- From: Jason Greene <jason.greene@redhat.com>
- Date: Tue, 25 Nov 2014 13:55:05 -0600
- To: Martin Thomson <martin.thomson@gmail.com>
- Cc: Yutaka Hirano <yhirano@google.com>, Andy Green <andy@warmcat.com>, Robert Collins <robertc@robertcollins.net>, Amos Jeffries <squid3@treenet.co.nz>, HTTP Working Group <ietf-http-wg@w3.org>
> On Nov 25, 2014, at 1:05 PM, Martin Thomson <martin.thomson@gmail.com> wrote: > > 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. What is the benefit to preventing reframing? The negative of such a restriction is that intermediaries will be unable to utilize their knowledge of their network topology to improve performance. Is it to prevent delays from overly coalescing messages? If so a simple urgency flag or could accomplish the same thing. -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat
Received on Tuesday, 25 November 2014 19:57:03 UTC