--20cf307f378278b11d04a852f81f
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Yehuda Katz
Chief Technologist | Strobe
(ph) 718.877.1325


On Mon, Jul 18, 2011 at 4:19 PM, Clifford Heath <clifford.heath / gmail.com>wrote:

> Awesome stuff, Yehuda! I look forward to this making its way into a
> distribution.
>
> On 18/07/2011, at 4:44 PM, Yehuda Katz wrote:
>
>>        It is possible to read_nonblock from Net::HTTP response, evenf
>> the response has Transfer-Encoding: Chunked, keepalive or compression. This
>> makes it possible to use Net::HTTP in reactor libraries, instead of writing
>> whole new HTTP libraries for each kind of reactor
>>
>
> Does this also work with SSL?
>

Yes, assuming that the SSLSocket is, in fact, as polymorphic with Socket as
it claims to be.


> I recall seeing tweets from you questioning why reading from an SSL socket
> might be affected by whether the socket is currently writable - I assume
> you
> worked out that it's due to handshaking (which can be re-initiated at any
> point
> during an SSL connection). Even though the application layer is in a mode
> where it expects only to read, the handshake may require writing, and hence
> can block on write if the socket is currently stalled.
>

Yep! I worked it out. Thanks for the full explanation :)


>         Make the body parsers (regular body and chunked encoding)
>> separate objects that can support either blocking read or non-blocking read.
>>
>
> Heh. Now all we need is a revision of the Rack API to allow reading chunked
> bodies in a piecemeal fashion. They can already be sent, because the
> response body may be enumerable - though that's still not reactor-friendly.
>
> I use async_sinatra which hacks Thin to make the EventMachine reactor
> work correctly - see http://github.com/raggi's projects.
>
> Integration to support websockets is also high on the list of wants. You
> should
> ask on <mailto:socket_io@**googlegroups.com <socket_io / googlegroups.com>>
> how best to do that, since many
> of the interested parties hang out there.
>
>         Improving the tests to test non-blocking read across all kinds of
>> requests, and add tests for decompression
>>
>
> I'd be interested in how you test non-blocking for SSL connections, seeing
> as
> you need a custom SSL server which triggers renewed handshakes to do it
> properly...?
>

I'm currently simply using the tests that shipped with Net::HTTP in the
current stdlib, but I'd be very interested in ways to improve them.
Unfortunately, the current SSL tests are not as exhaustive as the other
tests (such as the ones that test gzip or Transfer-Encoding: chunked), but I
would like to improve that.


>
> Clifford Heath, Data Constellation, http://dataconstellation.com
> Agile Information Management and Design
> Skype: cjheath, Ph: (+61/0)401-533-540
>
>
>
>

--20cf307f378278b11d04a852f81f
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<br clear="all">Yehuda Katz<br>Chief Technologist | Strobe<br>(ph) 718.877.1325<br>
<br><br><div class="gmail_quote">On Mon, Jul 18, 2011 at 4:19 PM, Clifford Heath <span dir="ltr">&lt;clifford.heath / gmail.com&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

Awesome stuff, Yehuda! I look forward to this making its way into a distribution.<br>
<br>
On 18/07/2011, at 4:44 PM, Yehuda Katz wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  It is possible to read_nonblock from Net::HTTP response, even if the response has Transfer-Encoding: Chunked, keepalive or compression. This makes it possible to use Net::HTTP in reactor libraries, insteadf writing whole new HTTP libraries for each kind of reactor<br>


</blockquote>
<br>
Does this also work with SSL?<br></blockquote><div><br></div><div>Yes, assuming that the SSLSocket is, in fact, as polymorphic with Socket as it claims to be.</div><div>/div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

I recall seeing tweets from you questioning why reading from an SSL socket<br>
might be affected by whether the socket is currently writable - I assume you<br>
worked out that it&#39;s due to handshaking (which can be re-initiated at any point<br>
during an SSL connection). Even though the application layer is in a mode<br>
where it expects only to read, the handshake may require writing, and hence<br>
can block on write if the socket is currently stalled.<br></blockquote><div><br></div><div>Yep! I worked it out. Thanks for the full explanation :)</div><div>/div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  Make the body parsers (regular body and chunked encoding) separate objects that can support either blocking read or non-blocking read.<br>
</blockquote>
<br>
Heh. Now all we need is a revision of the Rack API to allow reading chunked<br>
bodies in a piecemeal fashion. They can already be sent, because the<br>
response body may be enumerable - though that&#39;s still not reactor-friendly.<br>
<br>
I use async_sinatra which hacks Thin to make the EventMachine reactor<br>
work correctly - see <a href="http://github.com/raggi&#39;s" target="_blank">http://github.com/raggi&#39;s</a> projects.<br>
<br>
Integration to support websockets is also high on the list of wants. You should<br>
ask on &lt;mailto:<a href="mailto:socket_io / googlegroups.com" target="_blank">socket_io@<u></u>googlegroups.com</a>&gt; how best to do that, sinceany<br>
of the interested parties hang out there.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  Improving the tests to test non-blocking read across all kinds of requests, and add tests for decompression<br>
</blockquote>
<br>
I&#39;d be interested in how you test non-blocking for SSL connections, seeing as<br>
you need a custom SSL server which triggers renewed handshakes to do it<br>
properly...?<br></blockquote><div><br></div><div>I&#39;m currently simply using the tests that shipped with Net::HTTP in the current stdlib, but I&#39;d be very interested in ways to improve them. Unfortunately, the current SSL tests are not as exhaustive as the other tests (such as the ones that test gzip or Transfer-Encoding: chunked), but I would like to improve that.</div>

<div>/div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><font color="#888888">
<br>
Clifford Heath, Data Constellation, <a href="http://dataconstellation.com" target="_blank">http://dataconstellation.com</a><br>
Agile Information Management and Design<br>
Skype: cjheath, Ph: <a href="tel:%28%2B61%2F0%29401-533-540" value="+61401533540" target="_blank">(+61/0)401-533-540</a><br>
<br>
<br>
<br>
</font></blockquote></div><br>

--20cf307f378278b11d04a852f81f--