Re: Call for Community Feedback: Retiring IETF FTP Service

[Julian Reschke <[e-mail]>]

Am 30.11.2020 um 17:21 schrieb Keith Moore:
> On 11/30/20 10:52 AM, Roman Danyliw wrote:
>
>> If one visits,https://www.rfc-editor.org/rfc/rfc7230.txt, is a TXT not
>> returned?
>
> How would you know?  If you visit a file from a browser, you only know
> what the browser shows you.

Well, you could check with the web developer tools.

> If for instance I click on that link and then hit ^U in the browser
> (which happens to be Brave), what I now see appears to be text with line
> numbers.   I can't tell if the formfeeds are there or not.

Firefox shows you the line feeds (as control char). So is your point
that there *can* be a user agent that behaves differently? How is that
materially different from different text editors doing things differently?

> If I do the same in firefox, I get text without line numbers. The
> formfeeds actually appear to be there - they show up as squares with
> "000C" in them.
>
> In chromium, I get the same behavior as Brave.
>
> In the past, I've gotten other results, such as seeing HTML tags
> embedded in what is supposedly the "source" of the plain text file.
>
> The general problem is that when you use a web browser to view something
> and then save or print it, the behavior is undefined. No standard says
> what should happen, and you don't know what you're going to get.

<https://html.spec.whatwg.org/multipage/links.html#as-a-download> - but
I confess that I'm not going to read that algorithm :-)

I agree that Chrome does not *show* the FF character, but it *is*
present in the saved file.

> But a related problem is that people keep gratuitously changing things.
> So even if you find a workaround to some bit of damage, that workaround
> is not assured to work in the future.
>
> To be clear, we're just talking about damage caused by web browsers
> here.   I doubt that anyone is clicking on a .txt and getting .html or
> .pdf from the web server.
>
> But this illustrates why some of us prefer to avoid using web browsers
> for some things, and instead rely on tools that have well-defined behavior.
>
> Also, I don't think the HTTP protocol corrupts files, though I have seen
> software that would silently ignore an incomplete HTTP file transfer.

Which *should* be a thing of the past with HTTP/2 because of better
message framing.

> But if what you actually need to do is browse files to pick out the ones
> you want, vanilla HTTP doesn't provide what a tool needs to reliably do
> that.

It does not?

Best regards, Julian