WebSocket algebra

[ptrdom]

References #954.

[ptrdom]

Since browser clients cannot interact with upgrade response/request, I though it would be best to explicitly separate webSocket and webSocketWithUpgrade. My thinking was that if an endpoint describes an interaction with headers and client is unable to provide them, it should not be able to communicate over said endpoint because it will be incompatible with server implementation. Slight issue with that approach is that browsers can implicitly pass some headers, like cookies, so server implementation can interact with them, but I am not sure if this implicit contract should be handled by the implementation.

Only upgradeRequestHeaders and upgradeResponseHeaders are provided because the spec seems to not put any importance into request/response entities.

@julienrf What do you think?

[julienrf]

I guess you mean request stream?

[ptrdom]

Terms such as request and response are not really used for anything but the upgrade in WebSocket docs that I have read, but there is a clear definition of client and server, so I thought I would use those terms.

[ptrdom]

After doing more research and thinking, I do not think that a stream is a correct abstraction to express data flowing through a WebSocket. Issue with streams is that they have a definition of an end, and WebSockets lack that - neither client nor server can communicate they either of them have stopped sending their messages, they can only close the connection. Inability to explicitly communicate these clearly separate behaviors puts a limit to the available expression and requires developers to come up with their own protocols. This makes WebSockets not as valuable as I thought before, and they are not a replacement for ChunkedEntities.