[squid-users] cache-control

[Jeff Peng]

Hello,

The cache-control values like "no-cache" and "no-store", are used for
a cache/proxy server generally.
Do they have the same effect to useragent's local buffer (ig,
Firefox's disk buffer)? Thanks.

-- 
Regards,
Jeff. - [EMAIL PROTECTED]

[squid-users] cache-control headers

[Jonathan Lunn]

Hello squid-users,


I'm successfully using Squid (3.0.STABLE25) with ESI enabled but, I can't seem 
to cache anything that has a cache-control: max-age less than 60 seconds. At 
present I'm having to set cache-control: max-age header at 61 seconds in order 
to cache. 

e.g;



Am I missing something?

Regards,

Jonathan 


  

Re: [squid-users] cache-control

[Matus UHLAR - fantomas]

On 30.06.08 11:49, Jeff Peng wrote:
> The cache-control values like "no-cache" and "no-store", are used for
> a cache/proxy server generally.
> Do they have the same effect to useragent's local buffer (ig,
> Firefox's disk buffer)? Thanks.

RFC 2616 describes how proxies and user agents should traat those headers.
I think you should read that for best understanding of those.

Note that some browsers and proxies do not behave as they should, but it's
always better to know how they should behave and where they violate that, in
order to understand all the stuff
-- 
Matus UHLAR - fantomas, [EMAIL PROTECTED] ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
- Have you got anything without Spam in it?
- Well, there's Spam egg sausage and Spam, that's not got much Spam in it.

Re: [squid-users] cache-control

[Henrik Nordstrom]

On mån, 2008-06-30 at 11:49 +0800, Jeff Peng wrote:

> The cache-control values like "no-cache" and "no-store", are used for
> a cache/proxy server generally.
> Do they have the same effect to useragent's local buffer (ig,
> Firefox's disk buffer)? Thanks.

They should.

With the exception being if you navigate the history (back/forward).

Regards
Henrik


signature.asc
Description: This is a digitally signed message part

Re: [squid-users] cache-control headers

[Henrik Nordström]

ons 2010-05-12 klockan 08:45 -0700 skrev Jonathan Lunn:

> I'm successfully using Squid (3.0.STABLE25) with ESI enabled but, I can't 
> seem to cache anything that has a cache-control: max-age less than 60 
> seconds. At present I'm having to set cache-control: max-age header at 61 
> seconds in order to cache. 

There is a threshold set in squid.conf limiting caching of objects which
can not be revalidated (no cache validator in the response header) and
which expires quickly.

minimum_expiry_time or something like that.

Fixing the server to provide and support cache validators is the better
option however.

A cache validator is Last-Modified or ETag, and is used by
If-Modified-Since or If-None-Match request headers to validate the
freshness of the cached copy.

Regards
Henrik

Re: [squid-users] cache-control headers

[Amos Jeffries]

On Wed, 12 May 2010 08:45:27 -0700 (PDT), Jonathan Lunn

wrote:
> Hello squid-users,
> 
> 
> I'm successfully using Squid (3.0.STABLE25) with ESI enabled but, I
can't
> seem to cache anything that has a cache-control: max-age less than 60
> seconds. At present I'm having to set cache-control: max-age header at
61
> seconds in order to cache. 
> 
> e.g;
> 
>  header('Surrogate-Control: s-maxage=61, content="ESI/1.0"');
> header('Cache-Control: max-age=61' );
> 
> ...
> 
> ?>
> 
> Am I missing something?

The 3.0 implementation of ESI completely ignored the Cache-Control header.
This has been fixed in 3.1.
Try adding max-age to your Surrogate-Control header as well if you want
that to apply on 3.0 surrogates.

The 60 second issue has been mentioned before but the cause has not yet
been tracked down and fixed AFAIK. In this case it may be a default
staleness estimate due to ignoring the CC header.

Amos

[squid-users] Cache-Control: public doesn't cache

[Rob van der Putten]

Hi


AFAIK 'Cache-Control: public, no-transform' is cacheable. But Squid 
(3.3.8) doesn't cache.



Regards,
Rob

[squid-users] Cache-Control / Max-Age / Squid

[Marco C. Coelho]

One of the sites we host has a couple of large organizations that hit 
the site.


Recently, we have been getting complaints that the users are getting:

"You don't have permission to access / on this server"

Both of these customers use Squid or some variant.

