> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, June 25, 2002 12:47 PM > To: Bob Showalter; [EMAIL PROTECTED] > Subject: Re: Displaying Problems > > > Ok, so here's the deal: > > "Some HTTP/1.0 software has interpreted a Content-Type header > without charset parameter incorrectly > to mean "recipient should guess." Senders wishing to defeat > this behavior MAY include a charset > parameter even when the charset is ISO-8859-1 and SHOULD do > so when it is known that it will not > confuse the recipient." > > By the way, I did not upper case the MAY and SHOULD, those > were that way in the doc which means they > were trying to emphasize them. I'd have to say that MAY > doesn't suggest that it is a requirement > for the content-type to work properly.
This is the relevant paragraph from 2.2 that I was going for: 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. Appendix 19.3 (Tolerant Applications) says, in part: The line terminator for message-header fields is the sequence CRLF. However, we recommend that applications, when parsing such headers, recognize a single LF as a line terminator and ignore the leading CR. But, section 3.7 says: 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). Note especially the last sentence. A nit-pick, to be sure. But "little things" like this cause programs to break all the time. Like I said, most (maybe all?) clients will accept what you wrote, but why not stick to the standard? Or, save all the trouble of grovelling through the RFC's and: print $q->header; Cheers. -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
