Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask
 
PerlMonks  

Re: Re: Re: Re: Re: Handling Mac, Unix, Win/DOS newlines at readtime...

by Fastolfe (Vicar)
on Sep 17, 2002 at 21:11 UTC ( #198647=note: print w/ replies, xml ) Need Help??


in reply to Re: Re: Re: Re: Handling Mac, Unix, Win/DOS newlines at readtime...
in thread Handling Mac, Unix, Win/DOS newlines at readtime...

You're both right and wrong here. Let me first quote a bit of the HTML 4 specification:

4.3 The text/html content type

HTML documents are sent over the Internet as a sequence of bytes accompanied by encoding information (described in the section on character encodings). The structure of the transmission, termed a message entity, is defined by RFC2045 and RFC2616. A message entity with a content type of "text/html" represents an HTML document.

Here, the HTML specification explicitly indicates a reliance upon RFC2045 (and by association, RFC2046).

An HTML document is stored as a native plain-text document either on a user's PC or a web server. Newlines at this point are native to the OS.

Do not make the assumption that HTTP servers are filesystem-based! It just so happens that a filesystem-oriented document root, with URI contents represented as files, is the simplest and most prevalent way HTTP servers are implemented, but do not blindly assume that HTTP was written with the intent that a URI should map to a file on a filesystem. That's just not accurate.

But because most HTTP servers do this, they have to do a certain number of things to ensure that a requested resource is being delivered in a fashion consistent with HTTP and MIME. This usually involves examining a file extension for a MIME type, and delivering the contents of the file in a fashion consistent with that MIME type. If an HTML document is being stored on a filesystem with native newlines, an HTTP server that relies on filesystem-oriented content should take steps to ensure that "special cases" like newlines are addressed as well. Conversion should be performed by the web server as a consequence of the web server's filesystem-oriented implementation of an HTTP service.

What is the alternative? Turn HTML files into what are effectively binary files due to their quirkly (with respects to the native text format) line endings? If not, what else is supposed to be converting newlines here?

Think of this from the user agent's point of view. It's expecting content with the MIME type of text/html. MIME explicitly states that text/html must have line endings in CRLF fashion. How does it get that way? If the server isn't responsible for it, what is?

The HTTP servers have assumed this responsibility as a consequence of choosing a filesystem-oriented mechanism for storing content. They have to live with content stored with native line endings and should thus be responsible for getting that converted into something appropriate when delivering text/* content over the Internet.


Comment on Re: Re: Re: Re: Re: Handling Mac, Unix, Win/DOS newlines at readtime...
Re: Re: Re: Re: Re: Re: Handling Mac, Unix, Win/DOS newlines at readtime...
by mdillon (Priest) on Sep 17, 2002 at 21:23 UTC
    Let me quote RFC 2068 (HTTP/1.1), from the section on the relationship between HTTP and MIME:

    19.4.1 Conversion to Canonical Form

    MIME requires that an Internet mail entity be converted to canonical form prior to being transferred. Section 3.7.1 of this document describes the forms allowed for subtypes of the "text" media type when transmitted over HTTP. MIME requires that content with a type of "text" represent line breaks as CRLF and forbids the use of CR or LF outside of line break sequences. HTTP allows CRLF, bare CR, and bare LF to indicate a line break within text content when a message is transmitted over HTTP.

    Where it is possible, a proxy or gateway from HTTP to a strict MIME environment SHOULD translate all line breaks within the text media types described in section 3.7.1 of this document to the MIME canonical form of CRLF. Note, however, that this may be complicated by the presence of a Content-Encoding and by the fact that HTTP allows the use of some character sets which do not use octets 13 and 10 to represent CR and LF, as is the case for some multi-byte character sets.

    Notice the "SHOULD" and "Where it is possible".

      Yep, you're right. See my other reply also. This surprises me, in a way. The only way this relaxed requirement makes sense to me is in a case where the HTTP server isn't sure what line endings are being used on textual content stored on the server, which is an example of someone making special concessions because something else isn't doing what it's supposed to.

      So basically, HTML says, "I should be CRLF when sent over the Internet," but HTTP says, "Err, yah, we'll see what we can do."

      :/

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://198647]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others having an uproarious good time at the Monastery: (3)
As of 2014-09-15 02:21 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite cookbook is:










    Results (145 votes), past polls