September 2024 - Dillo-dev - lists.mailman3.com

Re: Queue Downloads

by Diego

I see same when do use filename without a path. I think download.dpi needs a filename with one path-segment or more. Send script v0.2 with a workarround (prefix "./" if there is not a "/" in filename) Best, Diego! El jue, 5 sept 2024 a las 15:17, <a1ex(a)dismail.de> escribió: > > Hi Diego, > > On Wed, 4 Sep 2024 18:17:42 +0200 > Diego <darkspirit5000(a)gmail.com> wrote: > > > Hello, maybe this script can be useful to someone. > > > > Requests downloads.dpi to download a URL to a file. He talks to dpid > > like dillo does. > > > > I think it's also a useful coding exercise. > > Nice, looks like a fun experiment! I think it's neat to be able to > interact with dpid outside of Dillo, and possibly could aid in > troubleshooting dpi development issues in future. > > The script seems to work fine, except the filename in the download > window just shows '??'. Do you get that as well? > > Regards, > Alex > > _______________________________________________ > Dillo-dev mailing list -- dillo-dev(a)mailman3.com > To unsubscribe send an email to dillo-dev-leave(a)mailman3.com

Sept. 5, 2024

Re: Queue Downloads

by a1ex＠dismail.de

Hi Diego, On Wed, 4 Sep 2024 18:17:42 +0200 Diego <darkspirit5000(a)gmail.com> wrote: > Hello, maybe this script can be useful to someone. > > Requests downloads.dpi to download a URL to a file. He talks to dpid > like dillo does. > > I think it's also a useful coding exercise. Nice, looks like a fun experiment! I think it's neat to be able to interact with dpid outside of Dillo, and possibly could aid in troubleshooting dpi development issues in future. The script seems to work fine, except the filename in the download window just shows '??'. Do you get that as well? Regards, Alex

Sept. 5, 2024

Queue Downloads

by Diego

Hello, maybe this script can be useful to someone. Requests downloads.dpi to download a URL to a file. He talks to dpid like dillo does. I think it's also a useful coding exercise. I'm bad at naming so if someone has a better name ^_^¡ Best, Diego!

Sept. 4, 2024

[PATCH] make downloads.dpi use http_user_agent from dillorc

by a1ex＠dismail.de

Hi, Here is a patch which allows wget called from downloads.dpi to use the user agent provided in dillorc, and fallback to the hardcoded Dillo/version agent if not defined. Regards, Alex diff -upr a/dlib/dlib.c b/dlib/dlib.c --- a/dlib/dlib.c Sun Aug 11 22:21:59 2024 +++ b/dlib/dlib.c Tue Sep 3 13:49:00 2024 @@ -922,6 +922,45 @@ char *dGethomedir (void) } /** + * Return the http_user_agent value in a static string + */ +char *dGetuseragent (void) +{ + static char *dillorc = NULL; + dillorc = dStrconcat(dGethomedir(), "/", ".dillo/dillorc", NULL); + FILE *In; + int len; + char *rcline = NULL, *value = NULL, *p; + if ((In = fopen(dillorc, "r")) == NULL) { + DLIB_MSG("dGetuseragent: unable to open dillorc.\n"); + return ("Dillo/" VERSION); + } + while ((rcline = dGetline(In)) != NULL) { + if (strncmp(rcline, "http_user_agent", 15) == 0) + break; + dFree(rcline); + } + fclose(In); + if (!rcline) { + value = ("Dillo/" VERSION); + DLIB_MSG("dGetuseragent: no 'http_user_agent' in dillorc.\n"); + } else { + len = (int) strlen(rcline); + if (len && rcline[len - 1] == '\n') + rcline[len - 1] = 0; + if ((p = strchr(rcline, '='))) { + while (*++p == ' '); + value = dStrdup(p); + } else { + value = ("Dillo/" VERSION); + DLIB_MSG("dGetuseragent: error parsing value in dillorc.\n"); + } + } + dFree(rcline); + return (value); +} + +/** * Get a line from a FILE stream. * Return value: read line on success, NULL on EOF. */ diff -upr a/dlib/dlib.h b/dlib/dlib.h --- a/dlib/dlib.h Sun Aug 11 22:21:59 2024 +++ b/dlib/dlib.h Tue Sep 3 13:49:00 2024 @@ -175,6 +175,7 @@ void dLib_show_messages(bool_t show); */ char *dGetcwd(void); char *dGethomedir(void); +char *dGetuseragent(void); char *dGetline(FILE *stream); int dClose(int fd); int dUsleep(unsigned long us); diff -upr a/dpi/downloads.cc b/dpi/downloads.cc --- a/dpi/downloads.cc Sun Aug 11 22:21:59 2024 +++ b/dpi/downloads.cc Tue Sep 3 13:49:06 2024 @@ -45,6 +45,7 @@ #include "config.h" #include "dpiutil.h" #include "../dpip/dpip.h" +#include "../dlib/dlib.h" /* * Debugging macros @@ -324,7 +325,7 @@ DLItem::DLItem(const char *full_filename, const char * cookies_path = dStrconcat(dGethomedir(), "/.dillo/cookies.txt", NULL); dl_argv = new char*[10]; int i = 0; - const char *user_agent = "Dillo/" VERSION; + const char *user_agent = dGetuseragent(); dl_argv[i++] = (char*)"wget"; if (stat(fullname, &ss) == 0) init_bytesize = (int)ss.st_size;

