On Thu, Mar 19, 2026 at 09:34:08PM +0000, Conrad Hughes via Lynx-dev wrote: > I've recently started to receive HTML emails containing links which > 'lynx -child -dump' seems to be rendering wrongly. They contain > %-encoded URLs > > <a href="https://foo.bar/otherdomain%2Fpath%2Fetc%3Fparam%3Dval..";> > > .. when rendered by lynx these are presented with the %codes decoded (so > I get otherdomain/path/etc?param=val.. above). This decoded URL is not > openable: the server at foo.bar only returns a page for the *%-encoded* > version of the URL. This seems to be a new thing, and because I'm using > the current Debian release of lynx (2.9.2, compiled in 2024) it is > almost certainly some new piece of e-commerce order tracking craziness, > but it would be nice to sort out. > > I'm wondering whether > > (1) there's an option somewhere to prevent lynx from decoding these > URLs when rendering them; and > > (2) do you think this decoding of the URLs counts as a bug, or is it > misbehaviour on the part of the software that generates these URLs and > fails to handle them? It's been too long since I was familiar with > the standards docs..
Someone reported something like this last summer (still on my to-do list, since ahead of that was an improvement which I've not found time to complete -- but this one probably is less effort). > (if I use lynx interactively on the email body, then it correctly opens > the encoded version of the link, so I am suspecting that this might > count as a rendering bug) > > Best, > Conrad > > -- Thomas E. Dickey <[email protected]> https://invisible-island.net
signature.asc
Description: PGP signature
