W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2010

Re: Concurrent non-error response disallowed. ("clarification of 7.2.2. Monitoring Connections for Error Status Messages")

From: Henrik Nordström <henrik@henriknordstrom.net>
Date: Wed, 19 May 2010 09:39:52 +0200
To: Jamie Lokier <jamie@shareable.org>
Cc: ietf-http-wg@w3.org
Message-Id: <1274254792.6296.7.camel@localhost.localdomain>
ons 2010-05-19 klockan 03:59 +0100 skrev Jamie Lokier:

> It's true, but isn't that less to do with bidirectional streaming, and
> more of a general "can't rely on unidirectional streaming either"?

Correct.

> Elsewhere I've failed to get a straight answer as to whether
> (unidirectional) streaming parts of a response (hanging-GET style) is
> unreliable enough, these days, to warrant sending each part in a whole
> response of its own.

You will find networks where this do not work.

But as with most things it will work fine for the majority of users.

> And if it is unreliable enough - whether that's due to proxies or
> clients, or both.

proxies mainly.

> I've seen a hanging-GET style specification that did streaming, but
> followed every part with some arbitrary looking number of space
> characters to force it through - no explanation of why that number,
> whether it's believed to always be enough from experience, or which
> proxies or clients needed it, of course.

Probably to escape from TCP send segment buffering optimization either
in the server itself or possibly proxies along the path. But all proxies
I know by default disable such buffering to support streaming responses.

Regards
Henrik
Received on Wednesday, 19 May 2010 07:40:47 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:18 GMT