- From: Mark Nottingham <mnot@mnot.net>
- Date: Wed, 13 Jun 2012 20:21:16 +1000
- To: Willy Tarreau <w@1wt.eu>
- Cc: "Roy T. Fielding" <fielding@gbiv.com>, Tim Bray <tbray@textuality.com>, ietf-http-wg@w3.org
On 13/06/2012, at 3:51 PM, Willy Tarreau wrote: > Hi Roy, > > On Tue, Jun 12, 2012 at 10:35:12PM -0700, Roy T. Fielding wrote: >> On Jun 12, 2012, at 9:34 AM, Tim Bray wrote: >> >>> Aaaaaaaand, it turns out MNot was right; I checked with an expert, and 451 is heavily used for ?redirect? in the Msft ecosystem, notably including HotMail?s hundreds of millions of users. Consider it ?4xx? (which I would still argue for as opposed to 5xx). -T >> >> 4xx indicates an error by the user or user agent. I don't see >> any reason (aside from literary) that would justify using a 4xx >> code for this. 5xx is typically used for non-authoritative >> responses or server-imposed limitations -- a status that might >> be different if the user agent chose a different intermediary >> or tried again later. Hence, 5xx makes more sense here. > > 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 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? -- Mark Nottingham http://www.mnot.net/
Received on Wednesday, 13 June 2012 10:21:45 UTC