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

Henrik Nordström wrote:
> fre 2010-05-14 klockan 18:33 +0100 skrev Jamie Lokier:
> 
> > It is possible to implement servers where the response is an
> > incremental function of the request, and if it worked reliably, that
> > would actually be useful.
> 
> There is applications operating in this manner, but the HTTP transport
> isn't well suited for this as you have no control over any buffering
> done by intermediary servers or even clients http frameworks operate.
> 
> > As far as I can tell, it would be within the HTTP specs if a new
> > client was deliberately made which supported bidirectional streaming
> > POSTs over a single connection, and a new server took advantage of
> > that when it knew the client supported it.
> 
> Yes, and such clients do exists, even if most select to either do it
> over an SSL connection or by using two parallell requests.
> 
> > Then the sticking point would be what proxies do.
> 
> Depends on the purpose of the proxy.
> 
> > That requirement says nothing about *non-error* codes.  What part of
> > accepting those while continuing to send the request is broken?  Or
> > alternatively of not accepting those?
> 
> None, other than me reading a bit too quickly.
> 
> > Do you think the above idea, of a client supporting it and a server
> > making use of it if it knows the particular client supports it, would
> > work now?  That would halve the number of connections needed for
> > comet-style interactions.
> 
> It will work in most environments, but you will find networks where
> intermediary proxies do buffer considerable amount of data or which may
> even serialize it down to request->response pattern.  HTTP does not
> provide any guarantee that full duplex communication will work.

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"?

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.

And if it is unreliable enough - whether that's due to proxies or
clients, or both.  If I knew the proxies were fine and the
difficulties were due to client buffering, then I would know it's safe
to use with clients that I recognise as being ok with it.

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.

-- Jamie

Received on Wednesday, 19 May 2010 02:59:42 UTC