This appears to be related to the Cache-Control: max-age = 259200 within 
their request.


When I touch all files in the http directory all is well.

Any thoughts to squid settings that would cause this.  We don't have 
this problem with our squid setup.


Marco

[squid-users] Cache-Control problems with Korean sites

[Mike Mitchell]

We're having problems accessing Korean Government sites like parcel.epost.go.kr 
and www.g2b.go.kr from a squid cache that is physically 
in Seoul, Korea.  I performed network captures and found that if the request 
included a 'Cache-Control' header the remote server did not send TCP ACK 
messages back for the request.  The remote server did complete the three-way 
TCP connection handshake, but would not acknowledge the request.  When I 
stripped the 'Cache-Control' header using

  acl NoCacheCtl dstdomain .epost.go.kr .gtb.go.kr
  header_access Cache-Control deny NoCacheCtl

the TCP ACKs started coming back and we could retrieve content.

My guess is there is a firewall protecting the remote web servers.  Has anyone 
seen this behavior before?

Mike Mitchell
SAS Institute Inc.
mike.mitch...@sas.com
(919) 531-6793

Re: [squid-users] Cache-Control: public doesn't cache

[Eliezer Croitoru]

Hey Rob,

Do you have a public URL or an example? header? more info?

In a case we can reproduce this we can get to the root of the issue.

Eliezer

On 04/28/2014 07:19 PM, Rob van der Putten wrote:

Hi


AFAIK 'Cache-Control: public, no-transform' is cacheable. But Squid
(3.3.8) doesn't cache.


Regards,
Rob

Re: [squid-users] Cache-Control: public doesn't cache

[Amos Jeffries]

On 29/04/2014 4:19 a.m., Rob van der Putten wrote:
> Hi
> 
> 
> AFAIK 'Cache-Control: public, no-transform' is cacheable. But Squid
> (3.3.8) doesn't cache.
> 

That one header does not make it cacheable...
 * "no-transform" has no meaning at all in regards to cacheability.
 * "public" is only meaningful when authentication is being used.


... in HTTP/1.1 everything is considered cacheable unless the protocol
defines a reason not to.

Squid may choose not to cache for many other reasons related to the
request headers, response headers, server trustworthiness, age of the
object on arrival, and available storage space.

Some reasons in the protocol are broad, like "a response to an unknown
method is not cacheable". **

Others are very specific, like "a cached object with Cache-Control
no-cache or must-revalidate may only be used as a response after a
successful revalidation (304 not modified) from the origin server." **

** very rough paraphrasing by me.

Amos

RE: [squid-users] Cache-Control: public doesn't cache

[Lawrence Pingree]

I believe there were some bugs fixed regarding caching in 3.4.4. I noticed 
better cache hits after upgrading to the 3.4.4 version. I am now running 
3.4.4.2 since there was a connect bug also fixed in this version. 



Best regards,
The Geek Guy

Lawrence Pingree
http://www.lawrencepingree.com/resume/

Author of "The Manager's Guide to Becoming Great"
http://www.Management-Book.com
 


-Original Message-
From: Amos Jeffries [mailto:squ...@treenet.co.nz] 
Sent: Monday, April 28, 2014 10:14 AM
To: squid-users@squid-cache.org
Subject: Re: [squid-users] Cache-Control: public doesn't cache

On 29/04/2014 4:19 a.m., Rob van der Putten wrote:
> Hi
> 
> 
> AFAIK 'Cache-Control: public, no-transform' is cacheable. But Squid
> (3.3.8) doesn't cache.
> 

That one header does not make it cacheable...
 * "no-transform" has no meaning at all in regards to cacheability.
 * "public" is only meaningful when authentication is being used.


... in HTTP/1.1 everything is considered cacheable unless the protocol defines 
a reason not to.

Squid may choose not to cache for many other reasons related to the request 
headers, response headers, server trustworthiness, age of the object on 
arrival, and available storage space.

Some reasons in the protocol are broad, like "a response to an unknown method 
is not cacheable". **

Others are very specific, like "a cached object with Cache-Control no-cache or 
must-revalidate may only be used as a response after a successful revalidation 
(304 not modified) from the origin server." **

** very rough paraphrasing by me.

Amos

Re: [squid-users] Cache-Control / Max-Age / Squid

[Mark Elsen]

