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

Sun Jun 19 05:16:42 UTC 2016

Hey Jaap, (not sure if it's the first name)

The issue is that there are consequences for cached objects not being revalidated.
Also if there are sites which needs to be targeted it would be a different story.
Some might not understand the difference between a cache and an archive or want it to act as one.
A cache is meant to be temporary while archive should last longer.
One example is Windows Updates which might needs to be archived since it's always needed.

If you have a specific targeted site, let me know and I will try to see if something can be done.

Eliezer

----
Eliezer Croitoru
Linux System Administrator
Mobile: +972-5-28704261
Email: eliezer at ngtech.co.il

-----Original Message-----
From: squid-users [mailto:squid-users-bounces at lists.squid-cache.org] On Behalf Of Alex Rousskov
Sent: Friday, June 17, 2016 6:22 PM
To: Jaap Dam
Cc: squid-users at lists.squid-cache.org
Subject: Re: [squid-users] Queue incoming requests when fetching from origin

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.
>     >
>     >
> 
> 

_______________________________________________
squid-users mailing list
squid-users at lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users