Re: SHOULD-level requirements in p6-caching

Hi Mark,

On Mon, May 02, 2011 at 12:26:07PM +1000, Mark Nottingham wrote:
> Hi Willy,
> 
> Sorry, I thought I'd responded to this, but apparently not.

no problem.

> 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).

Oh too bad :-(

> > 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 ;)

It's not the only case. There are people who like to immediately tag a
server which responds 5xx as dead within a farm. This was implemented
in haproxy because there was such a demand (think about ad serving site
for instance, they prefer to quickly return a blank page than to wait
for an error and delay response on the site they're referenced).

You can fairly see that with this method, a client can reliably make the
server emit 504 and appear as faulty.

That said it's not critical, but I like to try to respect the server and
clients responsibilities as much as possible in status codes, so that 4xx
generally means that the request will not work until the client changes
it (eg: hitting reload is pointless), while 5xx means that something on
the server makes the request fail and that might change regardless of the
client's request (most often an overload or technical error). In our case
here, it's the client "only-if-cached" which makes it fail, reason why I
would find a 4xx more appropriate.

But if some code is already deployed with this, it's too late :-/

Cheers,
Willy

Received on Monday, 2 May 2011 05:55:40 UTC