On 8/26/05, Marco C. Coelho <[EMAIL PROTECTED]> wrote:
> One of the sites we host has a couple of large organizations that hit
> the site.
> 
> Recently, we have been getting complaints that the users are getting:
> 
> "You don't have permission to access / on this server"
> 
> Both of these customers use Squid or some variant.
> 
> This appears to be related to the Cache-Control: max-age = 259200 within
> their request.
> 
> When I touch all files in the http directory all is well.
> 
> Any thoughts to squid settings that would cause this.  We don't have
> this problem with our squid setup.
> 
 

  To find outh whether squid could be the cause , checkout
access.log and cache.log.

 M.

[squid-users] Cache-control modification and accelarator mode

[Gabriel Wicke]

Hi,

i'm using squid as an accelarator for Plone, a CMS built on Zope.

On the xhtml content i set the Cache-control header as
must-revalidate,max-age=0,s-maxage=36000. 
The browser will always check back for changes, squid will get a purge
request if something changes.

This breaks as soon as some transparent proxy gets in the way that picks
up the s-maxage header.

So i'd like to strip any s-maxage headers or set them to 0 when passing
through squid. I took a look at header_access and header_replace:

header_access Cache-control deny all
header_replace Cache-control Must-revalidate,max-age=0,s-maxage=0

This makes the browser check back for everything on every request
(stylesheets, pics...), very slow. 

What i'd like to achieve is a conditional replace only if s-maxage was
included in the original header. Is this possible with some acl matching
magic?

Thanks for any ideas!

Gabriel

Re: [squid-users] Cache-Control problems with Korean sites

[Amos Jeffries]

Mike Mitchell wrote:

We're having problems accessing Korean Government sites like parcel.epost.go.kr and 
www.g2b.go.kr from a squid cache that is physically in 
Seoul, Korea.  I performed network captures and found that if the request included a 
'Cache-Control' header the remote server did not send TCP ACK messages back for the 
request.  The remote server did complete the three-way TCP connection handshake, but 
would not acknowledge the request.  When I stripped the 'Cache-Control' header using

  acl NoCacheCtl dstdomain .epost.go.kr .gtb.go.kr
  header_access Cache-Control deny NoCacheCtl

the TCP ACKs started coming back and we could retrieve content.

My guess is there is a firewall protecting the remote web servers.  Has anyone 
seen this behavior before?


Any cache-control values? or just specific ones?

It's really up to whoever runs the broken software to fix the issue. 
Just find out where the breakage is and yell loudly at them.


Amos
--
Please be using
  Current Stable Squid 2.7.STABLE6 or 3.0.STABLE16
  Current Beta Squid 3.1.0.10 or 3.1.0.11

RE: [squid-users] Cache-Control problems with Korean sites

[Mike Mitchell]

I used telnet to connect to the problem web server and sent a minimal HTTP 
request.  The web server returned a page, so I tried again adding a header from 
the trace one at a time until I did not get a response.  I only tried one value 
of Cache-Control, max-age=0.

I've tried accessing the Korean Government sites from other proxy servers 
around the world and I get the same behavior.  I know the problem isn't with 
the proxy server's ISP, but rather with the Korean Government sites.

Mike Mitchell

-Original Message-
From: Amos Jeffries [mailto:squ...@treenet.co.nz]
Sent: Tuesday, July 21, 2009 2:37 AM
To: Mike Mitchell
Cc: squid-users@squid-cache.org
Subject: Re: [squid-users] Cache-Control problems with Korean sites

Mike Mitchell wrote:
> We're having problems accessing Korean Government sites like 
> parcel.epost.go.kr and www.g2b.go.kr<http://www.g2b.go.kr> from a squid cache 
> that is physically in Seoul, Korea.  I performed network captures and found 
> that if the request included a 'Cache-Control' header the remote server did 
> not send TCP ACK messages back for the request.  The remote server did 
> complete the three-way TCP connection handshake, but would not acknowledge 
> the request.  When I stripped the 'Cache-Control' header using
>
>   acl NoCacheCtl dstdomain .epost.go.kr .gtb.go.kr
>   header_access Cache-Control deny NoCacheCtl
>
> the TCP ACKs started coming back and we could retrieve content.
>
> My guess is there is a firewall protecting the remote web servers.  Has 
> anyone seen this behavior before?

Any cache-control values? or just specific ones?

It's really up to whoever runs the broken software to fix the issue.
Just find out where the breakage is and yell loudly at them.

