HTTP server message followed by junk closes before reply

[Trustin Lee]

Hi Wade,

On Fri, Feb 13, 2009 at 2:00 AM, Wade Poziombka <wpoziombka at hotmail.com> wrote:
>
> The situation is that a valid HTTP request is followed by some invalid data.
> The issue is that the HTTP codec notes decoding error before the reply for
> the first valid message is sent.

HttpMessageDecoder doesn't close a connection but just raises an
exception.  It's your exceptionCaught() handler method that closes the
connection immediately.  Therefore, you can make your handler not to
close the connection immediately but to postpone the closure until all
replies are sent.

> Now we don't want to single thread a socket but HTTP should honor the
> semantics of pipelining per RFC 2616.  If I read section "8.1.2.2
> Pipelining" properly it seems the server should reply to the first message
> then close the connection as a result of the second (although not explicitly
> called out).
>
> So the question is: can we receive notification that a connection SHOULD be
> closed then close after we've successfully sent the reply?

It's you who sends the reply, so you can easily decide whether to
close the connection or not after the reply is sent.  For example, you
could close the connection only after all replies are sent by
comparing the number of received normal requests and the number of
sent replies (i.e. maintain two counters per connection.)

> The larger question is how is pipelining supported in Netty?  How would one
> implement such support?

By using Netty, you are already doing pipelining because all
operations are asynchronous.  What needs to be done by a Netty user is
to implement protocol-specific constraints like the one you've
mentioned above.

I'm not sure I gave you the answer that you are looking for.  Please
feel free to ask more.

HTH,

— Trustin Lee, http://gleamynode.net/