Subject: Re: [hybi] web socket protocol in "last call"?

From: Ian Hickson <[email-masked]>
Date: Sun, 1 Nov 2009 20:37:05 +0000 (UTC)

On Sat, 31 Oct 2009, Mike Dierken wrote:
>
> I had one small question about "[..] the latency involved in having to 
> establish new TCP connections for each HTTP message is non-existent in 
> WebSocket". I know that you know that persistent HTTP 1.1 connections 
> reduce the number of times an open/close of a connection would occur, so 
> I was curious what's actually happening that connections are created for 
> each request. (Not that I think the answer will or should change 
> anything to do with WebSockets, just a curiousity sort of thing).

Non-idempotent messages have to be sent using POST, which cannot be 
pipelined in practice.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

---

From: Jamie Lokier <[email-masked]>
Date: Sun, 1 Nov 2009 21:34:57 +0000

> Non-idempotent messages have to be sent using POST, which cannot be 

There are several problems with HTTP pipelining, which make it
unusable for POST and other non-idempotent request.

They are design faults in HTTP pipelining, due to the way TCP behaves
when a socket is closed; they are not intrinsic problems.

Even re-using a _persistent_ connection for POST is fraught because
the server might close the connection, and the client cannot detect
whether it should re-send the request.

There is something else quite non-obvious.  Sending a POST request
_followed_ by pipelining a second (idempotent) request can cause the
POST's response to be lost or truncated.

That's because the server may close the socket after the POST
response.  After that, the second request being in flight can cause
the server TCP to send RST packets which can cause the client to drop
what it has already received.

(Apache has a workaround for this; look up "lingering close", but it's
not described in the HTTP RFCs).

Ironically in these cases, TCP makes a connection less reliable :-)

As far as I can tell, WebSocket seems to have the same problem, which
is unfortunate as pipelining small requests over WebSocket seems like
a very natural thing to do.

Applications can work around it in various ways (e.g. using unique
request ids to detect+drop duplicates, and/or using orderly close
markers), but this is probably unfamiliar territory for most web
application writers.  Most authors will be familiar with AJAX/HTTP,
avoids these issues for POST requests by just not using pipelining.

-- Jamie

---

From: Lisa Dusseault <[email-masked]>
Date: Mon, 2 Nov 2009 16:38:15 -0800

On Fri, Oct 30, 2009 at 7:35 PM, Ian Hickson <[email-masked]> wrote:

>
> I must admit to being more interested in technical soundness than
> consensus. However, if we are to base things on consensus, then we need an
> objective definition of consensus, so that it can be determined when we do
> or do not have consensus. Is there such a definition?
>
>
It's simpler for WG documents, where the WG chair is responsible for
determining WG consensus.  Unless it turns out that there's an opposite
consensus outside the WG, the WG consensus is generally not overturned by
individual feedback in Last Call when IETF consensus is confirmed.

For individual proposals, it's tougher to determine consensus but the AD
responsible for sponsoring the document is responsible for judging consensus
based on all the feedback she's aware of.

That's objective only in the sense that somebody is objectively defined to
make the subjective call, but that's the heart of the matter.

It helps our transparency to make consensus calls explicit, if there are
individual issues that can be teased out for such a call -- particularly if
people can vote not only for or against, but also for "dealbreaker" and "not
a dealbreaker".

Lisa