- Dillo-dev - lists.mailman3.com

Re: [PATCH] Minor wording change in doc/user_help

by Rodrigo Arias

Hi, On Mon, Jul 13, 2026 at 04:51:42PM +0200, Rodrigo Arias wrote: >Hi, > >Thanks, I'll wait a bit in case you find more typos/wording issues so >we can just merge all of them in one commit. Merged here: https://git.dillo-browser.org/dillo/commit/?id=6e72e11d0af684317cdb69b944db… Best, Rodrigo.

Aug. 11, 2026

Re: [PATCH] Update manpage with HTTPS note

by Rodrigo Arias

Thanks, merged: https://git.dillo-browser.org/dillo/commit/?id=06f2ea711ffaf0e726517f430352… Best, Rodrigo. On Tue, Aug 11, 2026 at 12:49:54AM -0400, Nikolas Nyby wrote: >It seems that HTTPS/TLS support is no longer experimental in dillo. >--- > doc/dillo.1.in | 9 ++++----- > 1 file changed, 4 insertions(+), 5 deletions(-) > >diff --git a/doc/dillo.1.in b/doc/dillo.1.in >index 411305f6..f53c4c20 100644 >--- a/doc/dillo.1.in >+++ b/doc/dillo.1.in >@@ -1,4 +1,4 @@ >-.TH dillo 1 "May 28, 2015" "" "USER COMMANDS" >+.TH dillo 1 "August 11, 2026" "" "USER COMMANDS" > .SH NAME > dillo \- web browser > .SH SYNOPSIS >@@ -9,10 +9,9 @@ dillo \- web browser > .SH DESCRIPTION > .PP > Dillo is a lightweight graphical web browser that aims to be secure. >-It handles HTTP internally, and FILE, FTP, and >-DATA URIs are handled through a plugin system (dpi). In addition, >-.I EXPERIMENTAL >-HTTPS support can be enabled. Both FTP and Dillo's download manager use the >+It handles HTTP/HTTPS internally, and FILE, FTP, and >+DATA URIs are handled through a plugin system (dpi). Both FTP and >+Dillo's download manager use the > .BR wget (1) > downloader. > .PP >-- >2.53.0 > >_______________________________________________ >Dillo-dev mailing list -- dillo-dev(a)mailman3.com >To unsubscribe send an email to dillo-dev-leave(a)mailman3.com

Aug. 11, 2026

[PATCH] Update manpage with HTTPS note

by Nikolas Nyby

It seems that HTTPS/TLS support is no longer experimental in dillo. --- doc/dillo.1.in | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/doc/dillo.1.in b/doc/dillo.1.in index 411305f6..f53c4c20 100644 --- a/doc/dillo.1.in +++ b/doc/dillo.1.in @@ -1,4 +1,4 @@ -.TH dillo 1 "May 28, 2015" "" "USER COMMANDS" +.TH dillo 1 "August 11, 2026" "" "USER COMMANDS" .SH NAME dillo \- web browser .SH SYNOPSIS @@ -9,10 +9,9 @@ dillo \- web browser .SH DESCRIPTION .PP Dillo is a lightweight graphical web browser that aims to be secure. -It handles HTTP internally, and FILE, FTP, and -DATA URIs are handled through a plugin system (dpi). In addition, -.I EXPERIMENTAL -HTTPS support can be enabled. Both FTP and Dillo's download manager use the +It handles HTTP/HTTPS internally, and FILE, FTP, and +DATA URIs are handled through a plugin system (dpi). Both FTP and +Dillo's download manager use the .BR wget (1) downloader. .PP -- 2.53.0

Aug. 11, 2026

Re: Debian package (bugs 216, 305)

by Rodrigo Arias

Hi Nikolas, Thanks a lot for your work packaging Dillo for Debian! I'm happy to see users of low end devices (Raspberry Pi and so on) will eventually be able to enjoy an updated Dillo directly from "apt install dillo". I have closed the issues you mention. Let us know if you have further issues from downstream and we will try to get it solved. Thanks!, Rodrigo. On Thu, Aug 06, 2026 at 02:01:34PM -0400, Nikolas Nyby wrote: >Hello, >The following bugs can be closed now that I have released a Dillo 3.3.0 >package in Debian: >* https://bug.dillo-browser.org/216/ >* https://bug.dillo-browser.org/305/ > >See: https://tracker.debian.org/pkg/dillo >This new version will be in Debian testing in a few days. >_______________________________________________ >Dillo-dev mailing list -- dillo-dev(a)mailman3.com >To unsubscribe send an email to dillo-dev-leave(a)mailman3.com

Aug. 6, 2026

Debian package (bugs 216, 305)

by Nikolas Nyby

Hello, The following bugs can be closed now that I have released a Dillo 3.3.0 package in Debian: * https://bug.dillo-browser.org/216/ * https://bug.dillo-browser.org/305/ See: https://tracker.debian.org/pkg/dillo This new version will be in Debian testing in a few days.

Aug. 6, 2026

Re: Error when opening local html file

by Nikolas Nyby

Rodrigo Arias wrote: > Have you installed dillo in its prefix (make install)? This is often a > symptom that you are running it directly from the build directory and is > not able to find the plugins. Ah okay, yes this is the problem, thanks. I was just testing things out in my build directory and hadn't run `make install` yet.

July 13, 2026

Re: [PATCH] Minor wording change in doc/user_help

by Rodrigo Arias

Hi, Thanks, I'll wait a bit in case you find more typos/wording issues so we can just merge all of them in one commit. Best, Rodrigo. On Mon, Jul 13, 2026 at 10:15:29AM -0400, Nikolas Nyby wrote: >--- > doc/user_help.in.html | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > >diff --git a/doc/user_help.in.html b/doc/user_help.in.html >index 9f0ca589..f1fd26c9 100644 >--- a/doc/user_help.in.html >+++ b/doc/user_help.in.html >@@ -154,7 +154,7 @@ or copying text. > > The graphical interface is designed to be used with a mouse or pointing > device. At the top of the browser window you have the location bar and the main >-buttons to control the browser. You can leave the mouse for a brief moment over >+buttons to control the browser. You can hover the cursor for a brief moment over > any part of the menu to show a tooltip with more information. > > Dillo has context sensitive menus, which are opened with the right mouse >-- >2.53.0 > >_______________________________________________ >Dillo-dev mailing list -- dillo-dev(a)mailman3.com >To unsubscribe send an email to dillo-dev-leave(a)mailman3.com

July 13, 2026

Re: Error when opening local html file

by Rodrigo Arias

Hi, On Sun, Jul 12, 2026 at 09:01:04PM -0400, Nikolas Nyby wrote: >Hello, >I couldn't find a bug log for this already, or maybe I am doing >something wrong. > >On current git master, I add this to the address bar: > file:///home/nik/Documents/margin-test.html > >The file fails to load. Also, when using the menu: >File -> Open File... dialog, which inserts this into the address bar: > file:/home/nik/Documents/margin-test.html > >and displays the error: > > ERROR: can't start dpid daemon (URL scheme = 'file')! Have you installed dillo in its prefix (make install)? This is often a symptom that you are running it directly from the build directory and is not able to find the plugins. Otherwise, please provide more details to reproduce this and the full execution log. Best, Rodrigo.

July 13, 2026

[PATCH] Minor wording change in doc/user_help

by Nikolas Nyby

--- doc/user_help.in.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/user_help.in.html b/doc/user_help.in.html index 9f0ca589..f1fd26c9 100644 --- a/doc/user_help.in.html +++ b/doc/user_help.in.html @@ -154,7 +154,7 @@ or copying text. The graphical interface is designed to be used with a mouse or pointing device. At the top of the browser window you have the location bar and the main -buttons to control the browser. You can leave the mouse for a brief moment over +buttons to control the browser. You can hover the cursor for a brief moment over any part of the menu to show a tooltip with more information. Dillo has context sensitive menus, which are opened with the right mouse -- 2.53.0

July 13, 2026

Error when opening local html file

by Nikolas Nyby

