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. 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. Martin, does that look correct to you? Thanks, On Thu, Jul 17, 2014 at 2:08 AM, Martin Thomson <martin.thomson@gmail.com> wrote: > On 15 July 2014 23:33, Kari Hurtta <hurtta-ietf@elmme-mailer.org> 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 >
Received on Thursday, 17 July 2014 01:39:03 UTC