Re: Re[2]: [squid-users] Issue with header_access and validation
> But wouldnt that only override max-age which is received in headers sent > by servers? > The ones we want to override are from client requests only. > Plus refresh_pattern can not take an acl since it's global and only based > on path.(ie no acls) > > Or am I not seeing things clearly? > refresh_pattern gets involved when updating something already in cache. AFTER the IMS has been actioned. header_access gets involved when sending the request to the server or the response to the client. Thus it was working too late for your earlier config. The closest thing I know of squid offering is the 'reload_into_ims' or 'refresh_stale_hit' options. The first to reduce possibly large full object requests down to the smaller 304's. The latter to reduce the amount of 304's to one at a time. Amos > > Thanks for any help again. > > >>?Use refresh_pattern entries to override the max-age. > > >>?On Fri, May 02, 2008, Paul-Kenji Cahier wrote: >>>?Hello, > >>>?In our current situation, we are trying to have "Cache-control: >>> max-age=0" headers from clients to be ignored >>>?in the cache decision process, while keeping all of the 'Cache-control: >>> no-cache' and 'Pragma: no-cache' >>>?still valid as making revalidation mandatory. > >>>?Without trying to do anything, when squid receives the max-age=0 >>> directive, it decides to TCP_REFRESH_HIT since >>>?the client asks it. > >>>?Our current approach was the following: >>>?acl static_content req_header Cache-control max.age=0 >>>?header_access Cache-Control deny static_content > >>>?While the acl is properly matched, it seems the header_access does not >>> ever get applied when deciding of what to do, >>>?with the result that it's effectively being ignored. > >>>?Is there any way to make it be applied earlier/another way to ignore >>> only 'Cache-control: max.age=0' headers? >>>?(we would also preferably rather be able to define that with an acl so >>> we can only apply that directive to >>>?really probably static content) > >>>?The whole goal is to avoid firefox's F5/refresh button from forcing >>> thousands of TCP_REFRESH_HIT/304 all the time, >>>?which not only strains the servers but takes longer. Of course we also >>> want users that want to force a refresh >>>?(through ctrl+shift+R, which actually adds the no-cache directives) to >>> be able to do so.(Caching is good, >>>?but forcing delays before things are checked again is not) > >>>?Any suggestions will be really appreciated... We have tried to rewrite >>> urls through privoxy, but it came messy >>>?and fairly heavy on load, so a squid only solution would really be >>> best. > >>>?-- >>>?Best regards, >>>? Paul-Kenji Cahier >>>?mailto:[EMAIL PROTECTED] > >
Re[2]: [squid-users] Issue with header_access and validation
But wouldnt that only override max-age which is received in headers sent by servers? The ones we want to override are from client requests only. Plus refresh_pattern can not take an acl since it's global and only based on path.(ie no acls) Or am I not seeing things clearly? Thanks for any help again. >?Use refresh_pattern entries to override the max-age. >?On Fri, May 02, 2008, Paul-Kenji Cahier wrote: >>?Hello, >>?In our current situation, we are trying to have "Cache-control: max-age=0" >>headers from clients to be ignored >>?in the cache decision process, while keeping all of the 'Cache-control: >>no-cache' and 'Pragma: no-cache' >>?still valid as making revalidation mandatory. >>?Without trying to do anything, when squid receives the max-age=0 directive, >>it decides to TCP_REFRESH_HIT since >>?the client asks it. >>?Our current approach was the following: >>?acl static_content req_header Cache-control max.age=0 >>?header_access Cache-Control deny static_content >>?While the acl is properly matched, it seems the header_access does not ever >>get applied when deciding of what to do, >>?with the result that it's effectively being ignored. >>?Is there any way to make it be applied earlier/another way to ignore only >>'Cache-control: max.age=0' headers? >>?(we would also preferably rather be able to define that with an acl so we >>can only apply that directive to >>?really probably static content) >>?The whole goal is to avoid firefox's F5/refresh button from forcing >>thousands of TCP_REFRESH_HIT/304 all the time, >>?which not only strains the servers but takes longer. Of course we also want >>users that want to force a refresh >>?(through ctrl+shift+R, which actually adds the no-cache directives) to be >>able to do so.(Caching is good, >>?but forcing delays before things are checked again is not) >>?Any suggestions will be really appreciated... We have tried to rewrite urls >>through privoxy, but it came messy >>?and fairly heavy on load, so a squid only solution would really be best. >>?-- >>?Best regards, >>? Paul-Kenji Cahier >>?mailto:[EMAIL PROTECTED]
Re: [squid-users] Issue with header_access and validation
Use refresh_pattern entries to override the max-age. On Fri, May 02, 2008, Paul-Kenji Cahier wrote: > Hello, > > In our current situation, we are trying to have "Cache-control: max-age=0" > headers from clients to be ignored > in the cache decision process, while keeping all of the 'Cache-control: > no-cache' and 'Pragma: no-cache' > still valid as making revalidation mandatory. > > Without trying to do anything, when squid receives the max-age=0 directive, > it decides to TCP_REFRESH_HIT since > the client asks it. > > Our current approach was the following: > acl static_content req_header Cache-control max.age=0 > header_access Cache-Control deny static_content > > While the acl is properly matched, it seems the header_access does not ever > get applied when deciding of what to do, > with the result that it's effectively being ignored. > > Is there any way to make it be applied earlier/another way to ignore only > 'Cache-control: max.age=0' headers? > (we would also preferably rather be able to define that with an acl so we can > only apply that directive to > really probably static content) > > The whole goal is to avoid firefox's F5/refresh button from forcing thousands > of TCP_REFRESH_HIT/304 all the time, > which not only strains the servers but takes longer. Of course we also want > users that want to force a refresh > (through ctrl+shift+R, which actually adds the no-cache directives) to be > able to do so.(Caching is good, > but forcing delays before things are checked again is not) > > Any suggestions will be really appreciated... We have tried to rewrite urls > through privoxy, but it came messy > and fairly heavy on load, so a squid only solution would really be best. > > -- > Best regards, > Paul-Kenji Cahier > mailto:[EMAIL PROTECTED] -- - Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support - - $25/pm entry-level VPSes w/ capped bandwidth charges available in WA -
[squid-users] Issue with header_access and validation
Hello, In our current situation, we are trying to have "Cache-control: max-age=0" headers from clients to be ignored in the cache decision process, while keeping all of the 'Cache-control: no-cache' and 'Pragma: no-cache' still valid as making revalidation mandatory. Without trying to do anything, when squid receives the max-age=0 directive, it decides to TCP_REFRESH_HIT since the client asks it. Our current approach was the following: acl static_content req_header Cache-control max.age=0 header_access Cache-Control deny static_content While the acl is properly matched, it seems the header_access does not ever get applied when deciding of what to do, with the result that it's effectively being ignored. Is there any way to make it be applied earlier/another way to ignore only 'Cache-control: max.age=0' headers? (we would also preferably rather be able to define that with an acl so we can only apply that directive to really probably static content) The whole goal is to avoid firefox's F5/refresh button from forcing thousands of TCP_REFRESH_HIT/304 all the time, which not only strains the servers but takes longer. Of course we also want users that want to force a refresh (through ctrl+shift+R, which actually adds the no-cache directives) to be able to do so.(Caching is good, but forcing delays before things are checked again is not) Any suggestions will be really appreciated... We have tried to rewrite urls through privoxy, but it came messy and fairly heavy on load, so a squid only solution would really be best. -- Best regards, Paul-Kenji Cahier mailto:[EMAIL PROTECTED]