Re: WebSocket2

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?

I am thinking using SETTINGS frames would be too complex, as that would
require baking WebSocket2 directly into HTTP/2, the way it is now,
WebSocket2 should run over HTTP/2 with minimal resistance since we do not
introduce new settings or HTTP/2 frame types.  HTTP/2 was designed from the
very beginning to not support 2 way streaming like websocket provides
currently for HTTP/1.1.  I think the resistance would be great if adding
WebSocket2 requires adding to the actual HTTP/2 specification.

A side option is to make WebSocket2 its own connection, for example ws2 as
the ALPN type when connecting to a server and to create the connection the
server would send a Alt-Svc with the host+port+other params.  This method
was proposed already, I recall reading it in an RFC.  I think the problem
with this method is now you will have more than 1 connection per server as
well as tons of duplication during the peer handshake. The benefit to this
method is it would be totally separate from HTTP/2, and you would be able
to have a server that strictly only speaks WebSocket2.  I think the
complexity of adoption to do it this way is much higher.


If origin server does not know about WebSocket2 and the request succeeds
that is indeed a problem.  Perhaps the server can reply with the error
header always like websocket2-error: okay; in the case when the WebSocket2
negotation was a success. This way an origin server without WebSocket2 will
reply with 200, and the client will see there is no websocket2-error: okay;
header and promptly notify the client that WebSocket2 negotiation failed.

One problem I find is I have not come across anything in HTTP/2 to make the
handshake smooth except for Alt-Svc header, but what Alt-Svc was designed
for does not fit the use case for WebSocket2.  For example Alt-Svc can only
be sent by a server, a client cannot request an Alt-Svc.















On Sat, Oct 1, 2016 at 1:16 AM, Kari hurtta <hurtta-ietf@elmme-mailer.org>
wrote:

> 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
>
>
>