May 2026 - Dillo-dev - lists.mailman3.com

Dillo reporting UTF-8 bytes in URLs as bugs
by 256＠256-32.com May 11, 2026

May 11, 2026

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.

2 2

[PATCH] Add user-controllable Sec-GPC header
by a1ex＠dismail.de May 2, 2026

May 2, 2026

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

1 1

[Issue]: Parsing empty domain attributes in cookies
by Julian Jørgensen May 1, 2026

May 1, 2026

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

2 6