<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7638.1">
<TITLE>RE: [Web-SIG] WSGI and long response header values</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=2>Phillip J. Eby wrote:<BR>
&gt; Robert Brewer wrote:<BR>
&gt; &gt;So in my reading of HTTP, some code somewhere should introduce newlines in<BR>
&gt; &gt;longish, encoded response header values. I see three options:<BR>
&gt; &gt;<BR>
&gt; &gt;&nbsp; 1. Keep things as they are and disallow response header values if they<BR>
&gt; &gt; contain words over 75 chars that are outside the ISO-8859-1 character set<BR>
&gt; &gt;&nbsp; 2. Allow newline characters in WSGI response headers<BR>
&gt; &gt;&nbsp; 3. Require/strongly suggest WSGI servers to do the encoding and folding<BR>
&gt; &gt; before sending the value over HTTP.<BR>
&gt; &gt;<BR>
&gt; &gt;Any other solutions? I'd like to see 2 or 3 adopted (unless something<BR>
&gt; &gt;better comes along), so CherryPy can continue to support as much of the<BR>
&gt; &gt;HTTP spec as possible.<BR>
&gt;<BR>
&gt; #3 sounds most attractive, although I must confess I don't see how it<BR>
&gt; could be made to work, since the strings have to be encoded already,<BR>
&gt; unless you're saying that applications should encode them in chunks<BR>
&gt; of up to 75 characters, separated by spaces, and that the servers<BR>
&gt; should then fold the result.&nbsp; That would certainly seem like the<BR>
&gt; least-intrusive way to deal with it, as a slight clarification to<BR>
&gt; the spec, rather than any real *change* to the spec (and hence a new<BR>
&gt; version of it) as #2 would require.<BR>
<BR>
Bah. I knew I forgot a constraint in there (the strings have to be encoded by the app). Personally, I think the &quot;separate-by-spaces&quot; 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?<BR>
<BR>
<BR>
Robert Brewer<BR>
System Architect<BR>
Amor Ministries<BR>
fumanchu@amor.org<BR>
<BR>
[1] <A HREF="http://mail.python.org/pipermail/web-sig/2004-September/000749.html">http://mail.python.org/pipermail/web-sig/2004-September/000749.html</A></FONT>
</P>

</BODY>
</HTML>