- From: Nicolas Mailhot <nicolas.mailhot@laposte.net>
- Date: Sun, 8 Apr 2012 23:12:08 +0200
- 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 UTC