This happends too if you have a proxy that asks ntlm username and password?
Ming Fu <fming_at_borderware.com> escribió:
> 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 Wed Jan 06 2010 - 13:54:00 MST
This archive was generated by hypermail 2.2.0 : Wed Jan 06 2010 - 12:00:03 MST