Re: WebSocket2

Amos Jeffries

> I believe the relevant expert(s) are reading this thread already.
>
> That is the more likely reason a negotiated extension is unlikely to
> happen. If it is not needed at all, then it might be easier not to bother.

I was not aware using a custom method was allowed, if that is the case,
CONNECT, UPGRADE, WS2, etc all work.


Kari Hurtta

> Well, I think the following would work and avoid SETTINGS:
>
> -> :method ws2
> -> :scheme wss
> -> :authority foo.example
> -> :path /bar
> -> <optional extra parameters, e.g. compression support>
> <- :status 200
> <- sec-ws2-ack 1
> <- <optional negotiated extras>

> And unsuccessful request would elict a HTTP response code:
> - 405 for endpoint not supporting Websockets2
> - 404 for endpoit does not exist
> - 403 for "I don't want to talk to you"
> - 401 for "identify yourself".

> As for 301/302/307/308 responses, redirect across schemes would be
> error (channel open failed). And one would need to be very careful about
> redirects out of server's authority (probably channel open failed).

This looks really optimal.

> ( if :scheme is wss, then proxy gets
>
>   :method = CONNECT
>   :authority = foo.example:443
>
>   and there is no :scheme or :path
> )

Again a good option.

--------------


About Proxies:
~
I assumed the concern was with forward / reverse proxies like NGINX
forwarding http/2 to http.

Afaik HTTP/2 browser only allow using TLS, so a HTTP transparent proxy will
not be able to "proxy" anything unless the reverse proxy serves a MITM
certificate.  I do not think this is a common enough use case.
~


About Settings frame:
~
If the idea behind this is to make WebSocket2 compatible over HTTP/1.1 then
that is part of the reasons why I advocate to avoid SETTINGS frame.

If WebSocket2 can be negotiated and used in such a way to avoid locking to
the transport layer, it can easily be used in HTTP/1.1 as well.

An option is to define a WebSocket2 spec RFC, then define individual RFCs
for WebSocket2 over X|Y|Z.
~


About New HTTP/2 Frame Type:
~
If a new frame type is to be introduced it severly complicates things, as
anything WebSocket2 related to this frame is not applicable. This new frame
type would fulfill the role of data streaming.  It should be applicable not
only to websockets2 but also to HTTP/1.1's Chunked-Encoding.

There would be no standard on using this new frame type, and
implementations that build off HTTP/2 such as QUIC would be left in the
dark on how to use it.

Also HTTP/1.1 would have no chance at getting WebSocket2. If such a need
were to ever exist, currently I am not considering it at any priority level.
~


About Payload Length optimizations:
~
There is a particular use case where if you sent lots of small messages
that end up in a single HTTP/2 DATA frame or a single system level packet,
there is an overhead of 3 extra bytes and 6 for LZ4 compressed payloads.

Using flags to specify how many bits the payload size is we can remove some
flexibily but also decrease final system level packet size:

RSV now becomes 6 bits.
TYPE now becomes 2 bits. We have room for 1 more frame type.

Last 2 RSV bits are Payload Length. 0 for no length (error frame), 1 for 1
byte, 2 for 2 byte, 3 for 4 byte.

Second last 2 RSV bits are for compression.   0 is no compression, 1 is
lz4, 2 is deflate.  3 is reversed.

First 2 RSV bits are decompressed payload size in the case of LZ4 or
reserved for future use by compression.

This also has the benefit of not requiring to keep a serverside state for
LZ4 compressed payloads; for anyone that would have a sane usecase for that
:)


Before a small LZ4 Text frame looked like this:
b00000000 0x00 0x00 0x00 0x09 0x00 0x00 0x00 0x05 0xAE 0xB4

Now it can look like:
b01010100 0x09 0x05 0xAE 0xB4

>From 11 bytes down to 5.


The reason I think a 32bit UINT max is a good top value is that gives you
about 4G~ of a maximum payload.  If you have a payload greater than 4G
there is no sane way a client API can process that. Even 4G is way too much
~


Where to go from here:
~
What do you think if I update the RFC with contributors for the new
handshaking we discussed and possibly this new way to do the payload if we
all like it?


A possible approach is to break up the WebSocket2 framing into its own RFC,
which
will cover compression methods and framing.

A seperate RFC would cover transporting WebSocket2 over HTTP/2, now this
seperate RFC can involve custom HTTP/2 frame types, header based
authentication, negotiating compression, custom settings frames, proxy
support, etc?
~

On Mon, Oct 3, 2016 at 12:40 AM, Kari Hurtta <hurtta-ietf@elmme-mailer.org>
wrote:

> Ilari Liusvaara <ilariliusvaara@welho.com>: (Sun Oct  2 20:19:05 2016)
> > > > Well, I think the following would work and avoid SETTINGS:
> > > >
> > > > -> :method ws2
> > > > -> :scheme wss
> > > > -> :authority foo.example
> > > > -> :path /bar
> > > > -> <optional extra parameters, e.g. compression support>
> > > > <- :status 200
> > > > <- sec-ws2-ack 1
> > > > <- <optional negotiated extras>
> > >
> > > If we can also assume that proxy does not ignore
> > >    :method = ws2
> > >    :scheme = ws
> > > then this may work.
> >
> > Oh yeah, that only works against dodgily implemented origins, not WS2-
> > unsupporting proxies (that do something else than just realtime
> > forwarding of unknown methods).
> >
> >
> > If one is worried about the latter, one would need the SETTING then
> > (one only needs to have server end signal support, since it is a
> > capability server has that client may or may not use)..
> >
>
> If forward proxy (= proxy configured on browser) supports both http and
> ftp,
> then it is checking :scheme. If it supports only http (and tunneling with
> CONNECT), then it can be lazy.
>
> Reverse proxies (which DNS gives from :authority) are more likely
> to be lazy.  These are either http/2 ⇒ http/1.1 or http/2 ⇒ http/2.
>
> Reverse proxies may be also TLS termination point. So wss is not tunneled.
>
> "Transparent" proxies; then perhaps SETTINGS does not work either.
>
> > -Ilari
>
> / Kari Hurtta
>
>