Amos
--
Please be using
   Current Stable Squid 2.7.STABLE6 or 3.0.STABLE16
   Current Beta Squid 3.1.0.10 or 3.1.0.11

RE: [squid-users] Cache-Control problems with Korean sites

[Amos Jeffries]

On Tue, 21 Jul 2009 10:09:32 -0400, Mike Mitchell 
wrote:
> I used telnet to connect to the problem web server and sent a minimal
HTTP
> request.  The web server returned a page, so I tried again adding a
header
> from the trace one at a time until I did not get a response.  I only
tried
> one value of Cache-Control, max-age=0.
> 
> I've tried accessing the Korean Government sites from other proxy servers
> around the world and I get the same behavior.  I know the problem isn't
> with the proxy server's ISP, but rather with the Korean Government sites.

Okay so its definitely that issue then. Very strange.

The safe approach is to leave the site inaccessible and nag their admin(s)
until its fixed.

The header stripping may be the best short-term workaround if the above is
not an option. Being squid-2 it will also need a bit more work to make it
safe and not strip the reply controls (think of your Squid acting as a
Cache-Control: private remover for government security logins).
 * Try to strip the reply controls: I'd add an external ACL that takes only
the _request_ Cache-Control header and returns false if its missing.

I'd also add a "cache deny NoCacheCtl" rule to prevent your Squid being
poisoned by any bad data coming back.

And most definitely track down someone who can look at the issue and nag
them until its fixed. I can't stress how important that is.

Amos

> 
> Mike Mitchell
> 
> -Original Message-
> From: Amos Jeffries [mailto:squ...@treenet.co.nz]
> Sent: Tuesday, July 21, 2009 2:37 AM
> To: Mike Mitchell
> Cc: squid-users@squid-cache.org
> Subject: Re: [squid-users] Cache-Control problems with Korean sites
> 
> Mike Mitchell wrote:
>> We're having problems accessing Korean Government sites like
>> parcel.epost.go.kr and www.g2b.go.kr<http://www.g2b.go.kr> from a squid
>> cache that is physically in Seoul, Korea.  I performed network captures
>> and found that if the request included a 'Cache-Control' header the
>> remote server did not send TCP ACK messages back for the request.  The
>> remote server did complete the three-way TCP connection handshake, but
>> would not acknowledge the request.  When I stripped the 'Cache-Control'
>> header using
>>
>>   acl NoCacheCtl dstdomain .epost.go.kr .gtb.go.kr
>>   header_access Cache-Control deny NoCacheCtl
>>
>> the TCP ACKs started coming back and we could retrieve content.
>>
>> My guess is there is a firewall protecting the remote web servers.  Has
>> anyone seen this behavior before?
> 
> Any cache-control values? or just specific ones?
> 
> It's really up to whoever runs the broken software to fix the issue.
> Just find out where the breakage is and yell loudly at them.
> 
> Amos
> --
> Please be using
>Current Stable Squid 2.7.STABLE6 or 3.0.STABLE16
>Current Beta Squid 3.1.0.10 or 3.1.0.11

Re: [squid-users] Cache-Control problems with Korean sites

[Henrik Nordstrom]

mån 2009-07-20 klockan 09:49 -0400 skrev Mike Mitchell:

> My guess is there is a firewall protecting the remote web servers.  Has 
> anyone seen this behavior before?

Have not seen it on this level.

Generally the type of issues you describe is either Window Scaling or
ECN related (both are standardized TCP features frequently broken by old
firewalls), but I have not heard of Cache-Control having any impact on
it before...

Regards
Henrik

Re: [squid-users] Cache-Control problems with Korean sites

[Henrik Nordstrom]

mån 2009-07-20 klockan 09:49 -0400 skrev Mike Mitchell:
> We're having problems accessing Korean Government sites like
> parcel.epost.go.kr and www.g2b.go.kr from a
> squid cache that is physically in Seoul, Korea.  I performed network
> captures and found that if the request included a 'Cache-Control'
> header the remote server did not send TCP ACK messages back for the
> request.  The remote server did complete the three-way TCP connection
> handshake, but would not acknowledge the request.  When I stripped the
> 'Cache-Control' header using

Heh, just tried with Firefox without using a proxy and I can reproduce
the problem by simply hitting the reload button.

Regards
Henrik

[squid-users] cache-control header causes site to fail

