[Web-SIG] WSGI and long response header values

[Mark Nottingham]

My reading o WSGI was that multi-line headers should already be  
folding multi-line headers. If that's the case, what's the problem?

Cheers,


On 2006/09/08, at 2:02 PM, 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. I see three  
> options:
>
>  1. Keep things as they are and disallow response header values if  
> they contain words over 75 chars that are outside the ISO-8859-1  
> character set
>  2. Allow newline characters in WSGI response headers
>  3. Require/strongly suggest WSGI servers to do the encoding and  
> folding before sending the value over HTTP.
>
> Any other solutions? I'd like to see 2 or 3 adopted (unless  
> something better comes along), so CherryPy can continue to support  
> as much of the HTTP spec as possible.
>
>
> Robert Brewer
> System Architect
> Amor Ministries
> fumanchu at amor.org
>
> [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.2
> [2] http://www.w3.org/Protocols/rfc2616/rfc2616-sec2.html#sec2.2
> [3] http://www.rfc.net/rfc2047.html#s2
>
> _______________________________________________
> Web-SIG mailing list
> Web-SIG at python.org
> Web SIG: http://www.python.org/sigs/web-sig
> Unsubscribe: http://mail.python.org/mailman/options/web-sig/mnot% 
> 40mnot.net


--
Mark Nottingham     http://www.mnot.net/