Re: Status code for censorship?

Mark Nottingham wrote:
> 4xx status codes indicate that the problem is at the client; 5xx
> indicates that the error is at the server.

While that appears to be true, I think this is a case where
ambiguity of the English language is colouring the technical side
of things. (I saw the /. discussion and saw many people making the
same argument for a 5xx code, and that's before you get to the ones
arguing for [6-9]xx codes or 4-digit codes(?!) or worse...)

Take the case of an origin server returning a 403 error: the
client has very likely made a request that is indistinguishable
from a valid request, yet the server alone has decided not to
satisfy it. I don't think this means that 403 should in fact have
been specified as a 5xx error!

To me the crucial difference between the two classes is what
resolution action a user-agent can take. For a 4xx code, the
client must change some aspect of the request if it is to expect
to proceed past the error. Some 4xx codes are suggestive of
specific resolutions (such as 401, or even 406); ones where the
client has no specific intelligence are not going to be
automatically resolvable but the basic premise stands.

For 5xx codes the client can have a reasonable expectation that
at some future time (which might be days or weeks if a collapsed
server needs rebooting!) the exact same request might not receive
an error. (Err. Without changing the underlying resource. Of
course "normal" 403s can be resolved with chmod, and 404 by
uploading the necessary file. That's different.)

(I think there's a stronger argument that 501 and 505 should have
been made 4xx errors, but it's Too Late Now.)

I don't think the above is new, I think it's generally understood
in practice, but I've seen this misconception often enough that
it might be worth saying so in the two heading sections in httpbis.

> [...]
> However, it'd need to get deployed. Since the primary objective
> of such a status code seems to be to raise the visibility of
> censorship, thereby (presumably) causing some reaction against it,
> it seems unlikely that it'll happen in places where there's strong
> oversight of whoever is deploying it.

It doesn't *have* to be deployed. It doesn't even *have* to be
standardised, really. Today, any unknown 4xx code is going to
invoke pretty much the same (and probably correct) client behaviour,
and as you noted, 403 is perfectly sensible here.

Using a non-403 code is a choice made by intermediaries that wish
to be transparent about what they are doing. And in that case,
reserving a code *might* be useful to avoid clashing with any future
standard code that suggests specific resolution actions that are
clearly not appropriate in this instance. People are already using
various different custom non-standardised codes for this and related
things though.

John
--

Received on Monday, 11 June 2012 17:24:11 UTC