Re: [hybi] Random Responses

[Jamie Lokier <[e-mail]>]

Mark Lentczner wrote:
> Then I mis-replied. I should have said that we have a need for full- 
> duplex request-response -- either side can spontaneously send a  
> request message, and either side can, when ready, reply to a prior  
> request.

I agree.  HTTP requests and responses are easily distinguished, so
it's quite simple to accept either.

Recovery behaviour when the connection disappears is tricky if you
have HTTP-like requests.

Right now, clients tend to send non-idempotent requests (i.e. POST) on
a new connection, because if you send to a persistent connection, and
the socket reports an error, you don't know if the request was
received and processed and then the network died, or if the server
timed out the persistent connection and closed it while you were
sending the request.  You can't tell the difference, and it's unsafe
to repeat the request, so you use a new connection.

With a bidirectional connection, typically the initiating client sets
everything up, then the server is able to send a request - but this is
analogous to sending a request over a persistent HTTP connection.

In general with this sort of network protocol, you define a recovery
process - or assume the system will recover naturally - or don't have
non-idempotent requests coming from the server end.  But if we're
claiming to support HTTP in both directions, then we need to define if
the server is allowed to send POST requests and such to the client,
and what to do realistically on seeing network errors.

> Only the establishment in WebSocket is addressed via URL.  In rHTTP  
> each request can be addressed by URL.  This is useful as it is a very  
> common piece of meta-data that applications want. For example, using  
> WebSockets, for any complex page, an application is almost certainly  
> going to want a way to address which widget on the page is the  
> intended recipient of the event. Hence, each application is going to  
> have to devise an addressing scheme, and more importantly, a method of  
> encoding that address in the simple string event.

I agree that the URL address space is a very common useful piece of
metadata.  There is so much built around it now; it makes sense to
provide applications with that.

I also agree that HTTP message frame parsing is readily available, and
easy to implement when it isn't.

-- Jamie