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

Re: p2: scope for status codes

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Wed, 24 Apr 2013 01:15:51 +1200
Message-ID: <51768987.5090001@treenet.co.nz>
To: Mark Nottingham <mnot@mnot.net>
CC: ietf-http-wg@w3.org
On 23/04/2013 3:08 p.m., Mark Nottingham wrote:
> On 21/04/2013, at 12:32 PM, Amos Jeffries wrote:
>
>> On 20/04/2013 9:14 p.m., Mark Nottingham wrote:
>>> Several status codes are defined in terms of indicating the server's intent, without specifying what kind of server it is.
>>>
>>> I believe there are several that we can make more specific without too much controversy. Specifically,
>>>
>>>    406 Not Acceptable
>>>    409 Conflict
>> Note: Squid uses 409 Conflict to signal CVE-2009-0801 validation mismatch between DNS, TCP and HTTP state as reason for messages being rejected. It is a client-end error and more expressive of the semantic problem than 400 or 500.
> Er, that *really* isn't what 409 means; it's a conflict in the state of the *resource*.

I think it fits. Resource O is being fetched. The information available 
indicates that it is *only* available on server A, B , C. Yet the client 
is fetching a copy from server Z.
  "These droids^W^Wresource is not the one you seek."


> 400 and a body / header is probably best for that.
>
>
>>>    500 Internal Service Error
>> Disagree strongly with 500. It is intentionally the generic "server" error to be sent by any server for edge case internal errors.
> OK, I'll buy that.
>
>
>>> can, I think, all be specified as being from the origin server.
>>>
>>> And, if we are still OK with 403 Forbidden being generated by both origins and intermediaries, it may be helpful to explicitly state that.
>> Agreed on that.
> OK, it sounds like the outcome here is to note that 403 can be generated by intermediaries, at the most. Let's just make it an editorial suggestion.

... and what you had in mind for 406 status.

Amos
Received on Tuesday, 23 April 2013 13:16:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:10 UTC