Sept. 3, 2024

Re: [WIP PATCH] Use SIGUSR1 to reload the page

by Rodrigo Arias

Hi, On Mon, Sep 02, 2024 at 04:04:30PM +0200, a1ex(a)dismail.de wrote: >Hi Rodrigo, > >I find your recent idea[0] to refresh the page on local file changes >interesting, and it could be a quite useful feature. > >[0] https://github.com/dillo-browser/dillo/issues/255 > >I imagine it can be triggered with a tool like entr[1]: > >ls /tmp/test.html | entr 'pkill -SIGUSR1 dillo' > >[1] http://eradman.com/entrproject/ Yeah, that was the idea. >So far, I have a working signal handler which will act upon receipt of >a SIGUSR1 signal. It just prints the signal # to the console right now. >I am trying to make it perform an 'a_UIcmd_reload', but haven't been >successful yet: > >dillo.cc:389:19: error: use of undeclared identifier 'vbw' > a_UIcmd_reload(*vbw); > ^ >1 error generated You need to find a pointer to BrowserWindow and pass it to a_UIcmd_reload(). Check a_Bw_num() and a_Bw_get() in src/bw.c. We should reload the current page on all windows. I'm not sure if we can do this from the context of a signal, we probably need to register a timeout in FLTK and handle it from there. Probably not a very easy issue. I should start labeling the ones that are easy. Best, Rodrigo.

Sept. 2, 2024

[WIP PATCH] Use SIGUSR1 to reload the page

by a1ex＠dismail.de

Hi Rodrigo, I find your recent idea[0] to refresh the page on local file changes interesting, and it could be a quite useful feature. [0] https://github.com/dillo-browser/dillo/issues/255 I imagine it can be triggered with a tool like entr[1]: ls /tmp/test.html | entr 'pkill -SIGUSR1 dillo' [1] http://eradman.com/entrproject/ So far, I have a working signal handler which will act upon receipt of a SIGUSR1 signal. It just prints the signal # to the console right now. I am trying to make it perform an 'a_UIcmd_reload', but haven't been successful yet: dillo.cc:389:19: error: use of undeclared identifier 'vbw' a_UIcmd_reload(*vbw); ^ 1 error generated bw.h and uicmd.hh are defined in dillo.cc, so its probably a skill issue on my end :) Any hints would be appreciated! Regards, Alex --- a/src/dillo.cc Sun Aug 11 22:21:59 2024 +++ b/src/dillo.cc Mon Sep 2 14:21:08 2024 @@ -381,6 +381,14 @@ static DilloUrl *makeStartUrl(char *str, bool local) } /* + * Use SIGUSR1 to reload the page + */ +static void reload_handler(int signum) +{ + MSG("signum=%d\n\n", signum); +} + +/* * MAIN */ int main(int argc, char **argv) @@ -579,6 +587,10 @@ int main(int argc, char **argv) a_Url_free(start_url); } } + + // Reload page on SIGUSR1 + if (signal (SIGUSR1, reload_handler) == SIG_IGN) + signal (SIGUSR1, SIG_IGN); Fl::run();

Sept. 2, 2024

Re: Issues with HTTP multipart/form-data file upload

by Rodrigo Arias

Hi Xavier, On Sun, Sep 01, 2024 at 11:17:53PM +0200, Xavier Del Campo Romero wrote: >> This other method has a slightly not >> uniform distribution, but only runs rand() 70 times: >> >> Which is probably okay for this case. > >I also think it is good enough. > >> Then, I think using our own set may be the most readable solution here, >> which also allows the quick module method. > >I agree. Please, take a look at this PR: https://github.com/dillo-browser/dillo/pull/256 Here is the raw patch series for "git am": https://github.com/dillo-browser/dillo/pull/256.patch It would be nice if you can test it with slcl to know it works fine. Best, Rodrigo.

