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.
