On Wednesday, March 14, 2001, at 04:43 PM, Graham Leggett wrote: > > On HTTP/1.0, it's the Pragma header (simply "Pragma: no cache"). The > Expires header gives the time when the object becomes non-fresh, as will > be revalidated. >
Oh, yes. Pragma. s/pragma/kludge/g I always forget those, because I loathe them so much. > On HTTP/1.1, it's the Cache-Control header, which has a whole lot of > options, like no-cache (same as "Pragma: no-cache"), no-store, and a > whole lot of others. Each object representation is represented by an > Etag (electronic tag?) which is a unique string which changes when the > object changes. This allows very fine control over whether an object is > fresh or not. > Very fine control, especially when you apply warnings. > > - Whenever I turn off box2, box1 will start spitting > > 502's (Bad gateway - proxy error) because it can't contact > > box2. > > Is there a fallback to serve directly from the cache (at > > least the data it has... the rest should 404... ) ? > > In theory using the Expires header correctly should support this, but > often browsers will send a conditional request for checking whether > cached data has changed - and this ends up all the way at the backend > which isn't there - so a bad gateway gets sent back up the chain. > > This is something I am keen to sort out in the v2.0 mod_proxy - handling > of dodgy or unreliable backend servers in a useful way. To do this > though means doing some things that break HTTP/1.1, so they'll have to > be special configuration options, and not the default. > > One way of doing this is - when the "special mode" is on - replace a 502 > Bad Gateway result from a conditional response with a 304 Not Modified. > This way when the browser or the intermediate proxy asks "is my cached > copy fresh" the Apache proxy will say "yes" - even though the backend > server is toasted and there is no way of being sure. > > There is nothing that can be done about normal requests - if the backend > is dead and nothing is cached then there is nothing the browser can show > (502 Bad Gateway). Sending a 404 is a bad idea - could send someone > mailing in saying "the file is missing" when in fact the server was > missing, sending admins on wild goose chases. > I think there's a pretty good walkthrough of how to do this in section 13 of RFC 2616. And Warning:111 Revalidation failed helps when sent along with the cached response instead of a 502. I think this falls under the 13.1.1 "fresh enough" case. Chuck Chuck Murcko Topsail Group http://www.topsail.org/