Sept. 1, 2024

Re: Issues with HTTP multipart/form-data file upload

by Xavier Del Campo Romero

Hi Rodrigo, > Not sure what you mean with "unnecessary use of the heap". I meant > something like this: You are right: I was too fixated with strcspn(3), when in fact strchr(3) would already do. Also, this use of dStr_append_c() looks good to me. > The variable c is stored in a register, as you can see in the > disassembly (built with -Og): Thanks for the detailed explanation. Anyway, I do not expect this function to become a performance bottleneck. > This other method has a slightly not > uniform distribution, but only runs rand() 70 times: > > Which is probably okay for this case. I also think it is good enough. > Then, I think using our own set may be the most readable solution here, > which also allows the quick module method. I agree. Best regards, Xavi On 1/9/24 16:12, Rodrigo Arias wrote: > Hi Xavier, > >> Thank you. I am still unfamiliar with that part of Dillo, so please let >> me know about any progress. > > For now I'm still writing the RFC and doing some proof of concepts. I > can see that it will take a while. > >> Limiting ourselves to a-z, A-Z and 0-9 would still account for 62 out of >> the 75 possible characters, so roughly 82% of the set. I think that >> removing the quoting in favour of the limited set reduce the risk for >> broken implementations, yet still provide a good amount of randomness. > > Yes, I think so too. > >> I am not sure whether this was an intentional modification from your >> side. My patch is adding a <space> as defined by POSIX.1-2017 [1], so >> that sizeof " " would always return 2. Was it your intention to flag >> this potential confusion? > > Yes, my point was that it is that is not easy to determine the length of > a UTF-8 string by just looking at it. > >> Also, there was not strict reason to use sizeof " ". Any other >> character would do e.g.: sizeof "x", sizeof "A", etc. > > Same problem: > > ᕁ 𝓍 𝙭 х 𝐱 𝗑 ⤫ 𝑥 𝘅 ⤬ ᙮ ⨯ 𝕩 𝖝 × 𝔁 𝚡 x ｘ ⅹ 𝔵 ᕽ 𝒙 𝘹 > > 𝙰 A 𝐴 ᗅ 𝑨 𝚨 𝕬 𝖠 А Α 𝛢 𝝖 𝒜 𝜜 𖽀 𝓐 𝞐 Ａ 𝗔 𝘈 Ꭺ ꓮ 𝐀 𝔄 𝔸 𐊠 𝘼 > > Check: https://util.unicode.org/UnicodeJsps/confusables.jsp > > It is generally safer to use the explicit length. > >>> You can also use dStr_append_c() to only append one character, so you >>> only need a single character. >> >> That would be an unnecessary use of the heap, because the size is static. > > Not sure what you mean with "unnecessary use of the heap". I meant > something like this: > > static void generate_boundary(Dstr *boundary) > { > for (int i = 0; i < 70; i++) { > /* Extracted from RFC 2046, section 5.1.1. */ > static const char set[] = "abcdefghijklmnopqrstuvwxyz" > "ABCDEFGHIJKLMNOPQRSTUVWXYZ" > "0123456789"; > int c; > > do { > c = rand() & 0xff; > } while (!strchr(set, c)); > > dStr_append_c(boundary, c); > } > } > > The variable c is stored in a register, as you can see in the > disassembly (built with -Og): > > hop% r2 build/src/dillo > WARN: Relocs has not been applied. Please use `-e bin.relocs.apply=true` > or `-e bin.cache=true` next time > [0x000e3860]> s sym.generate_boundary_Dstr_ > [0x0012cf99]> af > [0x0012cf99]> pdf > ┌ 85: sym.generate_boundary_Dstr_ (int64_t arg1); > │ ; arg int64_t arg1 @ rdi > │ 0x0012cf99 55 push rbp ; > Fl_Pixmap.H:1250 ; generate_boundary(Dstr*) > │ 0x0012cf9a 4889e5 mov rbp, rsp > │ 0x0012cf9d 4155 push r13 > │ 0x0012cf9f 4154 push r12 > │ 0x0012cfa1 53 push rbx > │ 0x0012cfa2 4883ec08 sub rsp, 8 > │ 0x0012cfa6 4989fd mov r13, rdi ; > arg1 > │ 0x0012cfa9 41bc00000000 mov r12d, 0 ; > Fl_Pixmap.H:1251 > │ ┌─< 0x0012cfaf eb2c jmp 0x12cfdd > │ ┌┌──> 0x0012cfb1 ff1509cd1e00 call qword [reloc.rand] ; > Fl_Pixmap.H:1253 ; [0x319cc0:8]=0 > │ ╎╎│ 0x0012cfb7 0fb6d8 movzx ebx, al ; > <--- Perform the "& 0xff" by zero-extending the lowest byte in eax > │ ╎╎│ 0x0012cfba 89de mov esi, ebx ; > Fl_Pixmap.H:1260 > │ ╎╎│ 0x0012cfbc 488d3dbd5b.. lea rdi, > obj.generate_boundary_Dstr_::set ; 0x2a2b80 ; > "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789" > │ ╎╎│ 0x0012cfc3 ff15afc51e00 call qword [reloc.strchr] ; > [0x319578:8]=0 > │ ╎╎│ 0x0012cfc9 4885c0 test rax, rax > │ └───< 0x0012cfcc 74e3 je 0x12cfb1 > │ ╎│ 0x0012cfce 89de mov esi, ebx ; > Fl_Pixmap.H:1262 > │ ╎│ 0x0012cfd0 4c89ef mov rdi, r13 > │ ╎│ 0x0012cfd3 67e830570800 call sym.dStr_append_c > │ ╎│ 0x0012cfd9 4183c401 add r12d, 1 ; > Fl_Pixmap.H:1251 > │ ╎│ ; CODE XREF from generate_boundary(Dstr*) @ 0x12cfaf(x) > │ ╎└─> 0x0012cfdd 4183fc45 cmp r12d, 0x45 ; > 'E' > │ └──< 0x0012cfe1 7ece jle 0x12cfb1 > │ 0x0012cfe3 4883c408 add rsp, 8 ; > Fl_Pixmap.H:1264 > │ 0x0012cfe7 5b pop rbx > │ 0x0012cfe8 415c pop r12 > │ 0x0012cfea 415d pop r13 > │ 0x0012cfec 5d pop rbp > └ 0x0012cfed c3 ret > > This method gives us a perfect uniform distribution when RAND_MAX is a > power of 2, at the cost of executing rand() more times than required > (70/(62/256) ≈ 289 on average). This other method has a slightly not > uniform distribution, but only runs rand() 70 times: > > static void generate_boundary(Dstr *boundary) > { > /* Extracted from RFC 2046, section 5.1.1. */ > static const char set[] = "abcdefghijklmnopqrstuvwxyz" > "ABCDEFGHIJKLMNOPQRSTUVWXYZ" > "0123456789"; > static const int n = strlen(set); > > for (int i = 0; i < 70; i++) { > int c = (unsigned char) set[rand() % n]; > dStr_append_c(boundary, c); > } > } > > Which is probably okay for this case. > > Notice I haven't tested any of these methods yet, I'll need to add a > form upload test case to be able to see them in action (or a unit test). > >>> If we only use alphanumeric characters, we can just use isalnum() right? >> >> According to POSIX.1-2017 [2], isalnum(3) depends on the current locale >> configured by the system. For example, characters such as Ä or ú could >> return non-zero. > > Oh right, for some reason I was thinking this was the other way around, > and isalnum only worked with ASCII. I think we should review the other > uses of isalnum and friends as I think there may be used under similar > assumptions. > >> To avoid this, there are two possible solutions: >> >> 1. Use isalnum_l(3) to specify a locale_t object corresponding to the >> "POSIX" locale (equivalent to "C" [3]), which must be previously >> allocated by the newlocale(3) function [3] and released by the >> freelocal(3) function [4]. A minimalist example is shown below: >> >> locale_t l = newlocale(LC_CTYPE, "POSIX", NULL); >> >> for (unsigned char i = 0; i < 255; i++) >> printf("hhu=%hhu, c=%c, isalnum=%d\n", i, i, >> isalnum_l(i, l)); >> >> freelocale(l); >> >> 2. Define a known subset from the portable character set defined by >> POSIX.1-2017 [5] and use strspn(3), as already suggested by the patch. >> IMHO this approach is better because: >> - It does not deal with locales, so developers not familiar with them >> would understand the code better. >> - It is also portable outside a POSIX environment (not sure if this a >> requirement, though). >> - It does not require dynamic allication via newlocale(3). >> - It is the only possible option if non-alnum characters, such as ':' >> or '/', are appended to the boundary string. > > Then, I think using our own set may be the most readable solution here, > which also allows the quick module method. > > Best, > Rodrigo > _______________________________________________ > Dillo-dev mailing list -- dillo-dev(a)mailman3.com > To unsubscribe send an email to dillo-dev-leave(a)mailman3.com

