Re: [squid-users] Forward Cache not working

From: Ming Fu <fming_at_borderware.com>
Date: Tue, 05 Jan 2010 13:55:54 -0500

On 01/05/2010 01:28 PM, Mike Makowski wrote:
> I understand that authenticated requests are not cache-able unless over
> written by Cache-control: public in server respond.
>
> I am assuming this is true even though the wget header responses above dont
> indicate any type of Private or Authenticated session. Is the fact that I am
> simply including a username and password in the wget command line enough for
> squid to assume this is not a cacheable session?
>
Yes, any request with Authorization header. The wget will add that
header on when you have username and passwd
> Since I experimented with the squid caching options to no avail last night
> could you please suggest a config file line with full syntax that I can try?
> Is it simply "Cache-control: public in server respond"?
>
Ask the server to put "Cache-Control: public" on the respond header if
you have control of it.
> Thanks
>
> Mike
>
>
> -----Original Message-----
> From: Mike Marchywka [mailto:marchywka_at_hotmail.com]
> Sent: Tuesday, January 05, 2010 6:15 AM
> To: mikem_at_btslink.com; crobertson_at_gci.net; squid-users_at_squid-cache.org
> Subject: RE: [squid-users] Forward Cache not working
>
>
>
> ----------------------------------------
>
>> From:
>> To: crobertson_at_gci.net; squid-users_at_squid-cache.org
>> Date: Mon, 4 Jan 2010 22:12:56 -0600
>> Subject: RE: [squid-users] Forward Cache not working
>>
>> I have attached is a screenshot of WGET header output with the "-S"
>>
> option.
>
> LOL, can you just email the text in a plain text email? If I didn't know
> better
> I'd think someone put you up to this- you often are forced to with GUI
> output
> from which concise ASCII information can not be extracted.
>
>
>
>> I see nothing about "private" in the headers so I'm assuming this content
>> should be getting cached. Yet, each time I run wget and then view the
>>
> Squid
>
>> access log it shows TCP_MISS on every attempt. I'll try the Ignore Private
>> parameter in squid just to make sure that isn't the cause.
>>
>
> You can look at ietf spec and grep it for each header key wget returned
> ( assuming you have an easy way to extract these from your jpg
> image that should be quite quick LOL). Text is interoperable, images
> require you buy some wget-to-ietf-GUI tool that converts the ietf spec
> into the same font as your wget output and looks for blocks of
> pixles that are the same ( sorry to beat this to death but it comes
> up a lot and creates a lot of problems in other contexts).
>
>
>
>> Very puzzling.
>>
>> Mike
>>
>> -----Original Message-----
>> From: Chris Robertson [mailto:crobertson_at_gci.net]
>> Sent: Monday, January 04, 2010 6:48 PM
>> To: squid-users_at_squid-cache.org
>> Subject: Re: [squid-users] Forward Cache not working
>>
>> Mike Makowski wrote:
>>
>>> Here is my basic config. Using defaults for everything else.
>>>
>>> acl localnet src 172.16.0.0/12
>>> http_access allow local_net
>>> maximum_object_size 25 MB
>>>
>>> Here is a log entry showing one connection from a LAN user through the
>>> proxy. I am guessing that the TCP_MISS is significant. Perhaps the
>>> original source is marked as Private as Chris suggested. Don't really
>>>
> know
>
>>> how to even tell that though.
>>>
>> Add a "-S" to wget to output the server headers.
>>
>> wget -S http://www.sortmonster.net/master/Updates/test.xyz -O test.new.gz
>> --header=Accept-Encoding:gzip --http-user=myuserid
>>
> --http-passwd=mypassword
>
>>
>>
>>> Can squid be forced to cache regardless of
>>> source settings?
>>>
>>>
>> Yes.
>>
> http://www.squid-cache.org/Versions/v3/3.0/cfgman/refresh_pattern.html
>
>> Keyword "ignore-private".
>>
>>
>>> 1262645523.217 305633 172.17.0.152 TCP_MISS/200 11674081 GET
>>> http://www.sortmonster.net/master/Updates/test.xyz - DIRECT/74.205.4.93
>>> application/x-sortmonster 1262645523.464 122
>>>
>>> Mike
>>>
>> Chris
>>
>
> _________________________________________________________________
> Hotmail: Trusted email with powerful SPAM protection.
> http://clk.atdmt.com/GBL/go/177141665/direct/01/=
>
Received on Tue Jan 05 2010 - 18:58:21 MST

This archive was generated by hypermail 2.2.0 : Wed Jan 06 2010 - 12:00:02 MST