On 11/07/2014 4:27 p.m., Alex Rousskov wrote: > On 07/10/2014 09:12 PM, Amos Jeffries wrote: >> On 11/07/2014 10:15 a.m., Alex Rousskov wrote: >>> I propose adding support for a third adaptation vectoring point: >>> post-cache REQMOD. Services at this new point receive cache miss >>> requests and may adapt them as usual. If a service satisfies the >>> request, the service response may get cached by Squid. As you know, >>> Squid currently support pre-cache REQMOD and pre-cache RESPMOD. >> >> Just to clarify you mean this to be the vectoring point which receives >> MISS-only traffic, as the existing one(s) receive HIT+MISS traffic? > > + pre-cache REQMOD receives HIT+MISS request traffic. > + pre-cache RESPMOD receives MISS response traffic. > * post-cache REQMOD receives MISS request traffic. > - post-cache RESPMOD receives HIT+MISS response traffic. > > All four vectoring points are documented in RFC 3507. Squid currently > supports the first two. I propose adding support for the third. Each of > the four points (and probably other!) is useful for some use cases. > > Besides getting different HIT/MISS traffic mixture, there are other > differences between these vectoring points. For example, pre-cache > REQMOD responses go straight to the HTTP client while post-cache REQMOD > responses may be cached by Squid (this example is about request > satisfaction mode of REQMOD). > > >>> We have received many requests for post-cache adaptation support >>> throughput the years, and I personally resisted the temptation of adding >>> another layer of complexity (albeit an optional one) because it is a lot >>> of work and because many use cases could be addressed without post-cache >>> adaptation support. >>> >>> The last straw (and the motivation for this RFC) was PageSpeed[1] >>> integration. With PageSpeed, one can generate various variants of >>> "optimized" content. For example, mobile users may receive smaller >>> images. Apache and Nginx support PageSpeed modules. It is possible to >>> integrate Squid with PageSpeed (and similar services) today, but it is >>> not possible for Squid to _cache_ those generated variants unless one is >>> willing to pay for another round trip to the origin server to get >>> exactly the same unoptimized content. >> >> Can you show how they are violating standard HTTP variant caching? the >> HTTPbis should probably be informed of the problem. >> If it is actually within standard then it would seem to be a missing >> feature of Squid to cache them properly. We could improve better by >> fixing Squid to cache more compliant traffic. > > 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. Or, PageSpeed is completely unnecessary mid-transit and has nothing to do with Squid and caching. 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. Amos
