- From: Andy Green <andy@warmcat.com>
- Date: Fri, 10 Nov 2017 14:50:32 +0800
- To: Kari Hurtta <hurtta-ietf@elmme-mailer.org>, Wenbo Zhu <wenboz@google.com>, Kazuho Oku <kazuhooku@gmail.com>
- Cc: Patrick McManus <pmcmanus@mozilla.com>, hybi <hybi@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
On 11/10/2017 02:14 PM, Kari Hurtta wrote: >> 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? How about putting a gratuitous content-length: 0 in one side's headers or both? If somebody doesn't really understand what the endpoints are up to and continues along normal h2 lines, they should fail the stream on the first DATA turning up then. -Andy > / Kari Hurtta > >
Received on Friday, 10 November 2017 06:51:16 UTC