W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2016


From: Kari hurtta <hurtta-ietf@elmme-mailer.org>
Date: Sat, 1 Oct 2016 08:16:59 +0300 (EEST)
To: HTTP working group mailing list <ietf-http-wg@w3.org>
CC: Van Catha <vans554@gmail.com>, Kari hurtta <hurtta-ietf@elmme-mailer.org>
Message-Id: <20161001051700.245FA10F65@welho-filter1.welho.com>

> 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 


> 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

> 3.1.  Client Handshake Request


> 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

This archive was generated by hypermail 2.3.1 : Saturday, 1 October 2016 05:17:36 UTC