[Graeme Bisset]

Hi,

I'm trying to access the site http://www.kinderopvang-plein.nl

It works without going through squid but when I do I get a 403 forbidden
error.

I've tracked this down to the cache-control header that squid adds (and
more precisely the value it specifies) by running the following wget
commands...

This command fails...
wget --spider --header='Cache-Control: max-age=259200'
www.kinderopvang-plein.nl

This command works...
wget --spider --header='Cache-Control: max-age=1000'
www.kinderopvang-plein.nl

I take it this is a problem with the web server not coping with the
higher max-age values but is there a way to configure squid so that it
uses smaller values by default?

Thanks in advance,

Graeme


This message has been scanned for viruses by BlackSpider MailControl - 
www.blackspider.com

Re: [squid-users] Cache-control modification and accelarator mode

[Henrik Nordstrom]

On Thu, 18 Dec 2003, Gabriel Wicke wrote:

> On the xhtml content i set the Cache-control header as
> must-revalidate,max-age=0,s-maxage=36000. 
> The browser will always check back for changes, squid will get a purge
> request if something changes.
> 
> This breaks as soon as some transparent proxy gets in the way that picks
> up the s-maxage header.

Does not need to be a transparent proxy, just any proxy supporting 
s-maxage will do this.

The above headers says

  * Shared caches (i.e. proxies) may cache the object for 36000 seconds
  * All other caches (i.e. browsers) must check with their source (i.e. 
the proxy in proxied environment) if the source knows about a newer copy.

> So i'd like to strip any s-maxage headers or set them to 0 when passing
> through squid. I took a look at header_access and header_replace:
> 
> header_access Cache-control deny all
> header_replace Cache-control Must-revalidate,max-age=0,s-maxage=0
> 
> This makes the browser check back for everything on every request
> (stylesheets, pics...), very slow. 
> 
> What i'd like to achieve is a conditional replace only if s-maxage was
> included in the original header. Is this possible with some acl matching
> magic?

If you know which URLs you need to do this on then just make 
a urlpath_regex pattern matching which URLs this need to be done on (or 
not done on) and then use this in header_access when determining if the 
header should be replaced.

Regards
Henrik

[squid-users] Cache-Control is ignored upon 202 (accept) response

[Boaz Citrin]

Hello,

I want to invalidate the cache when my server returns 202 to a PUT
request, however it seems like Squid ignores the Cache-Control when
return code is 202.
Tried to set must-revalidate or even not to return any Cache-Control
header but these all result no update to cache so subsequent GET
request results HIT while I expect a MISS.

Thanks,

Boaz

RE: [squid-users] cache-control header causes site to fail

[Graeme Bisset]

Ah I've found another thread with the same problem...

http://www.squid-cache.org/mail-archive/squid-users/200509/0204.html

Is the refresh pattern still the only way to fix this issue?

Thanks,

Graeme

> -Original Message-
> From: Graeme Bisset [mailto:[EMAIL PROTECTED]
> Sent: 17 November 2005 13:47
> To: squid-users@squid-cache.org
> Subject: [squid-users] cache-control header causes site to fail
> 
> Hi,
> 
> I'm trying to access the site http://www.kinderopvang-plein.nl
> 
> It works without going through squid but when I do I get a 403
forbidden
> error.
> 
> I've tracked this down to the cache-control header that squid adds
(and
> more precisely the value it specifies) by running the following wget
> commands...
> 
> This command fails...
> wget --spider --header='Cache-Control: max-age=259200'
> www.kinderopvang-plein.nl
> 
> This command works...
> wget --spider --header='Cache-Control: max-age=1000'
> www.kinderopvang-plein.nl
> 
> I take it this is a problem with the web server not coping with the
> higher max-age values but is there a way to configure squid so that it
> uses smaller values by default?
> 
> Thanks in advance,
> 
> Graeme
> 
> 
> This message has been scanned for viruses by BlackSpider MailControl -
> www.blackspider.com

RE: [squid-users] cache-control header causes site to fail

[Henrik Nordstrom]

On Thu, 17 Nov 2005, Graeme Bisset wrote:


Ah I've found another thread with the same problem...

http://www.squid-cache.org/mail-archive/squid-users/200509/0204.html

Is the refresh pattern still the only way to fix this issue?


It's a very broken web server.

Your options are to

 a) Contact the site owner and have them fix their web server. If you 
