- From: Jason Greene <jason.greene@redhat.com>
- Date: Wed, 25 Jun 2014 17:57:46 -0500
- To: Roberto Peon <grmocg@gmail.com>
- Cc: K.Morgan@iaea.org, Patrick McManus <pmcmanus@mozilla.com>, Nicholas Hurley <hurley@todesschaf.org>, Mark Nottingham <mnot@mnot.net>, Poul-Henning Kamp <phk@phk.freebsd.dk>, Willy Tarreau <w@1wt.eu>, Greg Wilkins <gregw@intalio.com>, HTTP Working Group <ietf-http-wg@w3.org>, Martin Dürst <duerst@it.aoyama.ac.jp>
On Jun 25, 2014, at 3:22 PM, Roberto Peon <grmocg@gmail.com> wrote: > The sender determines how to apportion data into frames. We were seeing whole files transmitted as a single frame. Hmm I guess I just don’t see what’s so bad about this. If your peer negotiates a large frame size, you know not to bother muxing a lot of requests on it, and negotiate it down in another connection. > And again, in the web use-case this is not going to be a measurable difference in utilization, since we're likely to be using TLS. > -=R I don’t want to resurrect the encryption discussions, but I will say that if I was running a common public download site I would be very tempted to send clients to a clear-text, simple and fast HTTP/1.1 connection. Of course it would be nice if you didn’t have to switch protocols for common use cases. -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat
Received on Wednesday, 25 June 2014 22:58:54 UTC