Hello, I couldn't find a bug log for this already, or maybe I am doing something wrong. On current git master, I add this to the address bar: file:///home/nik/Documents/margin-test.html The file fails to load. Also, when using the menu: File -> Open File... dialog, which inserts this into the address bar: file:/home/nik/Documents/margin-test.html and displays the error: ERROR: can't start dpid daemon (URL scheme = 'file')!

July 13, 2026

Re: Save link as... silent failure on gopher protocol

by Diego

Very thanks. I await. Chers Diego. El dom, 12 jul 2026 a las 21:46, Rodrigo Arias (<rodarima(a)gmail.com>) escribió: > Hi, > > On Thu, Jul 09, 2026 at 01:37:14AM +0200, Diego wrote: > >¿Can i have some feedback? ¿Do the patchs work for you? ¿do it seem a > >practical idea? ¿etc? > > Thanks, I received the patches but I haven't had time to look at this > yet, I have have it in my queue. > > Best, > Rodrigo. > > > > >cheers! > >Diego. > > > > > >El vie, 3 jul 2026 a las 14:17, Diego (<darkspirit5000(a)gmail.com>) > escribió: > > > >> Hello, I'm sending two patches with an idea to solve this problem. > >> It's a proof of concept that I'm offering to develop and complete, > >> although I have very little free time. > >> > >> The first patch works with the latest dillo release (3.3.0) but also > works > >> with the current repository. > >> It implements changes in dillo, download.dpi, and the file and data DPIs > >> as examples. > >> The second patch works with the latest gopher.dpi repository. > >> > >> The main idea is that the DPIs that handle protocols save the URL and > >> write the file themselves, coordinating with download.dpi and dillo. > >> > >> To do this, they implement a new DPI command: `save_url` > >> d_cmd = a_Dpip_build_cmd("cmd=%s url=%s destination=%s", "save_url", > url, > >> dl_dest); > >> > >> Dillo initiates a download, sending it to download.dpi as before. If > it's > >> HTTP* or FTP*, it downloads directly as it does now. Otherwise, it will > >> send a `save_url` command to Dillo to coordinate. This allows Dillo to > >> notify the user, verify the security of the change, etc.Currently, Dillo > >> only checks if there's a DPI that handles the requested protocol. > >> > >> (A new function (`a_Dpiapi_is_service_handled(server_str)`) queries > `dpid` > >> without executing the DPI. No code is modified in `dpid`. Modifying > `dpid` > >> or executing the DPI would allow querying the capabilities of the DPIs, > but > >> it doesn't seem necessary.) > >> > >> - If a DPI is present, it sends the `save_url` command to the DPI that > >> coordinates with `download.dpi` via a secondary channel so that > downloads > >> can continue even if all Dillo windows are closed. > >> > >> - If the protocol isn't handled, it notifies download.dpi through the > >> secondary channel (this reduces the amount of code). > >> > >> The next step would be to implement `save_url` in other protocol DPIs. > >> > >> A possible change to download.dpi once all is done is to leave > >> download.dpi it as just a GUI for DPIs and extract the code to download > >> HTTP to a DPI. (There's already ftp.dpi) > >> > >> One last thing: can you recommend a simple Git manual? > >> > >> > >> Saludos > >> Diego. > >> > >> El lun, 25 may 2026 a las 21:23, Rodrigo Arias (<rodarima(a)gmail.com>) > >> escribió: > >> > >>> Hi, > >>> > >>> On Mon, May 25, 2026 at 09:25:58AM -0700, Ben Collver wrote: > >>> >Good day, > >>> > > >>> >I am using dillo 3.3.0 on Slackware64 15.0. > >>> > > >>> >If I open a gopher directory, right-click on an item, and click > >>> >Save link as..., this opens a file save dialog. If i click OK, it > >>> >dismisses the dialog. I expected it to save something, but it > >>> >creates no new files. > >>> > > >>> >Gopher URI: gopher://gopher.pglaf.org/1/4/0/2/8/40282/ > >>> >Top item: 40282-0 > >>> > > >>> >I found the following workaround: > >>> > > >>> >* Left click 40282-0 > >>> >* Click Save button in browser toolbar > >>> > > >>> >This creates a new file as expected. > >>> > >>> Yes, this is a known limitation of the downloads in Dillo. Using the > >>> "Save link as" to fetch a new resource will use wget under the hood, > >>> which only allows http(s). You can see the message in the console: > >>> > >>> > UIcmd_save: /tmp/40282-0.txt > >>> > ** WARNING **: Ignoring download request for > >>> > 'gopher://gopher.pglaf.org/0/4/0/2/8/40282/40282-0.txt': not in > cache > >>> > and not downloadable. > >>> > >>> Browsing to the target file makes the gopher plugin fetch the file and > >>> place it in the Dillo cache (you can see it in about:cache). Then > saving > >>> the current page (or going back and clicking the "Save link as" entry) > >>> works because it fetches it from the cache. > >>> > >>> It is planned to solve this some time in the future, but involves > >>> complex changes. In the meanwhile, you can use this workaround. > >>> > >>> Best, > >>> Rodrigo. > >>> _______________________________________________ > >>> Dillo-dev mailing list -- dillo-dev(a)mailman3.com > >>> To unsubscribe send an email to dillo-dev-leave(a)mailman3.com > >>> > >> > > >_______________________________________________ > >Dillo-dev mailing list -- dillo-dev(a)mailman3.com > >To unsubscribe send an email to dillo-dev-leave(a)mailman3.com > > _______________________________________________ > Dillo-dev mailing list -- dillo-dev(a)mailman3.com > To unsubscribe send an email to dillo-dev-leave(a)mailman3.com >

July 12, 2026

Re: Save link as... silent failure on gopher protocol

by Rodrigo Arias

Hi, On Thu, Jul 09, 2026 at 01:37:14AM +0200, Diego wrote: >¿Can i have some feedback? ¿Do the patchs work for you? ¿do it seem a >practical idea? ¿etc? Thanks, I received the patches but I haven't had time to look at this yet, I have have it in my queue. Best, Rodrigo. > >cheers! >Diego. > > >El vie, 3 jul 2026 a las 14:17, Diego (<darkspirit5000(a)gmail.com>) escribió: > >> Hello, I'm sending two patches with an idea to solve this problem. >> It's a proof of concept that I'm offering to develop and complete, >> although I have very little free time. >> >> The first patch works with the latest dillo release (3.3.0) but also works >> with the current repository. >> It implements changes in dillo, download.dpi, and the file and data DPIs >> as examples. >> The second patch works with the latest gopher.dpi repository. >> >> The main idea is that the DPIs that handle protocols save the URL and >> write the file themselves, coordinating with download.dpi and dillo. >> >> To do this, they implement a new DPI command: `save_url` >> d_cmd = a_Dpip_build_cmd("cmd=%s url=%s destination=%s", "save_url", url, >> dl_dest); >> >> Dillo initiates a download, sending it to download.dpi as before. If it's >> HTTP* or FTP*, it downloads directly as it does now. Otherwise, it will >> send a `save_url` command to Dillo to coordinate. This allows Dillo to >> notify the user, verify the security of the change, etc.Currently, Dillo >> only checks if there's a DPI that handles the requested protocol. >> >> (A new function (`a_Dpiapi_is_service_handled(server_str)`) queries `dpid` >> without executing the DPI. No code is modified in `dpid`. Modifying `dpid` >> or executing the DPI would allow querying the capabilities of the DPIs, but >> it doesn't seem necessary.) >> >> - If a DPI is present, it sends the `save_url` command to the DPI that >> coordinates with `download.dpi` via a secondary channel so that downloads >> can continue even if all Dillo windows are closed. >> >> - If the protocol isn't handled, it notifies download.dpi through the >> secondary channel (this reduces the amount of code). >> >> The next step would be to implement `save_url` in other protocol DPIs. >> >> A possible change to download.dpi once all is done is to leave >> download.dpi it as just a GUI for DPIs and extract the code to download >> HTTP to a DPI. (There's already ftp.dpi) >> >> One last thing: can you recommend a simple Git manual? >> >> >> Saludos >> Diego. >> >> El lun, 25 may 2026 a las 21:23, Rodrigo Arias (<rodarima(a)gmail.com>) >> escribió: >> >>> Hi, >>> >>> On Mon, May 25, 2026 at 09:25:58AM -0700, Ben Collver wrote: >>> >Good day, >>> > >>> >I am using dillo 3.3.0 on Slackware64 15.0. >>> > >>> >If I open a gopher directory, right-click on an item, and click >>> >Save link as..., this opens a file save dialog. If i click OK, it >>> >dismisses the dialog. I expected it to save something, but it >>> >creates no new files. >>> > >>> >Gopher URI: gopher://gopher.pglaf.org/1/4/0/2/8/40282/ >>> >Top item: 40282-0 >>> > >>> >I found the following workaround: >>> > >>> >* Left click 40282-0 >>> >* Click Save button in browser toolbar >>> > >>> >This creates a new file as expected. >>> >>> Yes, this is a known limitation of the downloads in Dillo. Using the >>> "Save link as" to fetch a new resource will use wget under the hood, >>> which only allows http(s). You can see the message in the console: >>> >>> > UIcmd_save: /tmp/40282-0.txt >>> > ** WARNING **: Ignoring download request for >>> > 'gopher://gopher.pglaf.org/0/4/0/2/8/40282/40282-0.txt': not in cache >>> > and not downloadable. >>> >>> Browsing to the target file makes the gopher plugin fetch the file and >>> place it in the Dillo cache (you can see it in about:cache). Then saving >>> the current page (or going back and clicking the "Save link as" entry) >>> works because it fetches it from the cache. >>> >>> It is planned to solve this some time in the future, but involves >>> complex changes. In the meanwhile, you can use this workaround. >>> >>> Best, >>> Rodrigo. >>> _______________________________________________ >>> Dillo-dev mailing list -- dillo-dev(a)mailman3.com >>> To unsubscribe send an email to dillo-dev-leave(a)mailman3.com >>> >> >_______________________________________________ >Dillo-dev mailing list -- dillo-dev(a)mailman3.com >To unsubscribe send an email to dillo-dev-leave(a)mailman3.com

July 12, 2026

Re: [PATCH] Fix typo in doc/user_help

by Rodrigo Arias

Hi Nikolas, Thanks for the patch, merged in: https://git.dillo-browser.org/dillo/commit/?id=fe83f43f07e1a83e4c05831c553b… Best, Rodrigo. On Sun, Jul 12, 2026 at 12:10:02AM -0400, Nikolas Nyby wrote: >--- > doc/user_help.in.html | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > >diff --git a/doc/user_help.in.html b/doc/user_help.in.html >index 6b21a7f9..9f0ca589 100644 >--- a/doc/user_help.in.html >+++ b/doc/user_help.in.html >@@ -842,7 +842,7 @@ button over a link or over the current page can be configured to show additional > entries that will run programs defined in the dillorc configuration. The options > <code>link_action</code> and <code>page_action</code> define new entries > for the link and page menu respectively, multiple entries can be configured by >-writting them multiple times. >+writing them multiple times. > > > The format to specify an action is >-- >2.53.0 > >_______________________________________________ >Dillo-dev mailing list -- dillo-dev(a)mailman3.com >To unsubscribe send an email to dillo-dev-leave(a)mailman3.com

July 12, 2026

[PATCH] Fix typo in doc/user_help

by Nikolas Nyby

--- doc/user_help.in.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/user_help.in.html b/doc/user_help.in.html index 6b21a7f9..9f0ca589 100644 --- a/doc/user_help.in.html +++ b/doc/user_help.in.html @@ -842,7 +842,7 @@ button over a link or over the current page can be configured to show additional entries that will run programs defined in the dillorc configuration. The options <code>link_action</code> and <code>page_action</code> define new entries for the link and page menu respectively, multiple entries can be configured by -writting them multiple times. +writing them multiple times. The format to specify an action is -- 2.53.0

July 12, 2026

Re: Save link as... silent failure on gopher protocol

by Diego

¿Can i have some feedback? ¿Do the patchs work for you? ¿do it seem a practical idea? ¿etc? cheers! Diego. El vie, 3 jul 2026 a las 14:17, Diego (<darkspirit5000(a)gmail.com>) escribió: > Hello, I'm sending two patches with an idea to solve this problem. > It's a proof of concept that I'm offering to develop and complete, > although I have very little free time. > > The first patch works with the latest dillo release (3.3.0) but also works > with the current repository. > It implements changes in dillo, download.dpi, and the file and data DPIs > as examples. > The second patch works with the latest gopher.dpi repository. > > The main idea is that the DPIs that handle protocols save the URL and > write the file themselves, coordinating with download.dpi and dillo. > > To do this, they implement a new DPI command: `save_url` > d_cmd = a_Dpip_build_cmd("cmd=%s url=%s destination=%s", "save_url", url, > dl_dest); > > Dillo initiates a download, sending it to download.dpi as before. If it's > HTTP* or FTP*, it downloads directly as it does now. Otherwise, it will > send a `save_url` command to Dillo to coordinate. This allows Dillo to > notify the user, verify the security of the change, etc.Currently, Dillo > only checks if there's a DPI that handles the requested protocol. > > (A new function (`a_Dpiapi_is_service_handled(server_str)`) queries `dpid` > without executing the DPI. No code is modified in `dpid`. Modifying `dpid` > or executing the DPI would allow querying the capabilities of the DPIs, but > it doesn't seem necessary.) > > - If a DPI is present, it sends the `save_url` command to the DPI that > coordinates with `download.dpi` via a secondary channel so that downloads > can continue even if all Dillo windows are closed. > > - If the protocol isn't handled, it notifies download.dpi through the > secondary channel (this reduces the amount of code). > > The next step would be to implement `save_url` in other protocol DPIs. > > A possible change to download.dpi once all is done is to leave > download.dpi it as just a GUI for DPIs and extract the code to download > HTTP to a DPI. (There's already ftp.dpi) > > One last thing: can you recommend a simple Git manual? > > > Saludos > Diego. > > El lun, 25 may 2026 a las 21:23, Rodrigo Arias (<rodarima(a)gmail.com>) > escribió: > >> Hi, >> >> On Mon, May 25, 2026 at 09:25:58AM -0700, Ben Collver wrote: >> >Good day, >> > >> >I am using dillo 3.3.0 on Slackware64 15.0. >> > >> >If I open a gopher directory, right-click on an item, and click >> >Save link as..., this opens a file save dialog. If i click OK, it >> >dismisses the dialog. I expected it to save something, but it >> >creates no new files. >> > >> >Gopher URI: gopher://gopher.pglaf.org/1/4/0/2/8/40282/ >> >Top item: 40282-0 >> > >> >I found the following workaround: >> > >> >* Left click 40282-0 >> >* Click Save button in browser toolbar >> > >> >This creates a new file as expected. >> >> Yes, this is a known limitation of the downloads in Dillo. Using the >> "Save link as" to fetch a new resource will use wget under the hood, >> which only allows http(s). You can see the message in the console: >> >> > UIcmd_save: /tmp/40282-0.txt >> > ** WARNING **: Ignoring download request for >> > 'gopher://gopher.pglaf.org/0/4/0/2/8/40282/40282-0.txt': not in cache >> > and not downloadable. >> >> Browsing to the target file makes the gopher plugin fetch the file and >> place it in the Dillo cache (you can see it in about:cache). Then saving >> the current page (or going back and clicking the "Save link as" entry) >> works because it fetches it from the cache. >> >> It is planned to solve this some time in the future, but involves >> complex changes. In the meanwhile, you can use this workaround. >> >> Best, >> Rodrigo. >> _______________________________________________ >> Dillo-dev mailing list -- dillo-dev(a)mailman3.com >> To unsubscribe send an email to dillo-dev-leave(a)mailman3.com >> >

July 8, 2026

Re: Save link as... silent failure on gopher protocol

by Diego

Hello, I'm sending two patches with an idea to solve this problem. It's a proof of concept that I'm offering to develop and complete, although I have very little free time. The first patch works with the latest dillo release (3.3.0) but also works with the current repository. It implements changes in dillo, download.dpi, and the file and data DPIs as examples. The second patch works with the latest gopher.dpi repository. The main idea is that the DPIs that handle protocols save the URL and write the file themselves, coordinating with download.dpi and dillo. To do this, they implement a new DPI command: `save_url` d_cmd = a_Dpip_build_cmd("cmd=%s url=%s destination=%s", "save_url", url, dl_dest); Dillo initiates a download, sending it to download.dpi as before. If it's HTTP* or FTP*, it downloads directly as it does now. Otherwise, it will send a `save_url` command to Dillo to coordinate. This allows Dillo to notify the user, verify the security of the change, etc.Currently, Dillo only checks if there's a DPI that handles the requested protocol. (A new function (`a_Dpiapi_is_service_handled(server_str)`) queries `dpid` without executing the DPI. No code is modified in `dpid`. Modifying `dpid` or executing the DPI would allow querying the capabilities of the DPIs, but it doesn't seem necessary.) - If a DPI is present, it sends the `save_url` command to the DPI that coordinates with `download.dpi` via a secondary channel so that downloads can continue even if all Dillo windows are closed. - If the protocol isn't handled, it notifies download.dpi through the secondary channel (this reduces the amount of code). The next step would be to implement `save_url` in other protocol DPIs. A possible change to download.dpi once all is done is to leave download.dpi it as just a GUI for DPIs and extract the code to download HTTP to a DPI. (There's already ftp.dpi) One last thing: can you recommend a simple Git manual? Saludos Diego. El lun, 25 may 2026 a las 21:23, Rodrigo Arias (<rodarima(a)gmail.com>) escribió: > Hi, > > On Mon, May 25, 2026 at 09:25:58AM -0700, Ben Collver wrote: > >Good day, > > > >I am using dillo 3.3.0 on Slackware64 15.0. > > > >If I open a gopher directory, right-click on an item, and click > >Save link as..., this opens a file save dialog. If i click OK, it > >dismisses the dialog. I expected it to save something, but it > >creates no new files. > > > >Gopher URI: gopher://gopher.pglaf.org/1/4/0/2/8/40282/ > >Top item: 40282-0 > > > >I found the following workaround: > > > >* Left click 40282-0 > >* Click Save button in browser toolbar > > > >This creates a new file as expected. > > Yes, this is a known limitation of the downloads in Dillo. Using the > "Save link as" to fetch a new resource will use wget under the hood, > which only allows http(s). You can see the message in the console: > > > UIcmd_save: /tmp/40282-0.txt > > ** WARNING **: Ignoring download request for > > 'gopher://gopher.pglaf.org/0/4/0/2/8/40282/40282-0.txt': not in cache > > and not downloadable. > > Browsing to the target file makes the gopher plugin fetch the file and > place it in the Dillo cache (you can see it in about:cache). Then saving > the current page (or going back and clicking the "Save link as" entry) > works because it fetches it from the cache. > > It is planned to solve this some time in the future, but involves > complex changes. In the meanwhile, you can use this workaround. > > Best, > Rodrigo. > _______________________________________________ > Dillo-dev mailing list -- dillo-dev(a)mailman3.com > To unsubscribe send an email to dillo-dev-leave(a)mailman3.com >

