Re: 5.5 Extending HTTP/2, WS_OVER_HTTP/2 | Re: draft-ietf-httpbis-http2-latest, 8.1.2.1 Request Header Fields | Re: draft-ietf-httpbis-http2-latest, 5.5

[Yutaka Hirano <[e-mail]>]

Thank you for the feedback!
I am updating my WebSocket over HTTP/2 draft to reflect recent changes to
the HTTP/2 spec and any comments are welcome.

So I guess that Websocket handshake response is a HEADERS frame.
> Because new colon-headers was not allowed in extensions, I guess that
> this handshake is regular HTTP-header.
> ( And I suppose that Websocket handshake request must be HEADERS frame
>   because that is used to open new stream on HTTP/2. [*] )

Yes, handshake request and response use usual HEADERS frames.
The server knows that the client wants to establish a WebSocket connection
from
:scheme header (which is a standard colon header).
We can define usual headers for handshake without violating the HTTP/2 spec,
like sec-websocket-protocol in the native WebSocket.

But it is needed to confirm that intermediaries understand WebSocket over
HTTP/2.
That's why SETTINGS frames with WS_CAPABLE is needed.

Does that make sense?



On Thu, Jul 17, 2014 at 2:37 PM, Kari Hurtta <[e-mail]>
wrote:

> [ Date: Thu, 17 Jul 2014 10:38:36 +0900
>   From: Yutaka Hirano <[e-mail]>
>   To: Martin Thomson <[e-mail]>
>   cc: Kari Hurtta <[e-mail]>,
>                 HTTPBIS working group mailing list <[e-mail]>
> ]
>
> Yutaka Hirano <[e-mail]>: (Thu Jul 17 04:38:36 2014)
> > I see.
> > Currently I would like to use SETTINGS frames to confirm the
> WS-over-HTTP/2
> > capability of a communication channel, like this.
> >
> > An endpoint sends a SETTINGS frame with WS_CAPABLE once a HTTP/2
> connection
> > is created.
> > An endpoint knows that an HTTP/2 connection is capable of WS_OVER_HTTP/2
> if
> > it receives a SETTINGS frame with WS_CAPABLE.
> > A client knows that an HTTP/2 connection isn't capable of WS_OVER_HTTP/2
> if
> > it receives a Websocket handshake response before receiving a SETTINGS
> > frame with WS_CAPABLE.
>
> So I guess that Websocket handshake response is a HEADERS frame.
> Because new colon-headers was not allowed in extensions, I guess that
> this handshake is regular HTTP-header.
>
> ( And I suppose that Websocket handshake request must be HEADERS frame
>   because that is used to open new stream on HTTP/2. [*] )
>
> > A server knows that an HTTP/2 connection isn't capable of WS_OVER_HTTP/2
> if
> > it receives a Websocket handshake request before receiving a SETTINGS
> frame
> > with WS_CAPABLE.
> >
>
> If handshake response is some new frame type, then already receipt of a new
> frame type guarantees that endpoint (and whole chain of intermediaries and
> server)
> are capable of WS_OVER_HTTP/2.
>
> As per
>
> 5.5 Extending HTTP/2
> http://http2.github.io/http2-spec/#extensibility
>
> intermediaries does not "forward" unknown frame types (and of course does
> not
> send SETTINGS frame with unknown settings to upstream).
>
> ( Also if hanshake was reserved bits, then already presence of these
>   guarantee that endpoint are capable of WS_OVER_HTTP/2. But there
>   is not many usefull reserved bits on
>
>   4.1 Frame Format
>   http://http2.github.io/http2-spec/#FrameHeader
>
>   and not any on
>
>   6.2 HEADERS
>   http://http2.github.io/http2-spec/#HEADERS
>
>   I do not see that
>
>   5.5 Extending HTTP/2
>   http://http2.github.io/http2-spec/#extensibility
>
>   allows extending flags for existing frame types,
>   but I do not see that explicitly forbidden either. )
>
> [*] If Websocket hanshake and new stream is opened with new frame type,
>     that is not possible before both endpoints are received SETTINGS
>     frame wich imply WS_OVER_HTTP/2.
>
>
> > Martin, does that look correct to you?
>
> This was not to me (but as "cc:"), but seems that I commented anyway ☺
>
> > Thanks,
>
> / Kari Hurtta
>
>
> > On Thu, Jul 17, 2014 at 2:08 AM, Martin Thomson <
> [e-mail]>
> > wrote:
> >
> > > On 15 July 2014 23:33, Kari Hurtta <[e-mail]>
> wrote:
> > > > Should this
> > > >         "other than those defined in this document"
> > > >
> > > > to be
> > > >         "other than those defined in this document or extensions
> > > (Section 5.5)"
> > >
> > > We decided to forbid the use of colon-headers in extensions.
> > >
> > > > In other hand I think that this whole text
> > > >
> > > > » Header field names that start with a colon are only valid in the
> > > HTTP/2 context. These are not
> > > > » HTTP header fields. Endpoints MUST NOT generate header fields that
> > > start with a colon other
> > > > » than those defined in this document [or extensions (Section 5.5)]
> > > >
> > > > belong to
> > > >
> > > > 8.1.2 HTTP Header Fields
> > >
> > > Let's see:
> > >
> https://github.com/http2/http2-spec/commit/cf1677cbc2b8f501204de18ecfe6ff4be623b9ba
> > >
>
>
>