Hi Alex, Thank you very much for your detailed explanation!
>From your explanation I would assume that my problem could be solved if the re-validation would be treated as a pure miss. From what I understand, re-validation is useful when done with If-Modified-Since or If-None-Match. However my responses do not provide the E-Tag header nor the Last-Modified header. Is it possible for Squid to never revalidate but always to assume 'pure cache-miss' when a resource is stale? Best regards 2016-06-16 17:20 GMT+02:00 Alex Rousskov <rouss...@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@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
