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 >> > > >