manage to get in hold with anyone reasonably clueful maintaining one of 
these sites then they are welcome to contact me for further discussion 
regarding this web server issue if they need additional explanations.


 b) Use refresh_pattern to work around the brokenness of the site.


It is NOT a Squid problem at all. It's just that the default settings of 
Squid happens to trigger this bug in these web servers while most direct 
browser connections do not.. But there is browsers having settings 
triggering this web server bug as well.


Regards
Henrik

Re: [squid-users] Cache-Control is ignored upon 202 (accept) response

[Amos Jeffries]

On 23/01/2014 3:04 a.m., Boaz Citrin wrote:
> Hello,
> 
> I want to invalidate the cache when my server returns 202 to a PUT
> request, however it seems like Squid ignores the Cache-Control when
> return code is 202.
> Tried to set must-revalidate or even not to return any Cache-Control
> header but these all result no update to cache so subsequent GET
> request results HIT while I expect a MISS.

Which version of Squid are you using?

Have you any unusual patch applied which might affect caching?

Are you using Store-URL or Store-ID features?

Have you enabled SMP workers?

Is the URL used in PUT presenting a Vary response to GET?

Amos

Fwd: [squid-users] Cache-Control is ignored upon 202 (accept) response

[Boaz Citrin]

I am using 2.7.STABLE8 on Windows. No patch, just the installer from
http://sourceforge.net/projects/squidwindowsmsi/

Also NOT using Store ID/Url features, also probably not using SMP
either as I am not familiar with it.

Not sure about the "Vary" question anyway the request/response don't
contain this header.

Thanks.


On Thu, Jan 23, 2014 at 9:19 AM, Amos Jeffries  wrote:
> On 23/01/2014 3:04 a.m., Boaz Citrin wrote:
>> Hello,
>>
>> I want to invalidate the cache when my server returns 202 to a PUT
>> request, however it seems like Squid ignores the Cache-Control when
>> return code is 202.
>> Tried to set must-revalidate or even not to return any Cache-Control
>> header but these all result no update to cache so subsequent GET
>> request results HIT while I expect a MISS.
>
> Which version of Squid are you using?
>
> Have you any unusual patch applied which might affect caching?
>
> Are you using Store-URL or Store-ID features?
>
> Have you enabled SMP workers?
>
> Is the URL used in PUT presenting a Vary response to GET?
>
> Amos
>

[squid-users] Cache-Control: header overwrite doesnt seem to work (squid 2.7)

[Christian Seifert]

Hi there, I am trying to cache 404 responses that have the Cache-Control header 
set to private by configuring squid to ignore such caching. It seems to work 
fine for 200 responses, but fails to work on 404 responses.

I adjusted the squid conf the following way:
refresh_pattern 99 100% 99 override-expire ignore-reload
override-lastmod ignore-no-cache ignore-private ignore-auth
ignore-stale-while-revalidate.

And then I also tried to remove the Cache-Control Header via the:
header_access Cache-Control deny all


/usr/local/squid/bin/squidclient -p 3128 -h 192.168.75.133 
http://www.google.com/idontexist
HTTP/1.0 404 Not Found
Content-Type: text/html; charset=ISO-8859-1
Date: Wed, 07 May 2008 14:47:00 GMT
Server: gws
X-Cache: MISS from localhost.localdomain
Via: 1.0 localhost.localdomain:3128 (squid/2.7.DEVEL0-20080506)
Connection: close

more access.log 
1210171620.299 75 192.168.75.133 TCP_MISS/404 7682 GET 
http://www.google.com/idontexist - DIRECT/72.14.253.104 text/html
1210171629.695 63 192.168.75.133 TCP_MISS/404 7682 GET 
http://www.google.com/idontexist - DIRECT/72.14.253.104 text/html


Bug? Configuration mistake?

Christian


  

Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

[squid-users] Cache-Control is ignored upon 202 (accept) response (re-post)

[Boaz Citrin]

Hello,

I want to invalidate the cache when my server returns 202 to a PUT
request, however it seems like Squid ignores the Cache-Control when
return code is 202.

Tried to set must-revalidate or even not to return any Cache-Control
header but these all result no update to cache so subsequent GET
request results HIT while I expect a MISS.
Note that Vary header is not present in response.

I am using 2.7.STABLE8 on Windows. No patch, just the installer from
http://sourceforge.net/projects/squidwindowsmsi/

