Conrad Hughes via Lynx-dev dixit: >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).
tbh, I actually *like* that it renders them decoded: this allows one to quickly pick out a link target hidden by, say, Google who do just that, percent-encode the whole thing and pass it as one argument to their tracking redirection. >This decoded URL is not openable: the server at foo.bar only returns a >page for the *%-encoded* version of the URL. Yes, that’s sensible (as sensible as both working), and lynx should not decode them for serving. That is, if I load an HTML file containing the above link and move the cursor on it, the address line (in advanced mode) and perhaps the “Link that you currently have selected” in the ‘=’ screen should show “https://foo.bar/otherdomain/path/etc?param=val...” but the ‘E’ URL input field should stick to the percent-encoded form, and lynx must GET /otherdomain%2Fpath%2Fetc%3Fparam%3Dval.. from the remote server. > (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.. I think it’s reasonable. >(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 >the current Debian release of lynx (2.9.2, compiled in 2024) it is Hmm, I cannot really reproduce that though. I edited the file to read… <html><body><p> <a href="http://example.org/xxxcgi?otherdomain%2Fpath%2Fetc%3Fparam%3Dval..";>link</a> … where the CGI in question is one on a server of mine (references changed to avoid scrapers) that just returns the server info. The address status line shows: |http://example.org/xxxcgi?otherdomain%2Fpath%2Fetc%3Fparam%3Dval.. So, not decoded (pity). The ‘=’ info page shows: |Link that you currently have selected | | Linkname: link | URL: http://example.org/xxxcgi?otherdomain%2Fpath%2Fetc%3Fparam%3Dval.. | http://example.org/xxxcgi?otherdomain/path/etc?param=val.. So, both (yay). ‘E’ shows: |Edit the current link's URL: http://example.org/xxxcgi?otherdomain%2Fpath%2Fetc%3Fparam%3Dval.. So, not decoded (ok). Following the link gives me: |ARGV[1]=otherdomain/path/etc\?param=val.. |QUERY_STRING=otherdomain%2Fpath%2Fetc%3Fparam%3Dval.. |REQUEST_URI='/xxxcgi?otherdomain%2Fpath%2Fetc%3Fparam%3Dval..' So, not decoded (good). Your “if I use lynx interactively on the email body” makes me wonder whether there isn’t something *else* interfering? For example, if you external an HTML body part in alpine, it’ll forcibly remove any image links (to protect the user (good), but with no way to override (annoying))… bye, //mirabilos -- <ch> you introduced a merge commit │<mika> % g rebase -i HEAD^^ <mika> sorry, no idea and rebasing just fscked │<mika> Segmentation <ch> should have cloned into a clean repo │ fault (core dumped) <ch> if I rebase that now, it's really ugh │<mika:#grml> wuahhhhhh
