Re: Re: Quick review for draft-svirid-websocket2-over-http2 (Was: Re: Draft HTTPbis Agenda For Seoul IETF 97)

> Some quick review comments:

>- The handshake seems to negotiate compression and then the frames
> contain compression method indicator. Are there really multiple
>  compression methods available on per-frame basis, or should the
>  compression just be 1 bit (compressed or not)?

The use case for this is that when using lz4, small frames under 20 octets
in size often end up being larger after compression.
This way the server can have more control of what it sends to client.

The reason for having different types of compression is to support a broad
range of data being transmitted. especially for all the
new custom protocol we have popping up.

>- The abbrevations in frame diagram are bit difficult to understand
>  (have those be expanded in above text?).

I agree on this. It is hard to draw up the frames and represent everything.
But rough idea when parsing is (everything is unsigned):

InnerFrame = case (Length = recv(1)):
  255:
    Length = recv(4)
  254:
    Length = recv(2)
  finally:
    recv(Length)

FrameHeader = InnerFrame[0]
FrameBody = InnerFrame[1,]
... continue

At first I had static sizes instead of the variable size, but the static
sizes produce extra bytes on the wire which can be reduces by introducing
some complexity. For example before a 100 octet sized frame length would
take 4 octets on the wire, now it just takes 1.

> - Somebody needs to try what this does against many HTTP/2 origins
>  that don't support WebSockets2 and against intermediaries with
>  custom server that actually supports it. Just to see what the
>  heck happens (if it is nasty, one might need to use SETTINGS to
>  signal support, either for WebSockets directly or for some sort
>  of strict scheme).

I think settings maybe the way to go at this point.  It seems to be quite
well received.

- What is "valid UTF-8" exactly? E.g. does it contain encodings for
  Unicode noncharacters?

It would be scanning over the string and validating every code point.    The
only reason this is included is to be backward compatible with WebSocket.

Ideally I just wanted to have binary frames, then when you receive them you
can
cast them to strings.


>  4.3.1.  GET
> https://tools.ietf.org/html/rfc7231#section-4.3.1
>
> |   A payload within a GET request message has no defined semantics;
> |   sending a payload body on a GET request might cause some existing
> |   implementations to reject the request.
> |
> |   The response to a GET request is cacheable; a cache MAY use it to
> |   satisfy subsequent GET and HEAD requests unless otherwise indicated
> |   by the Cache-Control header field (Section 5.2 of [RFC7234]).

> Changing of scheme does not change semantic of methods.

It seems that sending a Cache-Control header to indicate no caching would
work then?

I thought that a middlebox cannot cache ANYTHING unless the response
contains headers to allow caching.
It seems the opposite, anything can be cached unless strictly told not to.

The problem with CONNECT method is it seems to be used now for establishing
tunneling between middleboxes.

Introducing a custom method like WS2 also seems a little out of place.  But
a custom method method like
UPGRADE or something to indicate something is going on could work.



On Thu, Oct 20, 2016 at 5:33 AM, Kari Hurtta <hurtta-ietf@elmme-mailer.org>
wrote:

> > This could be the case for any HTTP/2 gateway that translates incoming
> > requests to HTTP/1, that does not reject unknown schemes. And whether
> > such gateway needs to reject schemes that do not match to the
> > request-response model of HTTP seems to be vague in reading RFC 7540.
> > Section 8.1.2.3 states that:
> >
> >       ":scheme" is not restricted to "http" and "https" schemed URIs.  A
> >       proxy or gateway can translate requests for non-HTTP schemes,
> >       enabling the use of HTTP to interact with non-HTTP services.
> >
> > My interpretation of this paragraph would be that it is permitted for
> > an HTTP/2 intermediary to transmit requests with schemes other than
> > "http" or "https", expecting that an upstream server would process the
> > request according to the scheme, considering the fact that (per my
> > understanding) such action is permitted in HTTP/1.1.
>
> Yes. HTTP/2 explicitly uses HTTP/1.1 semantic.
>
> 8.  HTTP Message Exchanges
> https://tools.ietf.org/html/rfc7540#section-8
>
> |   Thus, the specification and requirements of HTTP/1.1 Semantics and
> |   Content [RFC7231], Conditional Requests [RFC7232], Range Requests
> |   [RFC7233], Caching [RFC7234], and Authentication [RFC7235] are
> |   applicable to HTTP/2.  Selected portions of HTTP/1.1 Message Syntax
> |   and Routing [RFC7230], such as the HTTP and HTTPS URI schemes, are
> |   also applicable in HTTP/2, but the expression of those semantics for
> |   this protocol are defined in the sections below.
>
> 3.1.  Client Handshake Request
> https://tools.ietf.org/html/draft-svirid-websocket2-over-
> http2-00#section-3.1
>
> | 3.1.  Client Handshake Request
> |
> |    The client MUST use the :method GET.
> |
> |    The client MUST send a sec-ws2-version header that MUST specify the
> |    websocket2 version being used.
> |
> |    The client MAY send a sec-ws2-compression header that advertises the
> |    compression methods the client supports.  Valid key value pairs
> |   include:
>
> ↡
>
> | The client MUST NOT set the END_STREAM flag when sending the headers.
>
>
> Note however that this apply:
>
> 4.3.1.  GET
> https://tools.ietf.org/html/rfc7231#section-4.3.1
>
> |   A payload within a GET request message has no defined semantics;
> |   sending a payload body on a GET request might cause some existing
> |   implementations to reject the request.
> |
> |   The response to a GET request is cacheable; a cache MAY use it to
> |   satisfy subsequent GET and HEAD requests unless otherwise indicated
> |   by the Cache-Control header field (Section 5.2 of [RFC7234]).
>
>
> Changing of scheme does not change semantic of methods.
>
> 2.  Resources
> https://tools.ietf.org/html/rfc7231#section-2
>
> |   One design goal of HTTP is to separate resource identification from
> |   request semantics, which is made possible by vesting the request
> |   semantics in the request method (Section 4) and a few
> |   request-modifying header fields (Section 5).  If there is a conflict
> |   between the method semantics and any semantic implied by the URI
> |   itself, as described in Section 4.2.1, the method semantics take
> |   precedence.
>
> ( scheme is part of URI )
>
> 2.7.  Uniform Resource Identifiers
> https://tools.ietf.org/html/rfc7230#section-2.7
>
> |   Uniform Resource Identifiers (URIs) [RFC3986] are used throughout
> |   HTTP as the means for identifying resources (Section 2 of [RFC7231]).
> |   URI references are used to target requests, indicate redirects, and
> |   define relationships.
>
>
> / Kari Hurtta
>