July 3, 2026

Re: [PATCH] Fix header parsing bug with malicious header fields

by Rodrigo Arias

Hi, >diff --git a/src/cache.c b/src/cache.c >index 154bef5c..5bd8a5dc 100644 >--- a/src/cache.c >+++ b/src/cache.c >@@ -287,7 +287,7 @@ static int Cache_bufsize(CacheEntry_t *e) > * Inject full page content directly into the cache. > * Used for "about:splash". May be used for "about:cache" too. > * >- * The @param data_ds buffer is copied into the entry buffer, so it is >+ * @param buf is copied into the entry buffer, so it is the > * responsibility of the caller to free it. > */ > void a_Cache_entry_inject(const DilloUrl *Url, >@@ -765,9 +765,8 @@ static Dlist *Cache_parse_multiple_fields(const char *header, > j--; > field = dStrndup(header + i, j); > dList_append(fields, field); >- } else { >- while (header[i] != '\n') i++; > } >+ while (header[i] != '\n') i++; > } > > if (dList_length(fields) == 0) { Thanks!, merged in two commits with a comment: https://git.dillo-browser.org/dillo/commit/?id=7ed29a43c18a960946fe47f37004… https://git.dillo-browser.org/dillo/commit/?id=9b7b799c7e47ca6e2b91aec82bd5… Best, Rodrigo.

June 21, 2026

Re: Nordstjernen web browser

by Bobby Hiltz

> Banned, > Rodrigo. Probably the best option. It is totally possible that that email account is a bot too. The commits haven't stopped! I am annoyingly anti-AI, and it appears Lobsters had the same feelings about this project (https://lobste.rs/s/adztcr/nordstjernen_web_browser) And the claims? Stable? Written from scratch? Private? LEGENDARY? Good call. Thanks, Bobby

June 16, 2026

Re: Nordstjernen web browser

by J. M. Castroagudín Silva

On Mon, Jun 15, 2026 at 7:09 PM Rodrigo Arias <rodarima(a)gmail.com> wrote: > > Hi, > > Hmm, from the repo: > > >Minimalism: The whole engine is about 116,000 lines of C (plus a thin > >C++ Qt shell) — small enough for one person to read and audit > >end-to-end. > > >Don't ask "do you want me to proceed?", "should I continue?", "ready to > >commit?" — just do it. The user interrupts if they disagree. > > >Don't leave traces that the code has been written by AI LLM, in commit > >messages and git author and git committer. And yet, there are countless commits made by claude: https://github.com/nordstjernen-web/nordstjernen/commits/main/ Amazing, the amount of resources burned for a technology so damn abysmal It would be funny if it wasn't so sad :( > > Burn baby burn! > > https://www.theguardian.com/environment/2026/feb/13/elon-musk-xai-datacente… > > Banned, > Rodrigo. > _______________________________________________ > Dillo-dev mailing list -- dillo-dev(a)mailman3.com > To unsubscribe send an email to dillo-dev-leave(a)mailman3.com -- Saúde, J. M. Castroagudín

June 15, 2026

Re: caniuse for Dillo?

by Rodrigo Arias

Hi, On Mon, Jun 15, 2026 at 10:51:54PM +0400, Artyom Bologov wrote: >Hi y’all, > >I want to make sure my site opens in Dillo in perpetuity, so I’m >interested in what features of HTML and CSS Dillo does or does not >support. Thanks for taking that into consideration! >Is there any information on that? Can it be made accessible on >the Web somehow? Should it be relegated to caniuse or MDN? We don't have an equivalent list (at least not updated). I think the simplest method is to just try from time to time in Dillo and text-only browsers like links. As a general rule, test your site without CSS and avoid new CSS features like var() for sizing/margins (or use a fallback). Thanks!, Rodrigo.

June 15, 2026

Re: Nordstjernen web browser

by Rodrigo Arias

Hi, Hmm, from the repo: >Minimalism: The whole engine is about 116,000 lines of C (plus a thin >C++ Qt shell) — small enough for one person to read and audit >end-to-end. >Don't ask "do you want me to proceed?", "should I continue?", "ready to >commit?" — just do it. The user interrupts if they disagree. >Don't leave traces that the code has been written by AI LLM, in commit >messages and git author and git committer. Burn baby burn! https://www.theguardian.com/environment/2026/feb/13/elon-musk-xai-datacente… Banned, Rodrigo.

June 15, 2026

caniuse for Dillo?

by Artyom Bologov

Hi y’all, I want to make sure my site opens in Dillo in perpetuity, so I’m interested in what features of HTML and CSS Dillo does or does not support. Is there any information on that? Can it be made accessible on the Web somehow? Should it be relegated to caniuse or MDN? Best of luck, -- Artyom Bologov https://aartaka.me

June 15, 2026

Re: dpi problem

by Rodrigo Arias

Hi, On Mon, Jun 15, 2026 at 02:33:24AM +0200, Teddi Vazquez wrote: >Hello, I'm trying to add the plugins for gopher and gemini, when i run >the "make install" the next message appears in both: > >echo 'proto.gopher=gopher/gopher.filter.dpi' >> /root/.dillo/dpidrc Don't install with root (sudo) use just "make install" as your user. >dpidc stop || true >** ERROR **: [Dpi_read_comm_keys] No such file or directory >** ERROR **: main: Can't read dpid's port number These errors are expected when there is no dpid daemon running, which is fine if you don't have dillo open. After that "make install" it should work. Otherwise let us know. Best, Rodrigo.

June 15, 2026

Re: Nordstjernen web browser

by a1ex＠dismail.de

Andreas Røsdal <andreas.rosdal(a)gmail.com> wrote: > Hi, I am making the Nordstjernen web browser. > > Implemented in C. It's like Dillo, small and simple. > > https://nordstjernen.org/ > https://github.com/nordstjernen-web/nordstjernen > > I hope it's interesting for you, the internet needs more small independent web browsers. I'm all for more independent web browser alternatives, but there appear to be a couple of issues which would make this a non-starter for many people in this community: 1. Proprietary "source-available" style license. This does not make the project attractive for potential contributors, and users may also be resistant to participate in such a model. 2. Appears to be largely "vibe-coded". You make statements like "clean-room web browser written from scratch", but then there is this in 'Agents.MD': "Don't leave traces that the code has been written by AI LLM, in commit messages and git author and git committer." Some would argue that it can't be "clean-room from scratch" when the AI models you are using have been trained on other peoples work... Regards, Alex

June 15, 2026

Nordstjernen web browser

by Andreas Røsdal

Hi, I am making the Nordstjernen web browser. Implemented in C. It's like Dillo, small and simple. https://nordstjernen.org/ https://github.com/nordstjernen-web/nordstjernen I hope it's interesting for you, the internet needs more small independent web browsers. Andreas

June 15, 2026

dpi problem

by Teddi Vazquez

Hello, I'm trying to add the plugins for gopher and gemini, when i run the "make install" the next message appears in both: echo 'proto.gopher=gopher/gopher.filter.dpi' >> /root/.dillo/dpidrc dpidc stop || true ** ERROR **: [Dpi_read_comm_keys] No such file or directory ** ERROR **: main: Can't read dpid's port number mkdir -p ~/.dillo/dpi/gopher cp -f gopher.filter.dpi ~/.dillo/dpi/gopher I read the docs and thought maybe it was because the "dpi_dir" option wasn't added: "dpi_dir=~/.dillo/dpi/" but when I run dillo on the terminal this appears: prefs: {dpi_dir} is not a recognized token. paths: Cannot open file '/home/tmv/.dillo/keysrc': No such file or directory paths: Using /usr/local/etc/dillo/keysrc paths: Cannot open file '/home/tmv/.dillo/domainrc': No such file or directory paths: Using /usr/local/etc/dillo/domainrc I'm sorry if this obvious error, if possible I would like to receive some help, thanks. -- -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GC/CS/H/IT/L/M/P/S/SS/O d- s+: a? C++++ UL++++ P+ L+++ E+ W+++ N+ o- K++ w O-- M V- PS+++ PE++ Y+ PGP++ t+ 5+ X+ R tv b++++ DI--- D+ G++ e* h! r- x* ------END GEEK CODE BLOCK------ GPG: 37219EA0D04C8D3C Keybase: tmv

June 15, 2026

[PATCH] Fix header parsing bug with malicious header fields

by 256＠256-32.com

In cache.c, Cache_parse_multiple_fields() doesn't properly skip to the end of the line after finding a match, meaning you can trick it into thinking a single field is actually multiple fields. You can test it by running this command, assuming you have netcat installed: printf $'HTTP/1.0 200\r\nWarning: .Warning: x\r\n\r\n' | nc -Nl 8080 You can then direct Dillo to <http://localhost:8080/>. Dillo's output is then: HTTP warning: .Warning: x HTTP warning: x With this patch, the second line is not produced. (I also fixed a comment that uses the wrong name for a variable; I hope you don't mind.) Sorry the patch isn't in the usual .patch format, I'm new to git. diff --git a/src/cache.c b/src/cache.c index 154bef5c..5bd8a5dc 100644 --- a/src/cache.c +++ b/src/cache.c @@ -287,7 +287,7 @@ static int Cache_bufsize(CacheEntry_t *e) * Inject full page content directly into the cache. * Used for "about:splash". May be used for "about:cache" too. * - * The @param data_ds buffer is copied into the entry buffer, so it is + * @param buf is copied into the entry buffer, so it is the * responsibility of the caller to free it. */ void a_Cache_entry_inject(const DilloUrl *Url, @@ -765,9 +765,8 @@ static Dlist *Cache_parse_multiple_fields(const char *header, j--; field = dStrndup(header + i, j); dList_append(fields, field); - } else { - while (header[i] != '\n') i++; } + while (header[i] != '\n') i++; } if (dList_length(fields) == 0) {

June 14, 2026

Re: [Issue]: Parsing empty domain attributes in cookies

by Rodrigo Arias

Hi, On Wed, Apr 29, 2026 at 09:52:40PM +0200, Rodrigo Arias wrote: >I will merge it after fixing the cookies unit test, so I can add extra >cases for empty domains. Sorry for the delay, merged here: https://git.dillo-browser.org/dillo/commit/?id=9489bacfa2d051e52f6b9b43a246… Also added a couple of test cases. Best, Rodrigo.

June 6, 2026

Re: "Buggy" bugtracker doesn't copy or symlink additional files

by E. C. Masloch

On at 2026-06-04 19:11:55 +0200, Rodrigo Arias <rodarima(a)gmail.com> wrote: >Hi, > >> However, it appears that the "out" subdirectories of the program named buggy do not receive symlinks nor copies of the "extra attachments" files. > >Yeah, I'm aware. I have some fixes but I don't like any of them yet. I'll fix it eventually. I went and fixed this in my fork. The exact changeset is available on our hgweb [1]. Regards, ecm [1]: https://hg.pushbx.org/ecm/buggy/rev/71903036f451

June 5, 2026

Re: "Buggy" bugtracker doesn't copy or symlink additional files

by Rodrigo Arias

Hi, >However, it appears that the "out" subdirectories of the program named >buggy do not receive symlinks nor copies of the "extra attachments" >files. Yeah, I'm aware. I have some fixes but I don't like any of them yet. I'll fix it eventually. Best, Rodrigo.

June 4, 2026

"Buggy" bugtracker doesn't copy or symlink additional files

by E. C. Masloch

Hello! In the bugtracker sources [1] it states: > This repository contains the issues for the Dillo web browser. Each issue is contained in a directory named with the issue number. The text of the issue is stored in the index.md markdown file and any extra attachments are placed inside the issue directory. However, it appears that the "out" subdirectories of the program named buggy do not receive symlinks nor copies of the "extra attachments" files. Here's how to find attachment files in the repo named bugtracker: ~/proj/buggy/bugtracker/git$ find -mindepth 2 -a \! -iname index.md | grep -E '^\.\/[0-9]+\/' ./521/repro.sh ./429/meta ./520/log.txt Example is in ticket 520 [2]. The link titled "Full trace log" leads to a 404 page [3]. Regards, ecm [1]: https://git.dillo-browser.org/bugtracker/tree/README.md?id=0239b970b60b6ea6… [2]: https://bug.dillo-browser.org/520/ [3]: https://bug.dillo-browser.org/520/log.txt

June 4, 2026

Re: dillo displays corrupted data using gopher protocol

by Ben Collver

Hi Rodrigo, On Wed, May 27, 2026 at 11:05:11PM +0200, Rodrigo Arias wrote: > I enabled Asan with -fsanitize=address in CFLAGS and LDFLAGS and I see what > is going on: > > There is a missing case in which we are reading a character pass the buffer > (when i == len). I pushed the fix to the git repo: > > https://git.dillo-browser.org/plugins/gopher/commit/?id=d8055639af10041cec9… > > Let me know if that fixes it for you. Thanks for the explanation and the fix. Your fix works for me. -Ben

May 28, 2026

Re: dillo displays corrupted data using gopher protocol

by Rodrigo Arias

Hi Ben, On Mon, May 25, 2026 at 04:25:24PM -0700, Ben Collver wrote: > >I tried setting a breakpoint at line 349, watching the variables, and >stepping through the code with gdb's `n` command, but in that context >the plugin no longer gives SIGSEGV. > >Any more suggestions? I enabled Asan with -fsanitize=address in CFLAGS and LDFLAGS and I see what is going on: > ================================================================= > ==136179==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7b0195ff3040 at pc 0x5627981706b2 bp 0x7ffe14825560 sp 0x7ffe14825550 > READ of size 1 at 0x7b0195ff3040 thread T0 > #0 0x5627981706b1 in read_line /home/ram/dev/dillo/plugin/gopher/gopher.filter.dpi.c:332 > #1 0x5627981709c5 in read_response /home/ram/dev/dillo/plugin/gopher/gopher.filter.dpi.c:355 > #2 0x562798170d95 in render_dir /home/ram/dev/dillo/plugin/gopher/gopher.filter.dpi.c:384 > #3 0x56279817192c in respond /home/ram/dev/dillo/plugin/gopher/gopher.filter.dpi.c:466 > #4 0x562798171b25 in main /home/ram/dev/dillo/plugin/gopher/gopher.filter.dpi.c:490 > #5 0x7f0198027740 (/usr/lib/libc.so.6+0x27740) (BuildId: 020d6f7c33b2413f4fe10814c4729dce1387f049) > #6 0x7f0198027878 in __libc_start_main (/usr/lib/libc.so.6+0x27878) (BuildId: 020d6f7c33b2413f4fe10814c4729dce1387f049) > #7 0x56279816e384 in _start (/home/ram/.dillo/dpi/gopher/gopher.filter.dpi+0x3384) (BuildId: 2539342afa9ad468aea77caeadba0586e529a0f0) > > Address 0x7b0195ff3040 is located in stack of thread T0 at offset 4160 in frame > #0 0x562798170791 in read_response /home/ram/dev/dillo/plugin/gopher/gopher.filter.dpi.c:340 > > This frame has 2 object(s): > [32, 40) 'len' (line 342) > [64, 4160) 'buf' (line 341) <== Memory access at offset 4160 overflows this variable > HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork > (longjmp and C++ exceptions *are* supported) > SUMMARY: AddressSanitizer: stack-buffer-overflow /home/ram/dev/dillo/plugin/gopher/gopher.filter.dpi.c:332 in read_line > Shadow bytes around the buggy address: > 0x7b0195ff2d80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x7b0195ff2e00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x7b0195ff2e80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x7b0195ff2f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 0x7b0195ff2f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > =>0x7b0195ff3000: 00 00 00 00 00 00 00 00[f3]f3 f3 f3 f3 f3 f3 f3 > 0x7b0195ff3080: f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 > 0x7b0195ff3100: f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 > 0x7b0195ff3180: f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 > 0x7b0195ff3200: f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 > 0x7b0195ff3280: f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 > Shadow byte legend (one shadow byte represents 8 application bytes): > Addressable: 00 > Partially addressable: 01 02 03 04 05 06 07 > Heap left redzone: fa > Freed heap region: fd > Stack left redzone: f1 > Stack mid redzone: f2 > Stack right redzone: f3 > Stack after return: f5 > Stack use after scope: f8 > Global redzone: f9 > Global init order: f6 > Poisoned by user: f7 > Container overflow: fc > Array cookie: ac > Intra object redzone: bb > ASan internal: fe > Left alloca redzone: ca > Right alloca redzone: cb > ==136179==ABORTING There is a missing case in which we are reading a character pass the buffer (when i == len). I pushed the fix to the git repo: https://git.dillo-browser.org/plugins/gopher/commit/?id=d8055639af10041cec9… Let me know if that fixes it for you. Best, Rodrigo.

May 27, 2026

Re: dillo displays corrupted data using gopher protocol

by Ben Collver

Hi Rodrigo, On Tue, May 26, 2026 at 12:30:18AM +0200, Rodrigo Arias wrote: > I don't observe it here, which gopher plugin are you using and which commit? I am using commit a32f74522f990c46415977afcd06d0e8d162ea55 of the following gopher plugin: https://git.dillo-browser.org/plugins/gopher > You can likely invoke it manually with: > > $ dpidc stop > $ dpid & > $ key=$(cat ~/.dillo/dpid_comm_keys | cut -d " " -f2) > $ url="gopher://tilde.pink/1/~bencollver/log/2026-01-04-m1-macro-processor-retreat/readme.map" > $ echo "<cmd='auth' msg='$key' '><cmd='open_url' url='$url' '>\n" |\ > ~/.dillo/dpi/gopher/gopher.filter.dpi > > Perhaps using strace or gdb may help. Thanks! I built it with: CFLAGS = -std=c99 -D_POSIX_C_SOURCE=200112 -g I am including my gdb session below [1]. I tried setting a breakpoint at line 349, watching the variables, and stepping through the code with gdb's `n` command, but in that context the plugin no longer gives SIGSEGV. Any more suggestions? Thanks again, -Ben [1] gdb output: Program received signal SIGSEGV, Segmentation fault. 0x000000000040209c in read_line (buf=0x7fffffffdefb "\255\362Գ(\233G^\240Q0\335u.x86_64", len=18446744073709540501) at gopher.filter.dpi.c:331 331 for (i = 0; i < len && buf[i] != '\r' && buf[i] != '\n'; i++); (gdb) bt #0 0x000000000040209c in read_line ( buf=0x7fffffffdefb "\255\362Գ(\233G^\240Q0\335u.x86_64", len=18446744073709540501) at gopher.filter.dpi.c:331 #1 0x00000000004021e9 in read_response (s=3) at gopher.filter.dpi.c:355 #2 0x000000000040235a in render_dir (s=3, url=0x7fffffffd680 "gopher://tilde.pink/1/~bencollver/log/2026-01-04-m1-macro-processor-retreat/readme.map") at gopher.filter.dpi.c:384 #3 0x0000000000402823 in respond ( url=0x7fffffffd680 "gopher://tilde.pink/1/~bencollver/log/2026-01-04-m1-macro-processor-retreat/readme.map") at gopher.filter.dpi.c:466 #4 0x00000000004028ca in main () at gopher.filter.dpi.c:490 (gdb) up #1 0x00000000004021e9 in read_response (s=3) at gopher.filter.dpi.c:355 (gdb) p buf $3 = "i# 2026-01-04 - M1 Macro Processor Retreat\000Err\000null.host\000\061\000\000i\000Err\000null.host\000\061\000\000iI wrote a prototype gopher front-end to the Internet Archive. It was\000Err\000null.host\000\061\000\000ia single file AWK script using C"... (gdb) p start $4 = 12555

May 25, 2026

Re: dillo displays corrupted data using gopher protocol

by Rodrigo Arias

Hi, On Mon, May 25, 2026 at 02:14:27PM -0700, Ben Collver wrote: >Greetings, > >I am usuing dillo 3.3.0 on Slackware64 15.0. > >When i open the following document, dillo corrupts the content 100% of >the time. > > <gopher://tilde.pink/1/~bencollver/log/2026-01-04-m1-macro-processor-retreat/readme.map> > >See example screenshots linked below. > > <gopher://tilde.pink/I/~bencollver/files/dillo-1.png> > <gopher://tilde.pink/I/~bencollver/files/dillo-2.png> > >Details noticed about this corruption: > >* It never happens in lynx. >* It only happens for type 1 gopher items. >* It always begins on the line of text at offset 1500, which > happens to be the MTU for both the server and the client. > >Any suggestions for troubleshooting this further? I don't observe it here, which gopher plugin are you using and which commit? You can likely invoke it manually with: $ dpidc stop $ dpid & $ key=$(cat ~/.dillo/dpid_comm_keys | cut -d " " -f2) $ url="gopher://tilde.pink/1/~bencollver/log/2026-01-04-m1-macro-processor-retreat/readme.map" $ echo "<cmd='auth' msg='$key' '><cmd='open_url' url='$url' '>\n" |\ ~/.dillo/dpi/gopher/gopher.filter.dpi Perhaps using strace or gdb may help. Best, Rodrigo.

May 25, 2026

dillo displays corrupted data using gopher protocol

by Ben Collver

Greetings, I am usuing dillo 3.3.0 on Slackware64 15.0. When i open the following document, dillo corrupts the content 100% of the time. <gopher://tilde.pink/1/~bencollver/log/ 2026-01-04-m1-macro-processor-retreat/readme.map> See example screenshots linked below. <gopher://tilde.pink/I/~bencollver/files/dillo-1.png> <gopher://tilde.pink/I/~bencollver/files/dillo-2.png> Details noticed about this corruption: * It never happens in lynx. * It only happens for type 1 gopher items. * It always begins on the line of text at offset 1500, which happens to be the MTU for both the server and the client. Any suggestions for troubleshooting this further? Thanks! -Ben

May 25, 2026

Re: Save link as... silent failure on gopher protocol

by Rodrigo Arias

Hi, On Mon, May 25, 2026 at 09:25:58AM -0700, Ben Collver wrote: >Good day, > >I am using dillo 3.3.0 on Slackware64 15.0. > >If I open a gopher directory, right-click on an item, and click >Save link as..., this opens a file save dialog. If i click OK, it >dismisses the dialog. I expected it to save something, but it >creates no new files. > >Gopher URI: gopher://gopher.pglaf.org/1/4/0/2/8/40282/ >Top item: 40282-0 > >I found the following workaround: > >* Left click 40282-0 >* Click Save button in browser toolbar > >This creates a new file as expected. Yes, this is a known limitation of the downloads in Dillo. Using the "Save link as" to fetch a new resource will use wget under the hood, which only allows http(s). You can see the message in the console: > UIcmd_save: /tmp/40282-0.txt > ** WARNING **: Ignoring download request for > 'gopher://gopher.pglaf.org/0/4/0/2/8/40282/40282-0.txt': not in cache > and not downloadable. Browsing to the target file makes the gopher plugin fetch the file and place it in the Dillo cache (you can see it in about:cache). Then saving the current page (or going back and clicking the "Save link as" entry) works because it fetches it from the cache. It is planned to solve this some time in the future, but involves complex changes. In the meanwhile, you can use this workaround. Best, Rodrigo.

May 25, 2026

Save link as... silent failure on gopher protocol

by Ben Collver

Good day, I am using dillo 3.3.0 on Slackware64 15.0. If I open a gopher directory, right-click on an item, and click Save link as..., this opens a file save dialog. If i click OK, it dismisses the dialog. I expected it to save something, but it creates no new files. Gopher URI: gopher://gopher.pglaf.org/1/4/0/2/8/40282/ Top item: 40282-0 I found the following workaround: * Left click 40282-0 * Click Save button in browser toolbar This creates a new file as expected. Best regards, -Ben

May 25, 2026

Re: Dillo reporting UTF-8 bytes in URLs as bugs

by 256＠256-32.com

Thanks for the HTML4 standard link; I wasn't aware it didn't allow special characters in URLs. I have modified my static site generator to percent-encode these characters; it may be unimportant but I may as well conform to HTML4. > In HTML by the WHATWG they added exceptions for UTF-8 URLs, but I don't > think is a good idea. This breaks software that doesn't handle UTF-8 URLs > (i.e. anything that follows the RFC not what Google says). Can you name any examples of software that would break when presented with un-encoded UTF-8 URLs? Even Lynx supports them. P.S.: I know about RFC 3986; I've implemented it :^). The source of my confusion was that HTTP 1.0 (RFC 1945) defines URIs in a way that treats bytes >=0x80 as unreserved (section 3.2.1), and I falsely assumed HTML must be the same.

May 11, 2026

Re: Dillo reporting UTF-8 bytes in URLs as bugs

by Rodrigo Arias

Hi, On Sun, May 10, 2026 at 03:25:07AM +0100, 256(a)256-32.com wrote: >On my personal website <https://256-32.com/>, Dillo reports the following bug in >a link that uses special characters: >HTML warning: line 64, URL has 8 illegal bytes in {00-1F, 7F-FF} range ('/computers/důvěřivý'). Yes, we follow the RFC 3986 and the HTML 4.01 recommendation of marking illegal characters outside the unreserved set: https://www.w3.org/TR/html401/appendix/notes.html#h-B.2 In HTML by the WHATWG they added exceptions for UTF-8 URLs, but I don't think is a good idea. This breaks software that doesn't handle UTF-8 URLs (i.e. anything that follows the RFC not what Google says). My recommendation is to encode the URL with percent encoding: https://256-32.com/computers/d%C5%AFv%C4%9B%C5%99iv%C3%BD This is the URL that is used in HTTP, despite not being rendered as-is in the URL location of modern browsers. One of the problems with that is the Unicode "confusables", characters that render very similar but are different, like this: https://аpple.com See: https://www.xudongz.com/blog/2017/idn-phishing/ Best, Rodrigo.

May 10, 2026

Dillo reporting UTF-8 bytes in URLs as bugs

by 256＠256-32.com

On my personal website <https://256-32.com/>, Dillo reports the following bug in a link that uses special characters: HTML warning: line 64, URL has 8 illegal bytes in {00-1F, 7F-FF} range ('/computers/důvěřivý'). However, the HTTP response sent by my server specifies charset=utf-8 in the content type. These UTF-8 links work properly in Dillo, despite the bug message, and I believe my site is not in error here. <validator.w3.org> says my site is fine, so it seems there's nothing wrong with special characters in URLs. It doesn't report the same bytes outside of a link href as being bad. The error message seems to originate from src/html.cc:196.

May 10, 2026

Re: [PATCH] Add user-controllable Sec-GPC header

by a1ex＠dismail.de

Hi, <a1ex(a)dismail.de> wrote: > Hi, > > The attached patch adds a Sec-GPC header to Dillo. It defaults to ON, > and is controllable through a dillorc setting of 'http_sec_gpc'. > > Also, I changed DNT to be user-controllable with a dillorc setting of > 'http_dnt', also defaults to ON. > > I know that this is too late to get in for the 3.3.0 release, but I'm > sending it for review now, and if there are any issues it should allow > plenty of time to fix. > > Regards, > Alex > Friendly post-release ping! I've been running with this patch for a while now and it seems to be working fine. Here are some tests demonstrating how it works (showing HTTP headers using the new 'trace_http' feature): Default settings (http_dnt=YES, http_sec_gpc=YES): GET / HTTP/1.1\x0D Host: dillo-browser.org\x0D User-Agent: Dillo/3.3.0\x0D Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\x0D Accept-Encoding: gzip, deflate, br\x0D Referer: https://dillo-browser.org/\x0D Connection: keep-alive\x0D DNT: 1\x0D Sec-GPC: 1\x0D \x0D Only DNT on (http_dnt=YES, http_sec_gpc=NO): GET / HTTP/1.1\x0D Host: dillo-browser.org\x0D User-Agent: Dillo/3.3.0\x0D Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\x0D Accept-Encoding: gzip, deflate, br\x0D Referer: https://dillo-browser.org/\x0D Connection: keep-alive\x0D DNT: 1\x0D \x0D Only Sec-GPC on (http_dnt=NO, http_sec_gpc=YES): GET / HTTP/1.1\x0D Host: dillo-browser.org\x0D User-Agent: Dillo/3.3.0\x0D Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\x0D Accept-Encoding: gzip, deflate, br\x0D Referer: https://dillo-browser.org/\x0D Connection: keep-alive\x0D Sec-GPC: 1\x0D \x0D Both off (http_dnt=NO, http_sec_gpc=NO): GET / HTTP/1.1\x0D Host: dillo-browser.org\x0D User-Agent: Dillo/3.3.0\x0D Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\x0D Accept-Encoding: gzip, deflate, br\x0D Referer: https://dillo-browser.org/\x0D Connection: keep-alive\x0D \x0D If my implementation is less than ideal and you'd rather do it differently, or if this feature simply isn't worth bothering with, that's fine too. Regards, Alex

May 2, 2026

Re: [Issue]: Parsing empty domain attributes in cookies

by Julian Jørgensen

Hi Rodrigo, På Fri, 1 May 2026 23:04:07 +0200 Rodrigo Arias <rodarima(a)gmail.com> skrev: > >Maybe you need a hand with other issues? > > Sure!, here are some issues that would need a bit of work, but I > haven't had much time: > > Recently I saw that Wikipedia images were starting to fail with a 429 > HTTP code, likely because they consider Dillo a bot. I reached out to > them, but didn't got any reply. Perhaps there is something we could > do in our side to avoid this problem. > > https://bug.dillo-browser.org/523/ > > Another one is to add a limit to the maximum memory we will accept in > the decoder so we protect the user from compression bombs: > > https://bug.dillo-browser.org/422/ > > Another problem is that Dillo always caches the page, even if they > come with a no cache header. It would be nice to add some support for > this: > > https://bug.dillo-browser.org/293/ > https://bug.dillo-browser.org/77/ > > There are also many areas of improvement in the rendering side as > well, but I think it would be easier to work on the network/cache > first. Thanks, I will look at the page no-caching issue/feature :-). > Keep in mind that we have a strict ban against AI/LLM generated code. +1 Best regards, Julian Jørgensen

May 1, 2026

Re: [Issue]: Parsing empty domain attributes in cookies

by Rodrigo Arias

Hi Julian, On Fri, May 01, 2026 at 10:16:49PM +0200, Julian Jørgensen wrote: >Hmm, I think I misphased my email. What I was trying to say was: I had >fun debugging and creating the patch, and would like to work a bit more >on dillo :-). I'm glad :) >Maybe you need a hand with other issues? Sure!, here are some issues that would need a bit of work, but I haven't had much time: Recently I saw that Wikipedia images were starting to fail with a 429 HTTP code, likely because they consider Dillo a bot. I reached out to them, but didn't got any reply. Perhaps there is something we could do in our side to avoid this problem. https://bug.dillo-browser.org/523/ Another one is to add a limit to the maximum memory we will accept in the decoder so we protect the user from compression bombs: https://bug.dillo-browser.org/422/ Another problem is that Dillo always caches the page, even if they come with a no cache header. It would be nice to add some support for this: https://bug.dillo-browser.org/293/ https://bug.dillo-browser.org/77/ There are also many areas of improvement in the rendering side as well, but I think it would be easier to work on the network/cache first. Keep in mind that we have a strict ban against AI/LLM generated code. Best, Rodrigo.

May 1, 2026

Re: [Issue]: Parsing empty domain attributes in cookies

by Julian Jørgensen

Hi Rodrigo, På Fri, 1 May 2026 21:33:40 +0200 Rodrigo Arias <rodarima(a)gmail.com> skrev: > On Fri, May 01, 2026 at 08:01:45PM +0200, Julian Jørgensen wrote: > >I'm glad that my patch and report turned out to be usefull. I found > >the codebase pretty nice to navigate, so if you want to, I can give > >fixing the test a try. > > No worries, I already know what is causing the problem. It should not > take me long to fix it :) Hmm, I think I misphased my email. What I was trying to say was: I had fun debugging and creating the patch, and would like to work a bit more on dillo :-). Maybe you need a hand with other issues? Best regards, Julian Jørgensen

May 1, 2026

Re: [Issue]: Parsing empty domain attributes in cookies

by Rodrigo Arias

Hi Julian, On Fri, May 01, 2026 at 08:01:45PM +0200, Julian Jørgensen wrote: >I'm glad that my patch and report turned out to be usefull. I found the >codebase pretty nice to navigate, so if you want to, I can give fixing >the test a try. No worries, I already know what is causing the problem. It should not take me long to fix it :) Best, Rodrigo.

May 1, 2026

Re: [Issue]: Parsing empty domain attributes in cookies

by Julian Jørgensen

Hi Rodrigo, På Wed, 29 Apr 2026 21:52:40 +0200 Rodrigo Arias <rodarima(a)gmail.com> skrev: > Thanks for the patch, it seems to work as intended. I also think that > ignoring the key/value is the right interpretation from: > > https://www.rfc-editor.org/rfc/rfc6265#section-5.2.3 > > > If the attribute-value is empty, the behavior is undefined. > > However, the user agent SHOULD ignore the cookie-av entirely. > > I will merge it after fixing the cookies unit test, so I can add > extra cases for empty domains. I'm glad that my patch and report turned out to be usefull. I found the codebase pretty nice to navigate, so if you want to, I can give fixing the test a try. Best regards, Julian Jørgensen

May 1, 2026

Re: [Issue]: Parsing empty domain attributes in cookies

by Rodrigo Arias

Hi Julian, On Mon, Apr 27, 2026 at 11:30:06PM +0200, Julian Jørgensen wrote: >Hi Dillo devs, > >Thanks for a great browser :-). I'm having great fun using it >for accessing smaller sites. However, I might have found a minor issue >with the way it handles cookies. I'm not very familiar with browser, so >the problem is most likely on the site I'm trying to access. > >I use this pretty popular search engine called kagi.com. They have >a html mode, which I enjoy testing in browsers like Dillo. The problem >is that their session cookie is saved with an empty domain like so: >`Domain=;`. > >As far as I can understand from [1], it seems that this should result >in Dillo (the user agent?) ignoring this key/value pair. However, Dillo >will parse the domain as "", which will fail the domain/host >verification later in the program. > >I have attached a git formatted patch to demonstrate the issue. After >applying this change, the kagi.com page works like I would >expect. Thanks for the patch, it seems to work as intended. I also think that ignoring the key/value is the right interpretation from: https://www.rfc-editor.org/rfc/rfc6265#section-5.2.3 > If the attribute-value is empty, the behavior is undefined. However, > the user agent SHOULD ignore the cookie-av entirely. I will merge it after fixing the cookies unit test, so I can add extra cases for empty domains. Best, Rodrigo.

