- Dillo-dev - lists.mailman3.com

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