[squid-users] Queue incoming requests when fetching from origin

[Alex Rousskov]

On 06/17/2016 05:33 AM, Jaap Dam wrote:

> From what I
> understand, re-validation is useful when done with If-Modified-Since or
> If-None-Match.

To revalidate stale objects, Squid uses conditional requests. That is
not the only way to revalidate, but that is what Squid does.


> However my responses do not provide the E-Tag header nor
> the Last-Modified header. 

IIRC, the If-Modified-Since field in a conditional request may use the
response Date header when Last-Modified is not available. If the origin
server supports checking resource modification times (without disclosing
them in responses for some reason), revalidation would still work as
intended.


> Is it possible for Squid to never revalidate
> but always to assume 'pure cache-miss' when a resource is stale?

I am not sure. Others may be able to answer this question
authoritatively. If you force me to guess, I would say "no".

Alex.



> 2016-06-16 17:20 GMT+02:00 Alex Rousskov
> <rousskov at measurement-factory.com
> <mailto:rousskov at measurement-factory.com>>:
> 
>     On 06/16/2016 01:45 AM, Jaap Dam wrote:
> 
>     > Thanks for the information. Could you elaborate on when collapsed
>     > forwarding does apply?
> 
>     Squid is currently able to collapse HTTP client [miss] requests (but not
>     internally generated HTTP requests triggered by HTTP client requests).
>     Furthermore, to be collapsable, the request must have no markings that
>     make the future response uncachable.
> 
> 
>     > With your extra information, my assumption would
>     > be that it only applies on requests of a resource that has never been
>     > cached before.
> 
>     I would not phrase it like that because Squid does not remember was has
>     been cached before, only what is still cached at the query time. There
>     are three primary cases for an HTTP client request to consider here:
> 
>     * pure cache hit: Collapsing is inapplicable because Squid does not send
>     any requests (there is nothing to collapse). Each HTTP client request is
>     satisfied from the Squid cache.
> 
>     * pure cache miss: Multiple requests for the same missing object can be
>     collapsed if collapsed_forwarding is enabled. Collapsable requests have
>     no markings that make the future response uncachable.
> 
>     * revalidation: The requested object was found in the cache but it was
>     stale. Squid sends an internal "revalidation" request to the origin
>     server or peer. These internal requests are currently not collapsed. We
>     are working on collapsing them as well.
> 
> 
>     > Secondly would you have a suggestion for solving the issue I'm facing?
> 
> 
>     I have not studied the issue you are facing, but if you think collapsing
>     revalidation requests would solve your problem, then either wait for us
>     to finish initial collapsed revalidation support (and then see if it
>     solves your problem) or co-sponsor that ongoing development (to make
>     sure it solves your problem).
> 
> 
>     HTH,
> 
>     Alex.
> 
> 
> 
>     > 2016-06-15 17:19 GMT+02:00 Alex Rousskov:
>     >
>     >     On 06/14/2016 02:51 AM, Jaap Dam wrote:
>     >
>     >     > I've part of the logging as an attachment. I'm requesting a
>     single URL
>     >     > in this log. The log starts with a stale cache of the item.
>     >
>     >     Collapsed forwarding does not apply to cache revalidation
>     requests yet.
>     >     Factory is working on implementing collapsed revalidations (in
>     some
>     >     environments), but I cannot promise a specific delivery date
>     or that
>     >     your particular environment will be covered.
>     >
>     >     Alex.
>     >
>     >
>     >
>     >
>     >     > 2016-06-13 15:34 GMT+02:00 Amos Jeffries:
>     >     >
>     >     >     On 14/06/2016 12:29 a.m., Jaap Dam wrote:
>     >     >     > Is the collapsed_forwarding directive the correct one
>     to use
>     >     for my
>     >     >     > use-case or am i missing something?
>     >     >
>     >     >     Yes it is correct so far as I am understanding your need.
>     >     >
>     >     >     For further debugging about what is going on you will
>     need the
>     >     HTTP
>     >     >     messages involved. Add the directive "debug_options 11,2
>     20,3"
>     >     to your
>     >     >     config to get them logged in cache.log.
>     >
>     >
> 
>