[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ruby-talk
Subject:    Re: mime type
From:       "Jason Voegele" <jason () jvoegele ! com>
Date:       2002-04-15 18:34:36
[Download RAW message or body]

> "I was told once..." that to be excruciatingly correct you are supposed
>  to include carriage returns (\r\n\r\n) -- because it's the spec, even 
> though it generally works with just the newlines. Can anybody 
> confirm/deny this?

Here are two relevant portions of RFC 2616 (the HTTP 1.1 spec):

"
   HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all
   protocol elements except the entity-body (see appendix 19.3 for
   tolerant applications). The end-of-line marker within an entity-body
   is defined by its associated media type, as described in section 3.7.
"

AND

"
   When in canonical form, media subtypes of the "text" type use CRLF as
   the text line break. HTTP relaxes this requirement and allows the
   transport of text media with plain CR or LF alone representing a line
   break when it is done consistently for an entire entity-body. HTTP
   applications MUST accept CRLF, bare CR, and bare LF as being
   representative of a line break in text media received via HTTP. In
   addition, if the text is represented in a character set that does not
   use octets 13 and 10 for CR and LF respectively, as is the case for
   some multi-byte character sets, HTTP allows the use of whatever octet
   sequences are defined by that character set to represent the
   equivalent of CR and LF for line breaks. This flexibility regarding
   line breaks applies only to text media in the entity-body; a bare CR
   or LF MUST NOT be substituted for CRLF within any of the HTTP control
   structures (such as header fields and multipart boundaries).
"

-- 
Jason Voegele

"We believe that we invent symbols.  The truth is that they invent us."
    -- Gene Wolfe, The Shadow of the Torturer

[prev in list] [next in list] [prev in thread] [next in thread]