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