Also NOT using Store ID/Url features, also probably not using SMP
either as I am not familiar with it.

I wonder if there is any way to tweak the config to force caching on
202 response.

Thanks,

Boaz

Re: [squid-users] Cache-Control: header overwrite doesnt seem to work (squid 2.7)

[Adrian Chadd]

File a bugzilla report?


Adrian

On Thu, May 08, 2008, Christian Seifert wrote:
> Hi there, I am trying to cache 404 responses that have the Cache-Control 
> header set to private by configuring squid to ignore such caching. It seems 
> to work fine for 200 responses, but fails to work on 404 responses.
> 
> I adjusted the squid conf the following way:
> refresh_pattern 99 100% 99 override-expire ignore-reload
> override-lastmod ignore-no-cache ignore-private ignore-auth
> ignore-stale-while-revalidate.
> 
> And then I also tried to remove the Cache-Control Header via the:
> header_access Cache-Control deny all
> 
> 
> /usr/local/squid/bin/squidclient -p 3128 -h 192.168.75.133 
> http://www.google.com/idontexist
> HTTP/1.0 404 Not Found
> Content-Type: text/html; charset=ISO-8859-1
> Date: Wed, 07 May 2008 14:47:00 GMT
> Server: gws
> X-Cache: MISS from localhost.localdomain
> Via: 1.0 localhost.localdomain:3128 (squid/2.7.DEVEL0-20080506)
> Connection: close
> 
> more access.log 
> 1210171620.299 75 192.168.75.133 TCP_MISS/404 7682 GET 
> http://www.google.com/idontexist - DIRECT/72.14.253.104 text/html
> 1210171629.695 63 192.168.75.133 TCP_MISS/404 7682 GET 
> http://www.google.com/idontexist - DIRECT/72.14.253.104 text/html
> 
> 
> Bug? Configuration mistake?
> 
> Christian
> 
> 
>   
> 
> Be a better friend, newshound, and 
> know-it-all with Yahoo! Mobile.  Try it now.  
> http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

-- 
- 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] cache-control: no-transform - does it affect caching of pages & content?

[Adrian Miller]

Recently i added cache-control: no-transform to Firefox's ModifyHeader 
addon, expressly to stop vodafone adding its 1.2.3.4/bms.js  (to reduce 
image quality/bandwidth) to EVERY page it serves me.


Other suggestions on the vodafone js insertion was to use cache-control: 
no-cache and/or pragma: no-cache


I chose to try no-transform in just cache-control as i thought it was 
potentially less drama


After doing so im looking at my ratios and think that they may be lower 
than before i added this directive via the addon.


Any gurus out there have an opinion on whether this affects caching or 
not, to my understanding it shouldn't affect things, but just wanting 
some clarification.


Thanks in advance,

Adrian Miller

Re: [squid-users] Cache-Control is ignored upon 202 (accept) response (re-post)

[Amos Jeffries]

On 16/02/2014 10:41 p.m., Boaz Citrin wrote:
> Hello,
> 
> I want to invalidate the cache when my server returns 202 to a PUT
> request, however it seems like Squid ignores the Cache-Control when
> return code is 202.

>From the latest specification
http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-26#section-4.3.4

"
   Responses to the PUT method are not cacheable.  If a successful PUT
   request passes through a cache that has one or more stored responses
   for the effective request URI, those stored responses will be
   invalidated (see Section 4.4 of [Part6]).
"

> 
> Tried to set must-revalidate or even not to return any Cache-Control
> header but these all result no update to cache so subsequent GET
> request results HIT while I expect a MISS.
> Note that Vary header is not present in response.
> 
> I am using 2.7.STABLE8 on Windows. No patch, just the installer from
> http://sourceforge.net/projects/squidwindowsmsi/


Your version of Squid is known to be only ~60% compliant with the
HTTP/1.1 specification and it seems this is possibly one of the missing
bits. Please consider an upgrade (sadly that means using a non-Windows
server for Squid).

Amos

Re: [squid-users] Cache-Control is ignored upon 202 (accept) response (re-post)

[Boaz Citrin]

Sorry, I confused between PUT and DELETE. Actually the DELETE is
request doesn't invalidate the cache on 202 response.
And this doesn't conform with the spec:
"If a DELETE
   request passes through a cache that has one or more stored responses
   for the effective request URI, those stored responses will be
   invalidated"

