- From: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
- Date: Fri, 10 Nov 2017 18:50:11 +0200 (EET)
- To: Kazuho Oku <kazuhooku@gmail.com>
- CC: Kari Hurtta <hurtta-ietf@elmme-mailer.org>, Wenbo Zhu <wenboz@google.com>, Patrick McManus <pmcmanus@mozilla.com>, hybi <hybi@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
Kazuho Oku <kazuhooku@gmail.com>: (Fri Nov 10 09:05:20 2017) > 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). Yes, 5.5. Extending HTTP/2 https://tools.ietf.org/html/rfc7540#section-5.5 ----------------- " Extensions that could change the semantics of existing protocol " components MUST be negotiated before being used. ----------------- seems imply that :upgrade pseudo header maut be negotiated. SETTINGS is one possibility: ---------------- " This document doesn't mandate a specific method for negotiating the " use of an extension but notes that a setting (Section 6.5.2) could be " used for that purpose. ---------------- Seems that existing of new pseudo header itself can not be used as negotiation: ---------------- " Extensions are permitted to use new frame types (Section 4.1), new " settings (Section 6.5.2), or new error codes (Section 7). Registries " are established for managing these extension points: frame types " (Section 11.2), settings (Section 11.3), and error codes " (Section 11.4). " " Implementations MUST ignore unknown or unsupported values in all " extensible protocol elements. ---------------- / Kari Hurtta > > > > -- > Kazuho Oku
Received on Friday, 10 November 2017 16:52:00 UTC