Re: Announcing moonslice luv*, and lhttp_parser

[Coda Highland <chighland@...>]

On Wed, Oct 10, 2012 at 1:49 PM, Petite Abeille
<petite.abeille@gmail.com> wrote:
>
> On Oct 10, 2012, at 10:21 PM, Tim Caswell <tim@creationix.com> wrote:
>
>> I could have it wrong.  I still don't fully understand keepalive.
>> I've love to get feedback from people who understand it better.  The
>> module is a sample more than anything, but I do intend for it to be
>> production quality.  http://luvit.io/ is running on moonslice on top
>> of luvit right now.
>
>
> Mark Nottingham's REDbot is a good starting point for sanity check:
>
> http://redbot.org/?descend=True&uri=http://luvit.io
>
>> It supports either a string or a readable stream.  A readable stream
>> is pretty simple.  It's any table that has a :read()(callback) method.
>>
>> What would a "plain function as body" look like?  If the data is
>> available syncronously then just use a string, if you need to stream
>> over time, use a stream.  The simple stream API I designed supports
>> "backpressure" so you don't get into situations when you're reading a
>> large file from a local disk and writing to some slow mobile client
>> and end up buffering everything in ram.  The simplest interface I
>> could think of is readFunction(callback(err, data)), but I find a
>> table with a continuable version of the read is easier to work with.
>> For example using coroutines, piping from a file to a socket is as
>> simple as:
>>
>>    repeat
>>      local chunk = await(input:read())
>>      await(outout:write(chunk))
>>    while chunk
>
> A function based one could look like this:  return function aFile:read( 1024 ) end
>
> The consumer part of it, something like this:
>
> for aChunk in aContent do
>   -- "do the needful"
> end
>
>
>> That's how I read the spec, and it seems to work.  My clients (curl
>> and various browsers) seem to like it.  There is a change I misread
>> the spec though.
>
> The problem with browsers is that they tend to over compensate for a rather hostile environment… so they are not necessarily the best tool for testing protocol compliance…. perhaps try a couple of simple http libraries… for example, luaSocket sports a plain http client… ditto for stock python, ruby & co…
>
>
>

I've been through the wringer a couple times writing an HTTP server
myself over in the C++/Qt world; QxtWeb supports pretty much
everything in the HTTP/1.0 and HTTP/1.1 specs, as well as HTTP/0.9 as
far as its lack of specification can manage. The differences in the
protocol versions can be subtle but problematic, especially with
regards to keepalive. Do be careful. I'd show you my solutions but
they may not be readable to someone who's not already well-versed in
the tools I'm using.

/s/ Adam