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.
