Re: ftp: Print actually requested URLs
On Sat, Nov 06, 2021 at 07:02:39PM +, Stuart Henderson wrote: > On 2021/11/06 17:29, Klemens Nanni wrote: > > Encoding URL paths changes the requested URL and therefore may yield > > different responses (opposed to an unencoded URL), solely depending on > > how the server implements de/encoding. > > Makes sense as this matches what various other tools that fetch URLs do > for printing. Or another approach would be to not output the URL at all > (it's still visible with -d). I explicitly didn't want to change ftp's default log-level, that's another discussion, imho.
Re: ftp: Print actually requested URLs
On 2021/11/06 17:29, Klemens Nanni wrote: > Encoding URL paths changes the requested URL and therefore may yield > different responses (opposed to an unencoded URL), solely depending on > how the server implements de/encoding. Makes sense as this matches what various other tools that fetch URLs do for printing. Or another approach would be to not output the URL at all (it's still visible with -d).
Re: ftp: Print actually requested URLs
On Sat, Nov 06, 2021 at 11:33:21AM -0600, Theo de Raadt wrote: > > This matches exactly what is seen on the wire, e.g. with tshark(1). > > I don't see why this is important. Users don't need to see what is > on the wire. > > Why intentionaly expose them to a translation they are not supposed > to know or care about? Because I've run into a few encoding issues already (the last one being the RFC update the I just committed) and I'd very much prefer accurate information on such matter. Take the example that led to the tilde fix: prior to the last commit ftp still encoded "~" to "%7e" and that's what got me a 404 instead of an expected 200. Here's ftp(1) without the tilde fix and without this diff: $ ftp https://review.trustedfirmware.org/changes/TF-A%2Ftrusted-firmware-a~7726/revisions/9/patch?download Trying 64:ff9b::339f:1211... Requesting https://review.trustedfirmware.org/changes/TF-A%2Ftrusted-firmware-a~7726/revisions/9/patch?download ftp: Error retrieving https://review.trustedfirmware.org/changes/TF-A%2Ftrusted-firmware-a~7726/revisions/9/patch?download: 404 Not Found Neither did it request the URL with "~" nor did it get a 404 for the one with "~" -- the output is plain wrong and I have to turn on `-d' to see what's really going on. Now with this diff applied, I do get the truth: $ ./obj/ftp https://review.trustedfirmware.org/changes/TF-A%2Ftrusted-firmware-a~7726/revisions/9/patch?download Trying 64:ff9b::339f:1211... Requesting https://review.trustedfirmware.org/changes/TF-A%2Ftrusted-firmware-a%7e7726/revisions/9/patch?download ftp: Error retrieving https://review.trustedfirmware.org/changes/TF-A%2Ftrusted-firmware-a%7e7726/revisions/9/patch?download: 404 Not Found I feed it "~" but ftp encodes it as "%7e" and the server cannot serve "%7e". With this important difference between user input and HTTP request I can reason about en/decoding issues *without having to distrust* my tool's output, poking at debug logs and/or looking at the source.
Re: ftp: Print actually requested URLs
> This matches exactly what is seen on the wire, e.g. with tshark(1). I don't see why this is important. Users don't need to see what is on the wire. Why intentionaly expose them to a translation they are not supposed to know or care about?
