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.. (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
