W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: #540: "jumbo" frames

From: Jason Greene <jason.greene@redhat.com>
Date: Wed, 25 Jun 2014 17:57:46 -0500
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>
Message-Id: <C4D82B1C-0B00-4DFD-A393-9855DDF25D97@redhat.com>
To: Roberto Peon <grmocg@gmail.com>

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:31 UTC