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

Re: Large Frame Proposal

From: Roberto Peon <grmocg@gmail.com>
Date: Mon, 7 Jul 2014 16:06:42 -0700
Message-ID: <CAP+FsNfLuFj9aFVVzy6khFBZHmB5FMeFm0+2GLSw_KVQQppyqg@mail.gmail.com>
To: Poul-Henning Kamp <phk@phk.freebsd.dk>
Cc: Greg Wilkins <gregw@intalio.com>, Johnny Graettinger <jgraettinger@chromium.org>, HTTP Working Group <ietf-http-wg@w3.org>
On Mon, Jul 7, 2014 at 4:02 PM, Poul-Henning Kamp <phk@phk.freebsd.dk>
wrote:

> In message <
> CAP+FsNcxaLmfDcJc_ANzqpN-ja-2mzaOQKYvJ2rmcs_OX0kS7g@mail.gmail.com>,
> Roberto Peon wri
> tes:
>
> >And what if you're forwarding to another multiplexing proxy, and only
> then to a server?
> >Which limit applies to which request?
>
> Simple: You always respect the one your peer tells you.
>
> Your peer may be a proxy that needs your elephantine Kerberos Cookie
> but does not forward it to the server.
>
> Or it may have a better compression state with the server and be
> able to squeeze your header-set through.
>
> It might even be in cohorts with the server (ie: CDN) and strip out
> most of the headers that your browser needlessly spits out, before
> forwarding a much smaller request to the distant server over a thin
> slow pipe.
>
> You almost invariably end up worse by trying to second-guess the proxy.
>
> >It gets complicated and unuseful [...]
>
> No, it's simple, and I just showed you three valuable use-cases.
>

You just showed me three use-cases where the other request which are
multiplexed along that connection on either end will suffer failure because
the limit was too small, or the server/proxy accepted the work because the
end-users behind that connection need different limits.

Lets make it concrete.
Client A,is speaking to a proxy B, to servers C, D.
Server C wants a max header limit of 4k.
Server D wants a max header limit of 8k.

What does proxy B do?

-=R


>
>
> --
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk@FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
>
Received on Monday, 7 July 2014 23:07:10 UTC

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