- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Tue, 25 Nov 2014 11:05:40 -0800
- To: Yutaka Hirano <yhirano@google.com>
- Cc: Andy Green <andy@warmcat.com>, Robert Collins <robertc@robertcollins.net>, Jason Greene <jason.greene@redhat.com>, Amos Jeffries <squid3@treenet.co.nz>, HTTP Working Group <ietf-http-wg@w3.org>
On 25 November 2014 at 04:28, Yutaka Hirano <yhirano@google.com> wrote: >> a) rewriting intermediaries MUST read HEADERS >> b) if they see an UPGRADE header they do not know how to deal with, they >> must kill the stream >> This also covers "upgrade xxx-123" case for http2. > > We could ask for it, but I'm not sure if giving a special meaning for > "rewriting" is suitable from http/2 point of view and it is suitable to > request at this moment, given that http/2 is almost stabilized (not?). > cc: Martin. > We had a discussion about the capability check and agreed to use SETTINGS > frames. > http://lists.w3.org/Archives/Public/ietf-http-wg/2014JulSep/1114.html I don't see how Andy's request is feasible. The way HTTP/2 is structured, intermediaries are permitted to collapse and re-assemble DATA as they choose. You cannot rely on frame boundaries to remain. To that end, you either do as suggested up-thread and force support by all intermediaries, or you add your own framing. I don't know if you have considered this... You could use CONNECT and only use the multiplexing features of the protocol. A special CONNECT would be rejected by all but those that recognize it. More so if you made the CONNECT pseudo-header fields include a ":scheme" of "wss", which is illegal. I note that we don't identify what error/status is generated if you break that rule.
Received on Tuesday, 25 November 2014 19:06:14 UTC