[Web-SIG] WSGI and long response header values

[Ian Bicking]

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