W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2011

Re: SHOULD-level requirements in p6-caching

From: Mark Nottingham <mnot@mnot.net>
Date: Mon, 2 May 2011 12:26:07 +1000
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <587E888E-4CD0-4977-9299-D543B2DC1154@mnot.net>
To: Willy Tarreau <w@1wt.eu>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:40 GMT