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/archive%40mail-archive.com