- From: Mark Nottingham <mnot@mnot.net>
- Date: Mon, 2 May 2011 12:26:07 +1000
- To: Willy Tarreau <w@1wt.eu>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
Hi Willy, Sorry, I thought I'd responded to this, but apparently not. On 09/04/2011, at 4:05 PM, Willy Tarreau wrote: > On Thu, Apr 07, 2011 at 06:19:51PM +1000, Mark Nottingham wrote: >> In 3.2.1 (only-if-cached), >> >>> If it receives this >>> directive, a cache SHOULD either respond using a stored response >>> that is consistent with the other constraints of the request, or >>> respond with a 504 (Gateway Timeout) status code. >> >> MUST? > > Is there any reason for a 504 here ? I mean, 5xx are server-side errors > which should theorically not be decided by the client. In my opinion here > the client asks for an object and sets a condition to retrieve it, if the > object cannot be fetched from the cache, the client's condition cannot be > satisfied, so it should be a 4xx (possibly a 412 Precondition Failed). Basically, because this is the way it was specified, and this is already used in production (e.g., when Squid checks a peer for an object). > It is important to ensure that clients cannot force servers to emit 5xx > errors, because it is common to include status code checks when monitoring > production systems. If a cache emits a 504, usually it's because it cannot > reach the next hop so there is a connectivity issue that must be addressed. I see your point, but can imagine strategies for workaround; e.g., if the logs are being monitored, make the difference apparent in the logs; if the client is doing the monitoring, don't send only-if-cached ;) Cheers, -- Mark Nottingham http://www.mnot.net/
Received on Monday, 2 May 2011 02:26:34 UTC