Re: draft-kinnear-httpbis-http2-transport questions

> I have a few fairly basic questions about the goals of the draft.
> 
> Why do you need to use both :protocol and a setting?  Isn't SETTINGS_ENABLE_CONNECT_PROTOCOL 
> plus the new values for :protocol enough?

RFC 8441: Bootstrapping WebSockets with HTTP/2

SETTINGS_ENABLE_CONNECT_PROTOCOL SETTINGS seems do that partially:

https://tools.ietf.org/html/rfc8441#section-3


|   The new parameter name is SETTINGS_ENABLE_CONNECT_PROTOCOL.  The
|   value of the parameter MUST be 0 or 1.

|   Upon receipt of SETTINGS_ENABLE_CONNECT_PROTOCOL with a value of 1, a
|   client MAY use the Extended CONNECT as defined in this document when
*   creating new streams.  Receipt of this parameter by a server does not
*   have any impact.

|   Using a SETTINGS parameter to opt into an otherwise incompatible
|   protocol change is a use of "Extending HTTP/2" defined by Section 5.5
|   of [RFC7540].  Specifically, the addition a new pseudo-header field,
|   ":protocol", and the change in meaning of the :authority pseudo-
|   header field in Section 4 require opt-in negotiation. 

Specially it seems work on case

    :protocol=bytestream

when client is initializing this.

( :protocol=datagram is another thing )


https://tools.ietf.org/html/draft-kinnear-httpbis-http2-transport-01#section-2

|   As described in Section 5.5 of [RFC7540], SETTINGS parameters allow
|   endpoints to negotiate use of protocol extensions that would
|   otherwise generate protocol errors.  Use of the CONNECT method
|   extension defined in [RFC6455] requires the
|   SETTINGS_ENABLE_CONNECT_PROTOCOL parameter to be received by a client
|   prior to its use.

SETTINGS_ENABLE_CONNECT_PROTOCOL is on RFC 8441
it is NOT on RFC 6455: The WebSocket Protocol

|   After receiving both SETTINGS_ENABLE_CONNECT_PROTOCOL and
|   SETTINGS_ENABLE_BIDIRECTIONAL_CONNECT, either endpoint of an HTTP/2
|   connection can send a request in HEADERS frames to establish a byte
|   stream or datagram tunnel via the extended CONNECT method.
|   Similarly, either endpoint may be required to respond to an incoming
|   CONNECT request seeking to establish such a tunnel.

So I guess that server push on HTTP/2 is allowed to open
:protocol=bytestream  when 
  SETTINGS_ENABLE_BIDIRECTIONAL_CONNECT=1 is sent by client

> How does a :protocol of bytestream differ from a plan CONNECT?

Different semantic of :authority

https://tools.ietf.org/html/rfc7540#section-8.3

>   A proxy that supports CONNECT establishes a TCP connection [TCP] to
>   the server identified in the ":authority" pseudo-header field.  Once
>   this connection is successfully established, the proxy sends a
>   HEADERS frame containing a 2xx series status code to the client, as
>   defined in [RFC7231], Section 4.3.6.

So plain CONNECT is different.

https://tools.ietf.org/html/rfc8441#section-4

|   o  On requests bearing the :protocol pseudo-header field, the
|      :authority pseudo-header field is interpreted according to
|      Section 8.1.2.3 of [RFC7540] instead of Section 8.3 of that
|      document.  In particular, the server MUST NOT create a tunnel to
|      the host indicated by the :authority as it would with a CONNECT
|      method request that was not modified by this extension.

So in summary :protocol=bytestream does not freate TCP connection
to the server identified in the ":authority" pseudo-header field. 

I think that this is the difference.


> What is the point of a :protocol of datagram?


Seems that :protocol=datagram implies that "packect boundaries" are 
preserved.  That seems to be the difference between :protocol=datagram
and :protocol=bytestream 

( :protocol=bytestream     is like SOCK_STREAM on socket()
  but :protocol=datagram  looks like SOCK_SEQPACKET on socket()
  -- not actually SOCK_DGRAM  which is "connectionless, unreliable messages". 

  So perhaps it should be :protocol=seqpacket instead ?
)


So that one HTTP/2 DATA frame is one "packet" and is preserved to 
application (so that frame boundaries are not removed by HTTP/2 stack).

Was that intended meaning of

 :protocol=datagram

and only difference between :protocol=bytestream and :protocol=datagram
(I suggest :protocol=seqpacket  ☺  )

https://tools.ietf.org/html/draft-kinnear-httpbis-http2-transport-01#section-4

|   If the application negotiated the "datagram" protocol, individual
|   DATA frames are considered complete messages on the stream.
|   Implementations SHOULD preserve these message boundaries when
|   delivering data to the application.  This prevents applications from
|   needing to insert another level of framing to delineate message
|   boundaries while transmitting datagram messages over HTTP/2 streams.
|   Additionally, if an application is forwarding messages received over
|   a "datagram" stream, the contents of each DATA frame should be sent
|   in individual datagrams where possible.


So looks like

    SETTINGS_ENABLE_CONNECT_PROTOCOL=1 from server

    :protocol=datagram  from client

    is not enough for negation of this.

Is now SETTINGS_ENABLE_BIDIRECTIONAL_CONNECT=1 from other end (from server
if client is using :protocol=datagram) that what guarantees that 
:protocol=datagram preserves message boundaries ?

This is not vey well spelled on SETTINGS_ENABLE_BIDIRECTIONAL_CONNECT
text.  And also name does not imply that.


Got I that correct?

/ Kari Hurtta

Received on Saturday, 23 March 2019 07:25:05 UTC