[Web-SIG] WSGI and long response header values

[Phillip J. Eby]

At 06:31 PM 9/8/2006 -0500, Ian Bicking wrote:
>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.
>
>Realistically, isn't this an artifact of a time when things like
>line-length mattered a lot more?  That is, does any HTTP client actually
>care about or rely on the 75 character limit?

I believe RFC 2047 was originally created for email, where such a limit 
would actually matter.