April 29, 2026

[Issue]: Parsing empty domain attributes in cookies

by Julian Jørgensen

Hi Dillo devs, Thanks for a great browser :-). I'm having great fun using it for accessing smaller sites. However, I might have found a minor issue with the way it handles cookies. I'm not very familiar with browser, so the problem is most likely on the site I'm trying to access. I use this pretty popular search engine called kagi.com. They have a html mode, which I enjoy testing in browsers like Dillo. The problem is that their session cookie is saved with an empty domain like so: `Domain=;`. As far as I can understand from [1], it seems that this should result in Dillo (the user agent?) ignoring this key/value pair. However, Dillo will parse the domain as "", which will fail the domain/host verification later in the program. I have attached a git formatted patch to demonstrate the issue. After applying this change, the kagi.com page works like I would expect. Best regards, Julian Jørgensen [1]: https://www.rfc-editor.org/rfc/rfc6265#section-5.2.3

April 27, 2026

Re: Release 3.3.0

by Diego

¡Congratulations! Diego. El dom, 26 abr 2026 a las 21:20, Xavier Del Campo Romero (< xavi92(a)disroot.org>) escribió: > Congratulations and thanks for the hard work, team! > > Best regards, > > Xavi > > On 4/26/26 18:42, Rodrigo Arias wrote: > > Hi, > > > > I'm happy to announce that the Dillo 3.3.0 release is finally out: > > > > https://dillo-browser.org/release/3.3.0/ > > > > It follows the FLTK 1.4.5 release made yesterday, which contains some > > bug fixes for font rendering with Pango/Cairo. > > > > Enjoy!, > > Rodrigo. > > _______________________________________________ > > Dillo-dev mailing list -- dillo-dev(a)mailman3.com > > To unsubscribe send an email to dillo-dev-leave(a)mailman3.com > > _______________________________________________ > Dillo-dev mailing list -- dillo-dev(a)mailman3.com > To unsubscribe send an email to dillo-dev-leave(a)mailman3.com >

April 26, 2026