[Web-SIG] WSGI and long response header values
Ian Bicking
ianb at colorstudy.com
Sat Sep 9 01:31:55 CEST 2006
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 | ianb at colorstudy.com | http://blog.ianbicking.org
More information about the Web-SIG
mailing list