Any idea?

On Sun, Feb 16, 2014 at 12:42 PM, Amos Jeffries  wrote:
> On 16/02/2014 10:41 p.m., Boaz Citrin wrote:
>> Hello,
>>
>> I want to invalidate the cache when my server returns 202 to a PUT
>> request, however it seems like Squid ignores the Cache-Control when
>> return code is 202.
>
> From the latest specification
> http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-26#section-4.3.4
>
> "
>Responses to the PUT method are not cacheable.  If a successful PUT
>request passes through a cache that has one or more stored responses
>for the effective request URI, those stored responses will be
>invalidated (see Section 4.4 of [Part6]).
> "
>
>>
>> Tried to set must-revalidate or even not to return any Cache-Control
>> header but these all result no update to cache so subsequent GET
>> request results HIT while I expect a MISS.
>> Note that Vary header is not present in response.
>>
>> I am using 2.7.STABLE8 on Windows. No patch, just the installer from
>> http://sourceforge.net/projects/squidwindowsmsi/
>
>
> Your version of Squid is known to be only ~60% compliant with the
> HTTP/1.1 specification and it seems this is possibly one of the missing
> bits. Please consider an upgrade (sadly that means using a non-Windows
> server for Squid).
>
> Amos
>

Re: [squid-users] Cache-Control is ignored upon 202 (accept) response (re-post)

[Amos Jeffries]

On 17/02/2014 12:47 a.m., Boaz Citrin wrote:
> Sorry, I confused between PUT and DELETE. Actually the DELETE is
> request doesn't invalidate the cache on 202 response.
> And this doesn't conform with the spec:
> "If a DELETE
>request passes through a cache that has one or more stored responses
>for the effective request URI, those stored responses will be
>invalidated"
> 
> Any idea?

Are there Vary headers in the responses for the URL normally?

The DELETE invalidation process in Squid does not necessarily remove all
copies of variants.

Amos

> 
> On Sun, Feb 16, 2014 at 12:42 PM, Amos Jeffries  wrote:
>> On 16/02/2014 10:41 p.m., Boaz Citrin wrote:
>>> Hello,
>>>
>>> I want to invalidate the cache when my server returns 202 to a PUT
>>> request, however it seems like Squid ignores the Cache-Control when
>>> return code is 202.
>>
>> From the latest specification
>> http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-26#section-4.3.4
>>
>> "
>>Responses to the PUT method are not cacheable.  If a successful PUT
>>request passes through a cache that has one or more stored responses
>>for the effective request URI, those stored responses will be
>>invalidated (see Section 4.4 of [Part6]).
>> "
>>
>>>
>>> Tried to set must-revalidate or even not to return any Cache-Control
>>> header but these all result no update to cache so subsequent GET
>>> request results HIT while I expect a MISS.
>>> Note that Vary header is not present in response.
>>>
>>> I am using 2.7.STABLE8 on Windows. No patch, just the installer from
>>> http://sourceforge.net/projects/squidwindowsmsi/
>>
>>
>> Your version of Squid is known to be only ~60% compliant with the
>> HTTP/1.1 specification and it seems this is possibly one of the missing
>> bits. Please consider an upgrade (sadly that means using a non-Windows
>> server for Squid).
>>
>> Amos
>>

Re: [squid-users] cache-control: no-transform - does it affect caching of pages & content?

[Amos Jeffries]

On 18/05/2013 12:07 a.m., Adrian Miller wrote:
Recently i added cache-control: no-transform to Firefox's ModifyHeader 
addon, expressly to stop vodafone adding its 1.2.3.4/bms.js  (to 
reduce image quality/bandwidth) to EVERY page it serves me.


Other suggestions on the vodafone js insertion was to use 
cache-control: no-cache and/or pragma: no-cache


These have nothing to do with insertions. They will simply cause a MISS 
or revalidate on any cache along the way.




I chose to try no-transform in just cache-control as i thought it was 
potentially less drama


After doing so im looking at my ratios and think that they may be 
lower than before i added this directive via the addon.


Any gurus out there have an opinion on whether this affects caching or 
not, to my understanding it shouldn't affect things, but just wanting 
some clarification.


Thanks in advance,

Adrian Miller


That one does not affect caching.

If bms was altering the content in ways that broke caching your fix 
could be causing the performance optimizations built into HTTP to start 
working. Thats just a guess though.


Amos