Luca De Marinis Wrote:
-------------------------------------------------------
> On Wed, Jun 30, 2010 at 5:45 PM, bkirkbri wrote:
>
> >> I believe that even if you do, user agents and
> >> intermediate caches /
> >> proxies may decide not to honour them, so it
> may
> >> be pointless.
> >> Regards
> >
> > That's true in some cases, definitely.  I'd be
> interested in a list of
> > which browsers respect Cache-Control for non-200
> repsonses...
> >
> > But we might throw a reverse proxy cache in
> front of nginx, which would
> > respect those headers and take load off the
> nginx machine.  Check out
> >
> http://degizmo.com/2010/03/25/why-you-should-upstr
> eam-cache-your-404s/
>
> Interesting point, but I believe this is violating
> standards for
> performance (or maybe not, I don't know what the
> http rfc says about
> it), so I'd personally do it only for very good
> reasons; at our sites
> we don't get that many 404s so not caching them
> for us is preferable.
> Anyway if plan on using a reverse proxy it all
> changes because then
> you have fine control on when to purge a certain
> url, which obviously
> you don't have when your headers say "I can be
> saved by anything in
> between for 20 minutes". Even then, when I had to
> instruct a reverse
> proxy, I found it more convenient to use a custom
> header rather than
> munging cache-control, but my scenario was a bit
> different (I usually
> want caching to happen on my proxy, unless some
> conditions are met,
> and never want intermediate caches or UA's to
> presume they can cache
> my dynamic content).
>
> Bye

All good advice, thanks.

For what it's worth, the HTTP spec does allow caching of 404, 302, 301, etc. responses if the Cache-Control header is set explicitly by the origin. The spec forbids any caching of these responses without a Cache-Control header though, which is in contrast to the allowed behavior of caching 200 responses that do not have Cache-Control headers for some reasonable amount of time.