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. Does this clarify? Thank you, Alex.
