Re: [RFC] post-cache REQMOD

On 07/11/2014 03:16 AM, Amos Jeffries wrote:
> On 11/07/2014 4:27 p.m., Alex Rousskov wrote:
>> This is unrelated to caching rules. HTTP does not have a notion of
>> creating multiple responses from a single response, and that is exactly
>> what PageSpeed and similar adaptations do: For example, they convert a
>> large origin server image or page into several variants, one for each
>> class of clients.

> Indeed. So this implementation of PageSpeed by requiring HTTP agents to
> transform traffic mid-transit from single to multiple responses is a
> violation.

I do not think so. This is just a content adaptation outside of the HTTP
domain. If this is a "violation", then dreaming of unicorns is an HTTP
violation because HTTP does not have a notion of a unicorn.

> Or, PageSpeed is completely unnecessary mid-transit and has nothing to
> do with Squid and caching.

Evidently, folks deploying proxies say otherwise. We can tell them that
they are "doing it wrong", but I do not think we should in this case.
For some use cases, PageSpeed adaptation is the right thing to do. Also,
this is not necessarily used "mid-transit" as discussed below.

> Which can cache either the small shrunk
> objects, or the single large one just fine. It is instead the attempt to
> perform end-server operations in a proxy/gateway which is driving this
> change.

The need to better serve a diverse population of web clients is driving
this change. An attempt to confine useful content adaptations to
"end-servers" is futile at best. BTW, many want to deploy PageSpeed at
the reverse proxy, which is an end-server from the HTTP client point of
view so even if we adopt the "only end-servers can do that!" law, Squid
should still support this kind of adaptation.

Cheers,

Alex.
Received on Fri Jul 11 2014 - 15:25:15 MDT