Sept. 1, 2024

Re: Issues with HTTP multipart/form-data file upload

by Rodrigo Arias

Hi Xavier, >Thank you. I am still unfamiliar with that part of Dillo, so please let >me know about any progress. For now I'm still writing the RFC and doing some proof of concepts. I can see that it will take a while. >Limiting ourselves to a-z, A-Z and 0-9 would still account for 62 out of >the 75 possible characters, so roughly 82% of the set. I think that >removing the quoting in favour of the limited set reduce the risk for >broken implementations, yet still provide a good amount of randomness. Yes, I think so too. >I am not sure whether this was an intentional modification from your >side. My patch is adding a <space> as defined by POSIX.1-2017 [1], so >that sizeof " " would always return 2. Was it your intention to flag >this potential confusion? Yes, my point was that it is that is not easy to determine the length of a UTF-8 string by just looking at it. >Also, there was not strict reason to use sizeof " ". Any other >character would do e.g.: sizeof "x", sizeof "A", etc. Same problem: ᕁ 𝓍 𝙭 х 𝐱 𝗑 ⤫ 𝑥 𝘅 ⤬ ᙮ ⨯ 𝕩 𝖝 × 𝔁 𝚡 x ｘ ⅹ 𝔵 ᕽ 𝒙 𝘹 𝙰 A 𝐴 ᗅ 𝑨 𝚨 𝕬 𝖠 А Α 𝛢 𝝖 𝒜 𝜜 𖽀 𝓐 𝞐 Ａ 𝗔 𝘈 Ꭺ ꓮ 𝐀 𝔄 𝔸 𐊠 𝘼 Check: https://util.unicode.org/UnicodeJsps/confusables.jsp It is generally safer to use the explicit length. >> You can also use dStr_append_c() to only append one character, so you >> only need a single character. > >That would be an unnecessary use of the heap, because the size is static. Not sure what you mean with "unnecessary use of the heap". I meant something like this: static void generate_boundary(Dstr *boundary) { for (int i = 0; i < 70; i++) { /* Extracted from RFC 2046, section 5.1.1. */ static const char set[] = "abcdefghijklmnopqrstuvwxyz" "ABCDEFGHIJKLMNOPQRSTUVWXYZ" "0123456789"; int c; do { c = rand() & 0xff; } while (!strchr(set, c)); dStr_append_c(boundary, c); } } The variable c is stored in a register, as you can see in the disassembly (built with -Og): hop% r2 build/src/dillo WARN: Relocs has not been applied. Please use `-e bin.relocs.apply=true` or `-e bin.cache=true` next time [0x000e3860]> s sym.generate_boundary_Dstr_ [0x0012cf99]> af [0x0012cf99]> pdf ┌ 85: sym.generate_boundary_Dstr_ (int64_t arg1); │ ; arg int64_t arg1 @ rdi │ 0x0012cf99 55 push rbp ; Fl_Pixmap.H:1250 ; generate_boundary(Dstr*) │ 0x0012cf9a 4889e5 mov rbp, rsp │ 0x0012cf9d 4155 push r13 │ 0x0012cf9f 4154 push r12 │ 0x0012cfa1 53 push rbx │ 0x0012cfa2 4883ec08 sub rsp, 8 │ 0x0012cfa6 4989fd mov r13, rdi ; arg1 │ 0x0012cfa9 41bc00000000 mov r12d, 0 ; Fl_Pixmap.H:1251 │ ┌─< 0x0012cfaf eb2c jmp 0x12cfdd │ ┌┌──> 0x0012cfb1 ff1509cd1e00 call qword [reloc.rand] ; Fl_Pixmap.H:1253 ; [0x319cc0:8]=0 │ ╎╎│ 0x0012cfb7 0fb6d8 movzx ebx, al ; <--- Perform the "& 0xff" by zero-extending the lowest byte in eax │ ╎╎│ 0x0012cfba 89de mov esi, ebx ; Fl_Pixmap.H:1260 │ ╎╎│ 0x0012cfbc 488d3dbd5b.. lea rdi, obj.generate_boundary_Dstr_::set ; 0x2a2b80 ; "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789" │ ╎╎│ 0x0012cfc3 ff15afc51e00 call qword [reloc.strchr] ; [0x319578:8]=0 │ ╎╎│ 0x0012cfc9 4885c0 test rax, rax │ └───< 0x0012cfcc 74e3 je 0x12cfb1 │ ╎│ 0x0012cfce 89de mov esi, ebx ; Fl_Pixmap.H:1262 │ ╎│ 0x0012cfd0 4c89ef mov rdi, r13 │ ╎│ 0x0012cfd3 67e830570800 call sym.dStr_append_c │ ╎│ 0x0012cfd9 4183c401 add r12d, 1 ; Fl_Pixmap.H:1251 │ ╎│ ; CODE XREF from generate_boundary(Dstr*) @ 0x12cfaf(x) │ ╎└─> 0x0012cfdd 4183fc45 cmp r12d, 0x45 ; 'E' │ └──< 0x0012cfe1 7ece jle 0x12cfb1 │ 0x0012cfe3 4883c408 add rsp, 8 ; Fl_Pixmap.H:1264 │ 0x0012cfe7 5b pop rbx │ 0x0012cfe8 415c pop r12 │ 0x0012cfea 415d pop r13 │ 0x0012cfec 5d pop rbp └ 0x0012cfed c3 ret This method gives us a perfect uniform distribution when RAND_MAX is a power of 2, at the cost of executing rand() more times than required (70/(62/256) ≈ 289 on average). This other method has a slightly not uniform distribution, but only runs rand() 70 times: static void generate_boundary(Dstr *boundary) { /* Extracted from RFC 2046, section 5.1.1. */ static const char set[] = "abcdefghijklmnopqrstuvwxyz" "ABCDEFGHIJKLMNOPQRSTUVWXYZ" "0123456789"; static const int n = strlen(set); for (int i = 0; i < 70; i++) { int c = (unsigned char) set[rand() % n]; dStr_append_c(boundary, c); } } Which is probably okay for this case. Notice I haven't tested any of these methods yet, I'll need to add a form upload test case to be able to see them in action (or a unit test). >> If we only use alphanumeric characters, we can just use isalnum() right? > >According to POSIX.1-2017 [2], isalnum(3) depends on the current locale >configured by the system. For example, characters such as Ä or ú could >return non-zero. Oh right, for some reason I was thinking this was the other way around, and isalnum only worked with ASCII. I think we should review the other uses of isalnum and friends as I think there may be used under similar assumptions. > To avoid this, there are two possible solutions: > >1. Use isalnum_l(3) to specify a locale_t object corresponding to the >"POSIX" locale (equivalent to "C" [3]), which must be previously >allocated by the newlocale(3) function [3] and released by the >freelocal(3) function [4]. A minimalist example is shown below: > > locale_t l = newlocale(LC_CTYPE, "POSIX", NULL); > > for (unsigned char i = 0; i < 255; i++) > printf("hhu=%hhu, c=%c, isalnum=%d\n", i, i, >isalnum_l(i, l)); > > freelocale(l); > >2. Define a known subset from the portable character set defined by >POSIX.1-2017 [5] and use strspn(3), as already suggested by the patch. >IMHO this approach is better because: > - It does not deal with locales, so developers not familiar with them >would understand the code better. > - It is also portable outside a POSIX environment (not sure if this a >requirement, though). > - It does not require dynamic allication via newlocale(3). > - It is the only possible option if non-alnum characters, such as ':' >or '/', are appended to the boundary string. Then, I think using our own set may be the most readable solution here, which also allows the quick module method. Best, Rodrigo

Sept. 1, 2024

Re: TLS connect error: "an EOF was observed that violates the protocol"

by Rodrigo Arias

Hi Alex, On Thu, Aug 29, 2024 at 12:04:12PM +0200, a1ex(a)dismail.de wrote: >Hi Rodrigo, > >On Wed, 28 Aug 2024 23:02:38 +0200 >Rodrigo Arias <rodarima(a)gmail.com> wrote: > >> I think your IP may be banned from narkive. > >Yeah, that does sound like it could be the case. Funny, because I've >never even used that site before. I have a static IP address, so that >might have something to do with it. I'm thinking if you ever ran an exit Tor node that could be a plausible explanation. >On the plus side, without this issue we wouldn't have found the crash >in Dillo, so, thank you narkive for inadvertently helping Dillo :) Yes, this is more a symptom that we don't have enough tests. I'm thinking how to improve the test infrastructure so we can include more complex tests like bad TLS responses from a https server, among others. Best, Rodrigo.

Sept. 1, 2024