Hi users_at_grizzly,
like Patrick Julien in mid december, I'd like to point out that the
current state of affairs with Grizzly HTTP pipelining is somewhat
unsatisfactory.
Jean Francois said, back then, that Grizzly simply doesn't support
pipelining, and I've found a second post in which he states that,
quote: "We aren't supporting HTTP pipelining as this is not mandatory,
and messy to implement."
The HTTP 1.1 spec is, however, quite clear about this (section 8.1.2.2):
"A client that supports persistent connections MAY "pipeline" its
requests (i.e., send multiple requests without waiting for each
response). A server MUST send its responses to those requests in the
same order that the requests were received."
I'm sure the RFC would have said "A server MUST only send the response
to the last of those requests and MAY send the others in between, and
if so, MUST send them in the same order that the requests were
received" -- if that's what the intention was.
Now, nobody likes specifications that force messy implementations, and
I wouldn't insist on pipelining as a feature -- but the way it's
handled right now should be considered a bug. Being a practical
person, I wouldn't mind all this if I could make Grizzly/Glassfish
behave in a way that clients that do use pipelining can handle.
IIS, which also doesn't support pipelining, seems to be able to do
this, or is so common that clients just know that IIS is not fully
implementing HTTP 1.1 there.
Currently, when using a Glassfish-powered site (try txtr.com) with a
client that has pipelining enabled (most Opera versions out there, for
instance), things are just badly broken.
Is there a way to tell clients not to use pipelining that I'm not
aware of? Or should this be fixed in Grizzly? (Maybe responding to the
first request and then closing the connection when a second one comes
in without the first one fully answered would be a hotfix -- better
than quietly doing the wrong thing, anyway?)
Thanks for listening & have a nice weekend everybody,
rv