hit-for-pass vs. hit-for-miss

[Geoffrey Simmons]

For one thing, I wouldn't call it workaround to use Last-Modified/ETag and IMS/INM to avoid sending a very large response unless it's necessary. Validation is meant to solve just that sort of problem.

But that's not the main thing I'm talking about. We have required devs to always decide about TTLs for caching themselves, including TTL=0, by setting Cache-Control. I know that's unusual, but it's the way things really ought to be.

However, that eliminates the possibility of knowing at recv time that a request can be passed. Again, I know it's common to have something like lists of regexen in vcl_recv to decide what goes to lookup and what goes to pass. But it shouldn't *have* to be that way -- ideally, it shouldn't be necessary at all.

Without HFP, we're left with no way at all of knowing which requests can be passed. Which is bad enough, but it also in turn eliminates the possibility of using IMS/INM for uncacheable responses.

Altogether, it means that we ask devs to use HTTP for caching as the protocol intends, but then it's a problem case for a caching proxy for HTTP (and Nils has indicated that a VMOD might have performance problems). That IMO gets us into Alice in Wonderland territory.

Sent from my iPhone

> On Sep 7, 2016, at 4:00 PM, Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:
> 
> --------
> In message <4E80A314-241C-4566-B6BA-61B72DC2CAA6 at uplex.de>, Geoffrey Simmons wr
> ites:
> 
>> That may indeed be unusual, but I see that a sad commentary on the
>> state of web developers' knowledge about caching and HTTP. Not as
>> somebody's peculiar requirement.
> 
> Oh, man, if you think that is a sad commentary, wait till I get started...
> 
>> It would strike me as rather odd if a caching proxy has to treat
>> it as a special case when backends actually do something the right
>> way (like always set Cache-Control to determine TTLs).
> 
> IMO the unusual detail, is that it takes several minutes to fetch
> the object from the backend, and that people are trying to find
> a way to mitigate/work around that special case.
> 
> -- 
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk at FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe    
> Never attribute to malice what can adequately be explained by incompetence.