Re: New Version Notification for draft-tbray-http-legally-restricted-status-00.txt

Mark Nottingham wrote:
> On 13/06/2012, at 3:51 PM, Willy Tarreau wrote:
>> I don't completely agree here : for me, 5xx means that the error is not
>> the client's fault and that it might randomly work if the client tries
>> again, which is why network errors fall into this category, as opposed
>> to the 4xx error by the user/user agent as you explained (and which I
>> agree with).
> 
> This is completely off base.
> 
> If the client retries the request, it might indeed work again --
> depending on what network path they're using, etc. That's why all
> of the intermediation-focused errors are in 5xx.

If the same user agent, making the same request, from the same location,
over the same access link, can randomly switch between a path implementing
the block to one not from request to request, then I think all that shows
is that the block is *very* poorly implemented.

In practice the block will be implemented evenly for a given end point,
and the client will never succeed in that (exact) request no matter how
hard they try. Their only hope of success is to get the status of that
resource changed, which makes it a 4xx error.

>> If a client requests a resource that is forbidden for legal
>> reasons, we're typically in the situation where the user caused the error
>> to happen by requesting this resource, and where if he tries again he will
>> get the same error again. Much like 403 or 404. 5xx would be appropriate
>> if the server was not able to verify in a database or referential whether
>> the resource is legally permitted or not.
> 
> Sorry, what? 

You have made the case that, following specific language from the standard,
"4xx status codes indicate that the problem is at the client; 5xx indicates
that the error is at the server."

Taking that at face value, with no wider context, why is 404 a 4xx error?
The client made a request that to any outside observer looks entirely valid,
and usually apart from the precise URL requested is indistinguishable from
another request to the same server which returned a 200 response. The client
could even be following a link within a document it previously retrieved from
that same server. (With appropriate response headers the 404 might even be
cached by an intermediary past the point at which the origin server has been
"fixed" to return 200 responses for the same request.) The resulting 4xx error
could hardly be said to be the client's "fault".

I'm not trying to be facetious here, nor do I think I'm being dense. I really
see this interpretation as an (apparently quite common) mistake based on taking
a very narrow definition of the terms "client error" and "server error" which
is not quite justified by the heading paragraphs (p3 S7.4 and S7.5 in httpbis,
little changed from the 2616 versions), is contradicted by the descriptions of
specific status codes, does not match established usage, and in practical
terms fails to divide the domain of possible error types neatly(ish) into two
classes with broadly distinct:

   * causes
      4xx related to the request, or the state of a specific resource or
          resources, server does not want to satisfy request
      5xx network/server wide, server does want to satisfy request but
          "can't"
   * expected lifetimes
      4xx for a valid request, will not go away until the status of the
          underlying resource is modified
      5xx might "spontaneously" resolve, or resolution doesn't directly involve
          the specific resource
   * useful immediate response strategies
      4xx authenticate, change representation, change some other aspect of
          the request, ask for something different, give up; might make
          (semi-)persistent updates to local state
      5xx retry, or pause, retry; avoid polluting cache/history
   * useful final resolution strategies
      4xx fix/change the status of the resource(s)
      5xx forget after a successful retry, reboot server, reconfigure network

Things can get muddy round the edges, and this status code is I think muddiest
around "causes" (though I think 4xx is still justified), but under any other
metric I can't see why it isn't clearly in 4xx territory.

Conversely I think 5xx (511) for captive portals *is* justified under the
above classification. ("reconfigure network" could mean "walk down to the hotel
lobby and hand over a fiver for network access".)

(As I said previously, I'm deeply unsure about 501, and unconvinced about 505.
My skepticism here is bolstered by the choice of specific status codes to act
on in RFC 5861. *If* the underlying code usage were consistent, surely it could
have been applied based on code class alone.)

John
--

Received on Wednesday, 13 June 2012 13:06:08 UTC