Robert Brewer wrote: > PEP 333 says: > > "Each header_value must not include any control characters, including > carriage returns or linefeeds, either embedded or at the end. (These > requirements are to minimize the complexity of any parsing that must be > performed by servers, gateways, and intermediate response processors > that need to inspect or modify response headers.)" [1] > > That's understandable, but HTTP headers are defined as (mostly) *TEXT, > and "words of *TEXT MAY contain characters from character sets other > than ISO-8859-1 only when encoded according to the rules of RFC 2047." > [2] And RFC 2047 specifies that "an 'encoded-word' may not be more than > 75 characters long...If it is desirable to encode more text than will > fit in an 'encoded-word' of 75 characters, multiple 'encoded-word's > (separated by CRLF SPACE) may be used." [3] This satisfies HTTP header > folding rules, as well: "Header fields can be extended over multiple > lines by preceding each extra line with at least one SP or HT." [1, again] > > So in my reading of HTTP, some code somewhere should introduce newlines > in longish, encoded response header values.
Realistically, isn't this an artifact of a time when things like line-length mattered a lot more? That is, does any HTTP client actually care about or rely on the 75 character limit? -- Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com