WebSocket2

https://lists.w3.org/Archives/Public/ietf-http-wg/2016JulSep/0615.html

> I drafted up a rough RFC to support WebSocket2
> https://github.com/vans163/websocket2-drafts/blob/master/websocket2-over-http2.txt


( Very quick reading )

I'm not sure that is this problem or not 

https://github.com/vans163/websocket2-drafts/blob/master/websocket2-over-http2.txt

> 4.  Data Framing
> 
>    Once a handshake has been successfully completed the remote endpoints
>    can begin to send data to each other.  Data is sent using the HTTP/2
>    transport layer fully adhering to DATA Frames, Section 6.1 [RFC7540].
>    WebSocket2 has its own encapsulated framing protocol that is not to
>    be confused with HTTP/2 DATA Frames.


So these websockect frames are inside of HTTP/2 DATA frame
payload.

> 3.1.  Client Handshake Request

and

> 3.2. Server Handshake Reply

These use HTTP/2 HEADERS frame.



1) So consider situation

+---------------+                     +-----------+                   +--------+
|  Web          |  ---- HTTP/2 ---->  |  proxy    | ---- HTTP/2 ----> | origin |  
|  browser      |                     |           |                   | server |
+---------------+                     +-----------+                   +--------+
 

"Web server" and "origin server" supports 
"WebSocket2 over HTTP/2" and handshake 
with headers frames succeed.

"proxy" does not know about
"WebSocket2 over HTTP/2".


There there start using of HTTP/2 DATA
frames. These usage however differ
very much from usage of http -request
and response.

Perhaps "proxy" tries cache response.

Perhaps there should be some method
to verify that also "proxy" supports
"WebSocket2 over HTTP/2".

One method is to use HTTP/2 SETTINGS -frame.
(Another method is to use new frame
 type on HTTP/2. )


2) One note

> 3.2. Server Handshake Reply

If "origin server"  doe snot know about
"WebSocket2 over HTTP/2", this looks like 
regular request for page "/ws2".
This can still succeed.

>   The server MUST send ONLY ONE of the advertised compression methods
>   or exclude the websocket2-compression header from the reply,
>   signaling that no compression will be used.

Wgen websocket2-compression is excluded, client
gets /ws2 -resource with
:status: 200

and client does not know is this supporting 
"WebSocket2 over HTTP/2" or not.


Or have I missed something?

/ Kari Hurtta

Received on Saturday, 1 October 2016 05:17:32 UTC