[Web-SIG] WSGI and long response header values

[Robert Brewer]

James Y Knight wrote:
> On Sep 8, 2006, at 7:22 PM, Robert Brewer wrote:
> > 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?
> 
> I don't see what's wrong with encoding with the 75-char
> word-limit, separating "words" by spaces, *without* newlines.
> If the server feels like folding a long line into two, it
> can do so, but it's perfectly within its rights not to,
> and AFAIK nothing at all requires it to ever fold, given
> that a folded line is exactly equivalent to a single space.
> Line folding is one of those things that really has no purpose
> in HTTP besides to write out the examples in the RFCs.

I was hoping that too, but the server is actually *not* within its rights to leave out the newlines, because that restriction is actually part of RFC 2047 (MIME headers), not the HTTP spec:

"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."


Robert Brewer
System Architect
Amor Ministries
fumanchu at amor.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/web-sig/attachments/20060908/3d18afc8/attachment.htm