- From: Jason Greene <jason.greene@redhat.com>
- Date: Tue, 25 Nov 2014 15:32:36 -0600
- To: Willy Tarreau <w@1wt.eu>
- Cc: Martin Thomson <martin.thomson@gmail.com>, 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 3:27 PM, Willy Tarreau <w@1wt.eu> wrote: > > On Tue, Nov 25, 2014 at 01:17:41PM -0800, Martin Thomson wrote: >> On 25 November 2014 at 11:55, Jason Greene <jason.greene@redhat.com> wrote: >>> >>> 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. >> >> >> It would appear that Yukata and Andy want to use HTTP/2 frame >> boundaries as the basis for WS frame boundaries. That implies that >> you need to prevent blind reframing. Since reframing is an inherent >> part of HTTP/2, I note that this would be unwise. (And for more than >> just the reasons you describe.) > > I agree. Let's not reinvent application-aware chunking... > Also I note that we can already have tunnels over HTTP/2, so there's > nothing which prevents one form passing the whole WS stream inside. > Sure it's a double encoding, but that's really WS/1 over HTTP, regardless > of the HTTP version. We could later work on WS/2 which would benefit more > efficiently from H2 framing if that makes sense at all, but let's not try > to optimize first then fix… It seems there is a great deal of overlap between Web Sockets and HTTP/2, so I am questioning whether it makes sense to try to simply map what made since for HTTP/1 on top of HTTP/2. -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat
Received on Tuesday, 25 November 2014 21:34:32 UTC