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

Re: Re[2]: Some proxy needs

From: Nicolas Mailhot <nicolas.mailhot@laposte.net>
Date: Sun, 8 Apr 2012 23:12:08 +0200
Message-ID: <0edc27e8599b098be0f9a3bf18a1653f.squirrel@arekh.dyndns.org>
To: "Poul-Henning Kamp" <phk@phk.freebsd.dk>
Cc: "Nicolas Mailhot" <nicolas.mailhot@laposte.net>, "Adrien W. de Croy" <adrien@qbik.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>

Le Dim 8 avril 2012 22:35, Poul-Henning Kamp a écrit :
> In message <6d282afce1d51732a6d9cdcfdcac0a8a.squirrel@arekh.dyndns.org>,
> "Nicol
> as Mailhot" writes:
>
>>Then if the protocol does not permit signaling progress, what the solution
>>would be? (educating users does not work, they've been brainwashed to refresh
>>at the slightest pause)
>
> I think it is a design-mistake for the proxy to react to the forced
> reload of a huge object, when is already busy processing that object
> and have not delivered it to any clients yet.
>
> Given that the client has not seen the object yet, the client has
> no basis for conclusing it is out of date, so the reloads should
> be ignored, the requests queued and once the object is processed,
> you can deliver it.

Ah, but on a big proxy farm setup, the load balancer may orient the second
request to an new proxy (since the first one is busy). And the origin web site
may also be part of a cdn, and the second request may not end on the same
delivery server as the first one

Either way once you pile up several layers where load is shared between
multiple parallel nodes, implicit signaling breaks down badly

-- 
Nicolas Mailhot
Received on Sunday, 8 April 2012 21:12:42 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:59 GMT