On Fri, Nov 27, 2009 at 12:20 PM, P.J. Eby <span dir="ltr">&lt;<a href="mailto:pje@telecommunity.com">pje@telecommunity.com</a>&gt;</span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>&gt; 1. The &#39;readline()&#39; function of &#39;wsgi.input&#39; may optionally take a size hint.<br>


<br>
Already de-facto required. Leaving it out helps no-one. KEEP.<br>
</blockquote>
<br></div>
Fair enough, since it&#39;s a MAY.  On the other hand, because it&#39;s a MAY, it actually *helps* no-one, from a spec compatibility POV.  (That is, you have to test whether it&#39;s available, so it&#39;s no different than it not being in the spec to begin with.)<br>


<br>
So, putting it in doesn&#39;t *hurt*, but neither does it *help*...  so I lean towards leaving it to 2.x, where it can actually help.</blockquote><div><br></div><div>I think it was meant to be a must.  The *caller* MAY pass in a size hint, the implementor MUST implement this optional argument.  This is the de-facto requirement.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
&gt; 2. The &#39;wsgi.input&#39; must provide an empty string as end of input stream marker.<br>
<br>
I don&#39;t think this will be a problem. What would WSGI middleware do to break this requirement?<br>
</blockquote>
<br></div>
It could be reading the original input stream, and replacing it with another one.  Not very common I would guess, but it&#39;s still possible for a piece of perfectly valid 1.0 middleware to fail this requirement for 1.1, leading to the condition where you really can&#39;t tell if you&#39;re running valid 1.1 or not.</blockquote>

<div><br></div><div>Middleware sometimes does this, but any time it does this it always replaces the input stream with something truly file-like, e.g., StringIO or a temp file.  Nothing but servers really hands sockets around, and sockets are the only objects I&#39;m aware of that don&#39;t act quite like a file.</div>

<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It was only put in in the first place so that CGI adapters could pass through their input stream (which may not ever provide an EOF) without having to wrap it. I agree that was a mistake, and should be corrected.<br>
</blockquote>
<br></div>
I agree...  but only in 2.x.<div class="im"><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
&gt; 3. The size argument to &#39;read()&#39; function of &#39;wsgi.input&#39; would be optional and if not supplied the function would return all available request content. Thus would make &#39;wsgi.input&#39; more file like as the WSGI specification suggests it is, but isn&#39;t really per original definition.<br>


<br>
This one could be a problem with middleware, and that feature shouldn&#39;t ever be used, in any case: reading into memory an arbitrary amount of data from a client is not a good thing to encourage. OMIT.<br>
</blockquote>
<br></div>
Agreed -- even in 2.x it&#39;s questionable if not harmful.</blockquote><div><br></div><div>Well, we need a way to handle content of unknown length, but if the file terminates with &#39;&#39; then this isn&#39;t that important.</div>

<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
&gt; 4. The &#39;wsgi.file_wrapper&#39; supplied by the WSGI adapter must honour the Content-Length response header and must only return from the file that amount of content. This would guarantee that using wsgi.file_wrapper to return part of a file for byte range requests would work.<br>


<br>
Given item #6, I suppose this is actually just a matter of efficiency, in case the file wrapper is sent to a middleware rather than directly to the wsgi gateway? If it goes directly to the gateway, that can of course stop reading by itself. ?undecided?<br>


</blockquote>
<br></div>
I don&#39;t really see how this one helps anything in 1.x, and so lean towards leaving it out.</blockquote><div><br></div><div>I don&#39;t really understand this either, unless it was handling range responses as well.  Content-Length alone isn&#39;t very interesting in this case. </div>

<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
&gt; 5. Any WSGI application or middleware should not return more data than specified by the Content-Length response header if defined.<br>
<br>
As long as this is meant as &quot;SHOULD&quot;, that&#39;s fine. It&#39;s not actually a requirement, but rather a suggestion of best practices. KEEP.<br>
<br>
&gt; 6. The WSGI adapter must not pass on to the server any data above what the Content-Length response header defines if supplied.<br>
<br>
This is already required by HTTP. If the WSGI gateway doesn&#39;t make this happen somehow, it&#39;s generating invalid HTTP and that&#39;s a bug. Okay to clarify in the spec to ensure people don&#39;t miss the requirement when implementing. KEEP.<br>


</blockquote>
<br></div>
Good points - I agree with these two, and they can be considered 1.0 clarifications as well.  After the first four (which I see no reason to include) I was probably a little over-inclined to throw these two out (especially since I was reading the &quot;should&quot; above as a &quot;must&quot;, per your proposal).</blockquote>

<div><br></div><div>In this context, maybe 4 is just an extension of these?  Put 4 after 6 and maybe it&#39;ll seem more obvious...?</div></div><br>-- <br>Ian Bicking  |  <a href="http://blog.ianbicking.org">http://blog.ianbicking.org</a>  |  <a href="http://topplabs.org/civichacker">http://topplabs.org/civichacker</a><br>