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. If you use a batch tool like wget or curl to fetch the text version of an RFC (or any other text file), and look at it in a text editor, it works fine. For that matter, if you use a browser to download a file using a right click and a 'Save Link As' option, that works too. Since web browsers are designed to display HTML we also provide HTML versions of RFCs designed to render well in web browsers. But you have to pick the right version for the right purpose. R's, John
