At 06:31 PM 9/8/2006 -0500, Ian Bicking wrote: >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?
I believe RFC 2047 was originally created for email, where such a limit would actually matter. _______________________________________________ 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
