Now in English: My reading of WSGI was that implementations should already be folding multi-line headers.
Cheers, On 2006/09/09, at 5:18 PM, Mark Nottingham wrote: > 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 >> [EMAIL PROTECTED] >> >> [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@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/ > > _______________________________________________ > 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/mnot% > 40mnot.net -- Mark Nottingham http://www.mnot.net/ _______________________________________________ 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
