Re: [squid-users] No-cache

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
>>
>
>
>
Received on Thu May 22 2014 - 11:15:27 MDT