Re: Large Frame Proposal

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