<!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>James Y Knight wrote:<BR>
&gt; I don't see what's wrong with encoding with the 75-char<BR>
&gt; word-limit, separating &quot;words&quot; by spaces, *without* newlines.<BR>
&gt; If the server feels like folding a long line into two, it<BR>
&gt; can do so, but it's perfectly within its rights not to,<BR>
&gt; and AFAIK nothing at all requires it to ever fold, given<BR>
&gt; that a folded line is exactly equivalent to a single space.<BR>
&gt; Line folding is one of those things that really has no purpose<BR>
&gt; in HTTP besides to write out the examples in the RFCs.<BR>
<BR>
And I just said:<BR>
&gt; I was hoping that too, but the server is actually *not*<BR>
&gt; within its rights to leave out the newlines, because that<BR>
&gt; restriction is actually part of RFC 2047 (MIME headers),<BR>
&gt; not the HTTP spec.<BR>
<BR>
Bah. Of course, any HTTP server or proxy is free to unfold headers. So maybe the dream of arbitrary header values via MIME-encoding is broken from the get-go.<BR>
<BR>
<BR>
Robert Brewer<BR>
System Architect<BR>
Amor Ministries<BR>
fumanchu@amor.org<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>