One micro-addition to John's comment without disagreeing with anything he said... --On Monday, November 30, 2020 12:59 -0500 John Levine <johnl@xxxxxxxxx> wrote: > In article <5FC52B73.6050106@xxxxxxxxxxxxx> you write: >> As I just posted to Carsten, this was a major problem 35 >> years ago which is why protocols like FTP are rich in >> options to handle this. I could be 180 degrees wrong that >> HTTP/HTML is making no changes and so giving just what is on >> the web site which is then no use to me and it is FTP that >> knows what I really want and is making corrections for me, >> such as inserting <CRLF> or <FF> where I need it > > In this case, you are indeed wrong. HTTP returns whatever it > returns other than some options for compression and > decompression that don't matter here. All of the display > problems you are seeing are due to the inconsistent ways that > browsers interpret the text files they fetch, which is not > surprising since browsers are designed to display formatted > HTML, not unformatted text. This tells us that web browsers > are a poor tool to look at text files, not that anything is > wrong about HTTP. >... You are also a tad wrong about FTP. If FTP is run using the ASCII Type and "stream" mode (which are the required defaults) and if no type of structure commands are issued, then a conforming server will deliver an NVT text file (see the Telnet protocol spec) using as line delimiters. If the file is coming from a system that uses CRLF, character counts, or record delimiters internally, "raw" CR or LF should be transmitted unchanged, but, if it uses some other line-delimiting convention, the server it is required to turn that into CRLF. Presumably if the local system using page delimiters other than FF those would have them converted too. But FTP won't do pagination of an unpaginated file or introduce line endings into a file that does not have them. There is also a small, but unpleasant, elephant in that room. I have seen many FTP clients, most operating in a command-line mode or with URLs, that will not allow the user to issue most (or any) of FTP's large selection of commands. For text files, that should be ok because the defaults are supposed to be TYPE ASCII, Stream mode, and File structure. And, while I have never taken the time to track down the details, either some of those clients quietly request TYPE Image or some servers transmit whatever they have as if Image files had been requested (I think the latter). That works much of the time, but can result, e.g., in LF-delimited lines in what should have been ASCII transfers. And, looking back at the spec to refresh my memory, I rediscovered a glitch I found and tried to get fixed years ago but got nowhere. Watch for a note on the subject. john
