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

[PATCH] make downloads.dpi use http_user_agent from dillorc
by a1ex＠dismail.de Dec. 10, 2024

Dec. 10, 2024

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;

2 4

[WIP PATCH] Use SIGUSR1 to reload the page
by a1ex＠dismail.de Oct. 25, 2024

Oct. 25, 2024

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();

2 5

scroll_step description
by Kevin Koster Oct. 17, 2024

Oct. 17, 2024

There's a new "scroll_step" option in the example configuration file for 3.1.0-rc1. The comment "Mouse wheel scroll step in pixels" suggests that this only affects the mouse wheel, but it also changes the distance the page moves when the arrow keys are pressed and the overlap of previous page content that's left when you press Page Up/Down. I think that's a little confusing, especially as the value has changed since the default behaviour in 3.0.5 (the old value seems to have been about 25).

2 6

Directory of Dillo-friendly services
by a1ex＠dismail.de Oct. 2, 2024

Oct. 2, 2024

Hi, Here is a small site with a directory of Dillo-friendly services: https://alex.envs.net/dillectory/ I'd like to develop this further and maintain it, so if anyone has feedback or additions, please let me know! Regards, Alex

2 2

'load_images' pref ineffective on embedded images
by a1ex＠dismail.de Oct. 1, 2024

Oct. 1, 2024

Hi, The pref 'load_images=NO' only disables loading images from a remote img src, and not from an embedded[1] data:image src. If this behavior is intentional, would it be reasonable to implement an option to disable all images? It might be the case that the user does not want to see any images, no matter the img src. [1] <img src="data:image/png;base64,..."> Regards, Alex

2 2

Feature idea: save tabs list
by a1ex＠dismail.de Sept. 15, 2024

Sept. 15, 2024

Hi, It would be nice to have the ability to save a list of open tabs. Often I find myself shutting down my workstation and still have many tabs open in Dillo. Its a pain to go through them all at that moment to decide whats worth saving or bookmarking. An option to save all open tab urls to a file would be great. It would be even nicer if we could later open all those urls in new tabs when starting Dillo :) On first glance it doesn't seem very easy to implement, but also maybe not super complicated either. I don't have any patches yet, just wanted to put the idea out and see what you think about it. Regards, Alex

5 11

Queue Downloads
by Diego Sept. 6, 2024

Sept. 6, 2024

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!

2 4

Issues with HTTP multipart/form-data file upload
by Xavier Del Campo Romero Sept. 1, 2024

Sept. 1, 2024

Hello Dillo dev community, I am testing support among web browsers for slcl [1], a JS-less minimalist web storage solution. slcl relies on "multipart/form-data"-encoded HTTP requests to upload files to a server. Whereas Dillo helped me to uncover a few wrong assumptions on my code, I have realised a few issues on Dillo itself related to filue uploads that should be considered. Issue #1: While Dillo is fine uploading small files (up to a few MiB), things go wrong with larger files, so much that memory usage increases up to multiple GiB and can even lock the system up. This is because Dillo is designed to send requests always from memory, which means file contents must be dumped into memory first, and this might be unfeasible for large files. Suggestion: Instead, Dillo should ideally send file contents on-the-fly, so that memory usage is kept to a minimum regardless the file size. Issue #2: Even if Dillo generates a 70-byte, random boundary string (yet mostly filled with '-', similarly to Firefox [2]), it ensures it is not found anywhere inside the file contents. Again, this can be a serious bottleneck in the case of large files, as it requires to scan the whole file for a match. Suggestion: Define *all* of the 70 bytes in the boundary string as random, and assume they would never be found inside a file. The chance of accidental collision is so low that it is not worth the effort into checking them. Suggested patches: - 0001-dialog.cc-Generate-more-random-boundaries.patch) Issue #3: Dillo only supports uploading 1 file at a time. This is mostly because it relies (probably temporarily?) on the a_Dialog_save_file function [3]. However, this is not a limitation on the HTTP protocol, and other implementation such as Firefox or Chromium-based browsers support this. Suggested patches: - 0002-dialog-Add-a_Dialog_select_files.patch - 0003-WIP-multi-file-uploads.patch Conclusions: Dillo seems designed to always send requests from memory, so it is not straightforward to break this assumption in order to support large file uploads. 0003-WIP-multi-file-uploads.patch is an incomplete first step into fixing this, but it surely needs deeper design changes. I did not put more effort into these patches for the time being because, after seeing the potential complexity behind this task, I thought it was a better idea to ask the community for feedback and guidelines. Thank you very much for reading. Best regards, Xavier Del Campo Romero [1]: https://gitea.privatedns.org/xavi/slcl [2]: https://github.com/dillo-browser/dillo/blob/8a360e32ac3136494a494379a6dbbac… [3]: https://github.com/dillo-browser/dillo/blob/8a360e32ac3136494a494379a6dbbac…

2 7

TLS connect error: "an EOF was observed that violates the protocol"
by a1ex＠dismail.de Sept. 1, 2024

Sept. 1, 2024

Hi, Here are 2 separate issues: 1) socks5 proxy on 127.0.0.1:8080 not working. This is a proxy over ssh, for example: ssh -N -D 8080 user(a)example.com in dillorc: http_proxy="http://localhost:8080/" console output when trying to connect to a site: Connecting to 127.0.0.1:8080 CONNECT through proxy failed. Full reply not received: (nothing) ** WARNING **: CCC: call on already finished chain. Flags=CCC_Ended This setup works fine under Firefox. I tried doing a tcpdump while attempting the connection, and there is no activity. So, while trying to research this, I ran into another issue: 2) Any time I go to a page on this site, Dillo crashes with the following: Nav_open_url: new url='https://dillo-dev.auriga.wearlab.narkive.com/WT0JYUZq/dillo-won-t-resolve-u…' Dns_server [0]: dillo-dev.auriga.wearlab.narkive.com is 149.248.211.108 Connecting to 149.248.211.108:443 TLS connect error: "an EOF was observed that violates the protocol" Tls_close_by_key: Avoiding SSL shutdown for: https://dillo-dev.auriga.wearlab.narkive.com/WT0JYUZq/dillo-won-t-resolve-u… fd 6 is done and failed dillo(13689) in malloc(): write to free mem 0x60383b59140[24..31]@32 Abort trap gdb output: Program received signal SIGABRT, Aborted. thrkill () at /tmp/-:2 2 /tmp/-: No such file or directory. in /tmp/- This is on OpenBSD-current amd64 with LibreSSL 3.9.0, running an unmodified fresh checkout of Dillo master. Also tested on OpenBSD 7.5 with the same result. I tested the site with: https://www.ssllabs.com/ssltest/analyze.html?d=dillo-dev.auriga.wearlab.nar… There seem to be some handshake failures during the simulation. This probably is not be the fault of Dillo, but maybe there is a more graceful to handle this, rather than crashing. Even a test with curl has issues: curl: (35) LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to dillo-dev.auriga.wearlab.narkive.com:443 Is this site just broken/misconfigured? Regards, Alex

3 21