- From: Kazuho Oku <kazuhooku@gmail.com>
- Date: Fri, 10 Nov 2017 16:05:20 +0900
- To: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
- Cc: Wenbo Zhu <wenboz@google.com>, Patrick McManus <pmcmanus@mozilla.com>, hybi <hybi@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
2017-11-10 15:14 GMT+09:00 Kari Hurtta <hurtta-ietf@elmme-mailer.org>: >> Therefore the explicit tunneling mechanism is >> necessary to signal to proxies/frameworks that a full-duplex byte-stream is >> being tunneled as a http/2 stream. > >>> Request: >>> :method: GET >>> :scheme: https >>> :authority: server.example.com >>> :path: /chat >>> :upgrade: websocket > > 8.1.2.1. Pseudo-Header Fields > https://tools.ietf.org/html/rfc7540#section-8.1.2.1 > > states > > -------- > > Pseudo-header fields are only valid in the context in which they are > defined. Pseudo-header fields defined for requests MUST NOT appear > in responses; pseudo-header fields defined for responses MUST NOT > appear in requests. Pseudo-header fields MUST NOT appear in > trailers. Endpoints MUST treat a request or response that contains > undefined or invalid pseudo-header fields as malformed > (Section 8.1.2.6). > > -------- > > Then that ":upgrade" works as explicit tunneling mechanism, IF you can trust > that response is treated as mailformed (stream error of type PROTOCOL_ERROR) > when proxies/frameworks does not subscribe that tunneling mechanism. > > Can you trust that? Note that we would be doing negotiation beforehand using a SETTINGS parameter. Otherwise, a client cannot send a request with `:upgrade:` pseudo header. I believe that a successful negotiation would be sufficient to guarantee that the `:upgrade:` response header will be recognized as a signal (or a 101 status code as a signal). > > / Kari Hurtta > -- Kazuho Oku
Received on Friday, 10 November 2017 07:05:44 UTC