On 12/07/2014 3:24 a.m., Alex Rousskov wrote: > 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. >
We've been advising alternative to post-cache vector points as you say for some time. This does not appear to be much different to the other requests. There is an alternative. Question is whether the benefit gained by one more piece of software in the installed chain outweights the development effort and maintenance of a new vector point in Squid code. IMHO they are pretty evenly balanced at present. So its up to you whether you want to take on that workload. My opinion on where and how to integrate was mentionend in the initial email. > >> 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. > Perhapse. Dont let my doubts there block you though. Amos
