- 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
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