Re: [RFC] post-cache REQMOD

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.
Received on Fri Jul 11 2014 - 04:27:23 MDT