Re: [MINA 3] HTTP protocol improvement

[Emmanuel Lécharny]

Le 2/9/13 1:32 PM, Jeff MAURY a écrit :
> I don't think Antlr is of great help. There are a lot of protocol specific
> to process (encoding of header, URL escaping,...) that will not be done by
> an Antlr generated parser.
I think that an antlr parser could most certainly handle all those
cases, but I'm afraid that it could be a bit more complex than just
doing it by and, with a state machine...
> I don't see the relation with the thread model and I think it's allowed to
> send a new request without the previous one being fully received: it is
> called HTTP pipelining if I remember correctly
A user can perfectly send many concurrent HTTP requests from a browser :
this is even configurable on every browser, to speed up the load of a
page wih may images.

Now, those concurrent requests - assuming that the client can send more
than one request to a server, though more than one socket, leads to
interesting complcation we have to be aware of.

Here, I was more thinking about the fact that when a client sends many
HTTP request without waiting for the response, then those requests will
be handled one after the other on the server. If we add an executor
*after* the decoder, we may process the requests concurrently.

But anyway, these are considerations that could be discussed further,
once we have a decent codec.
>
> +1 for a full HTTP review as each time I used it, I found some problems
> related to the full respect of the HTTP specs
Ok, sounds good to me.


-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com 

Re: [MINA 3] HTTP protocol improvement

[Jeff MAURY]

I don't think Antlr is of great help. There are a lot of protocol specific
to process (encoding of header, URL escaping,...) that will not be done by
an Antlr generated parser.
I don't see the relation with the thread model and I think it's allowed to
send a new request without the previous one being fully received: it is
called HTTP pipelining if I remember correctly

+1 for a full HTTP review as each time I used it, I found some problems
related to the full respect of the HTTP specs

Regards
Jeff



On Sat, Feb 9, 2013 at 12:34 PM, Emmanuel Lécharny wrote:

> Hi guys,
>
> we currently have a pretty rough HTTP codec in MINA 3, based on regexp.
> It's good enough for test purposes, but I wonder if it wouldn't be a
> good idea to start working on somethng more robust and faster too ?
>
> I have gathered all the HTTP 1.1 grammar in one document, that could be
> used as a base for a faster code (see the http.g file).
>
> I don't know if we should use antlr or write a parser by hand. I think
> that using antlr would be easier, but will be at least 2 times slower
> than doig it by hand.
>
> Another aspect is that we want this parser to be stateless, so that
> means we have to keep a state in the session.
>
> Last, not least, we have to think about the thread model : if we
> consider that a user can only send one rrequest after the other (ie, the
> second request can only be processed when the previous one has been
> completed), then we have no issue. We can go a bit farther, and consider
> that once we have decoded a full request, then we can accept another
> one, whatever the server has to do with the previsous request : the
> ncoming requests are all serialized until they are decoded, then we
> spawn a new thread to process the HTTP request.
>
> wdyt ?
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
>


-- 
Jeff MAURY


"Legacy code" often differs from its suggested alternative by actually
working and scaling.
 - Bjarne Stroustrup

http://www.jeffmaury.com
http://riadiscuss.jeffmaury.com
http://www.twitter.com/jeffmaury