[Web-SIG] WSGI and long response header values

[Robert Brewer]

Phillip J. Eby wrote:
> Robert Brewer wrote:
> >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.
> 
> #3 sounds most attractive, although I must confess I don't see how it
> could be made to work, since the strings have to be encoded already,
> unless you're saying that applications should encode them in chunks
> of up to 75 characters, separated by spaces, and that the servers
> should then fold the result.  That would certainly seem like the
> least-intrusive way to deal with it, as a slight clarification to
> the spec, rather than any real *change* to the spec (and hence a new
> version of it) as #2 would require.

Bah. I knew I forgot a constraint in there (the strings have to be encoded by the app). Personally, I think the "separate-by-spaces" cure is worse than the disease. I also finally found the only other discussion of this issue [1] and ... I wish we had allowed folding from the beginning. Given the obscure nature of this need, I would rather have had all WSGI implementations be 99% WSGI-compliant (by ignoring folding) than 99% HTTP-compliant (by not allowing folding). We could have improved the former number without changing the spec, but not the latter. Meh. Water under the bridge. Maybe in 1.1?


Robert Brewer
System Architect
Amor Ministries
fumanchu at amor.org

[1] http://mail.python.org/pipermail/web-sig/2004-September/000749.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/web-sig/attachments/20060908/42955f74/attachment.html