Re: [squid-users] No-cache

Thanks Amos, the problem actually lies I think in an embedded browser
control that has poor cache procedure adherence.

Your post gives me a few things to look in to though.

On Thu, May 22, 2014 at 12:15 PM, Amos Jeffries <squid3_at_treenet.co.nz> wrote:
> On 22/05/2014 9:50 p.m., Tom Holder wrote:
>> Hi Amos,
>>
>> Indeed it does, but the proxy is for a custom server/browse setup and
>> it's essential the browser doesn't cache, however, the server behind
>> squid is performing expensive operations so I want squid to cache it.
>>
>> Basically, I would cache in the browser, but I don't have granular
>> enough control to cache content in the way I need. site1.com might
>> look one way 1 second and then immediately serve completely different
>> content based on what a user does (a different header is sent).
>> Essentially the browser is getting confused and bleeding content
>> between these two (what it believes are identical, but aren't) sites.
>
> So the server (or your config of Squid?) is violating HTTP protocol, and
> your users are getting visible effects of the violation.
>
> The "fix" you asked for is this:
>
> acl site1 dstdomain site1.com
> http_reply_access Cache-Control deny site1
> http_reply_replace Cache-Control no-store
>
> Notice that the "confusion" problem very likely continues.
>
>>
>> In short, this isn't for browsing the internet :)
>
> Internet or not is irrelevant. These same details apply equally to
> "internal" noSQL database transactions, cloud server data exchanges,
> some chat program messaging, and app-based "txt" messaging - anything
> performed using HTTP request/response.
>
> What you are describing suggests the headers being deliverd by the
> server are breaking the basic HTTP protocol requirements for dynamic
> responses:
>
> 1) The server is required to send Vary: header listing *all* HTTP
> headers which it uses (or might use) to determine response content for
> the given URL. This list MUST be delivered in full on every response for
> the URL, even if some of the headers were not used for that particular
> response. If things beyond HTTP headers matter then "Vary: *" is to be
> sent in the reply.
>
> 2) The server is required to deliver ETag header uniquely identifying
> each response delivered.
>
> 3) If changes to the content matter for display/usage the server is
> required to deliver Date: and Last-Modified: and either Expires: or
> CacheControl:max-age values for the cache to determine how long it can
> used stored content before checking for updates to the object.
> OR, to deliver Cache-Control: no-cache/must-revalidate indicating
> mandatory revalidation on every client use.
>
>
> If the server itself is not following those basic RFC requirements then
> it does not matter which cache is storing the response. The problems
> will continue.
>
> Amos
>
>>
>> Tom
>>
>> On Thu, May 22, 2014 at 10:30 AM, Amos Jeffries wrote:
>>> On 22/05/2014 8:30 p.m., Tom Holder wrote:
>>>> Is it possible to get squid to throw out a no-cache header?
>>>>
>>>> I want squid to still serve up resources it might have in it's own
>>>> cache, but I want to force the browser not to cache what it's being
>>>> served.
>>>
>>> That defeats the primary purpose and benefit of caching: getting content
>>> stored as close to the user as possible.
>>>
>>> What version of Squid are you using?
>>> Are you running it as forward, reverse, or interception proxy?
>>>
>>> Amos
>>>
>>
>>
>>
>

-- 
Tom Holder
Systems Architect
Follow me on: [Twitter] [Linked In]
www.Simpleweb.co.uk
Tel: 0117 922 0448
Simpleweb Ltd.
Unit G, Albion Dockside Building, Hanover Place, Bristol, BS1 6UT
Simpleweb Ltd. is registered in England.
Registration no: 5929003 : V.A.T. registration no: 891600913