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

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 UTC