Re: WebSocket2

On 2/10/2016 7:20 a.m., Van Catha wrote:
> Correct. Because HTTP2/ DATA frames essentially provide flow control only
> and WebSocket2 frames need to be delivered in full to the underlying client
> API. A single WebSocket2 frame could be broken up into multiple HTTP/2 Data
> frames depending how large the MAX negotiated size is by the endpoints.
> 
> The proxy problem circles around back to the implementation. Perhaps a
> header in the request could be included saying to not cache anything, if
> the proxy caches things well its the proxies fault.  Also if the proxy is
> not aware of WebSocket2 this should not matter, the proxies job is to
> forward everything as it came.  As long as the proxy would forward the
> websocket2-[version|compression] headers to the server and forward what the
> server replies with there should be no problems.  Again if the proxy is
> "smart" and decides to cache the response (which did not specify any
> headers related to caching) its the proxies fault.  To be more direct the
> response may be forced to include headers specifically instructing nothing
> should be cached.  Does this work?

If the WebSocket message transmits over HTTP and does not prohibit
caching it can expect to be cached as per the default cacheability of
the method used. Caching is a fundamental part of HTTP that has to be
accounted for and looking at DATA frames alone is not sufficient for that.

We had CONNECT method baked into the WS v1 handshake for exactly this
reason.

Amos

Received on Sunday, 2 October 2016 05:40:40 UTC