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

Re: #541: CONTINUATION - option #4

From: Willy Tarreau <w@1wt.eu>
Date: Mon, 7 Jul 2014 11:48:08 +0200
To: Mark Nottingham <mnot@mnot.net>
Cc: Jason Greene <jason.greene@redhat.com>, K.Morgan@iaea.org, Martin Thomson <martin.thomson@gmail.com>, adrian.f.cole@gmail.com, tatsuhiro.t@gmail.com, ietf-http-wg@w3.org
Message-ID: <20140707094808.GB32346@1wt.eu>
On Mon, Jul 07, 2014 at 06:59:49PM +1000, Mark Nottingham wrote:
> > Here the proxy does not have to impact one
> > client's MHS depending on the other ones. At best it would impact the MHS on
> > the connections to the origin server. The MHS is a property of the connection
> > and does not have to be transferred between the two sides (better, must not).
> 
> I'm not sure I buy that. If I connect to a proxy and its request MHS is
> bigger than the next-hop's request MHS, I'll send requests assuming the
> first. 

I mean, you're the UA, you don't need to know anything about the server since
your connection is with the proxy. Let's not repeat the proxy-connection hell!
If the proxy accepts 64kB because you're authenticating to it using kerberos
tickets, but it needs only 16kB to go outside, what matters for the UA is the
proxy connection only. And conversely, a reverse-proxy could need a larger MHS
with the origin than what it uses with the client because it passes additional
information (eg: SSL cert). So the two are definitely independant.

> I suspect some intermediaries will end up grouping requests from different
> connections together by MHS.

Yes that's what I was suggesting as well.

> I wonder if any sort of MHS setting is better-off being something
> coarse-grained (e.g., aligned on 1k or 4k) so that you don't have peers doing
> weird things like advertising 423 byte MHS, thereby screwing things up...

I definitely agree. Using powers of two, or at maybe half-steps would ensure
easy allocation/grouping.

Cheers,
Willy
Received on Monday, 7 July 2014 09:48:46 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:09 UTC