RE: 500 status

RFC 2616

If squid can communicate with the server, it must serve the response
code last recieved (if still fresh). See point 3 and the text
afterwards.

Rob

====
13.1.1 Cache Correctness

   A correct cache MUST respond to a request with the most up-to-date
   response held by the cache that is appropriate to the request (see
   sections 13.2.5, 13.2.6, and 13.12) which meets one of the following
   conditions:

      1. It has been checked for equivalence with what the origin server
         would have returned by revalidating the response with the
         origin server (section 13.3);

Fielding, et al. Standards Track [Page 75]

RFC 2616 HTTP/1.1 June 1999

      2. It is "fresh enough" (see section 13.2). In the default case,
         this means it meets the least restrictive freshness requirement
         of the client, origin server, and cache (see section 14.9); if
         the origin server so specifies, it is the freshness requirement
         of the origin server alone.

         If a stored response is not "fresh enough" by the most
         restrictive freshness requirement of both the client and the
         origin server, in carefully considered circumstances the cache
         MAY still return the response with the appropriate Warning
         header (see section 13.1.5 and 14.46), unless such a response
         is prohibited (e.g., by a "no-store" cache-directive, or by a
         "no-cache" cache-request-directive; see section 14.9).

      3. It is an appropriate 304 (Not Modified), 305 (Proxy Redirect),
         or error (4xx or 5xx) response message.

   If the cache can not communicate with the origin server, then a
   correct cache SHOULD respond as above if the response can be
   correctly served from the cache; if not it MUST return an error or
   warning indicating that there was a communication failure.

> -----Original Message-----
> From: Brian Degenhardt [mailto:bmd@mp3.com]
> Sent: Thursday, 9 November 2000 12:59 PM
> To: squid-dev@squid-cache.org
> Subject: 500 status
>
>
> Reply-To:
>
> While using squid as a web accelerator, I've noticed that if
> a machine that
> it's attempting to accelerate crashes, or does not listen on
> port 80, squid
> will continue to serve it's stale cache object and log a
> TCP_REFRESH_HIT/200
> until the machine comes back up.
>
> This is nice because it adds a little robustness to the
> accelerated cluster.
>
> However, if the machine returns a 500 Internal Server Error
> response to
> squid's query on a stale item, squid removes the cached
> object and replaces
> it with a negatively cached error message. The same action
> is done with a
> 503 Status.
>
> Anyways, I was wondering why this is? I can't seem to find
> any text in
> rfc2068 that states what a cache should do in this situation,
> and it seems
> to me that an 'Internal Server Error' is close enough to
> 'machine crashed'
> that squid should behave the same.
>
> If I were to hack up a patch that made squid return the stale
> object and
> wait for a more concrete status before replacing it, would it
> be accepted?
>
> cheers
>
> -bmd
>
Received on Wed Nov 08 2000 - 19:07:47 MST