You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Dan Poirier <po...@pobox.com> on 2010/11/10 15:42:48 UTC
Any standard on picking a response status out of several possible?
If multiple response statuses would be valid for a request (e.g. 403,
413), is there any standard on how to pick one? I looked through RFC
2616 but didn't see anything. Or is it just an implementation detail?
Thanks,
Dan
RE: Any standard on picking a response status out of several possible?
Posted by Richard Chmura <ri...@unilytics.com>.
I don't know of an existing standard order. What this proposed set of
order:
Send the highest number response code error (413 and not 403).
For debug/testing environments, using expanded error messages or
concatenated messages might be suitable.
Richard
-----Original Message-----
From: Dan Poirier [mailto:poirier@pobox.com]
Sent: Wednesday, November 10, 2010 9:43 AM
To: dev@httpd.apache.org
Subject: Any standard on picking a response status out of several
possible?
If multiple response statuses would be valid for a request (e.g. 403,
413), is there any standard on how to pick one? I looked through RFC
2616 but didn't see anything. Or is it just an implementation detail?
Thanks,
Dan
Re: Any standard on picking a response status out of several possible?
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
On 10 Nov 2010, at 14:42, Dan Poirier wrote:
> If multiple response statuses would be valid for a request (e.g. 403,
> 413), is there any standard on how to pick one? I looked through RFC
> 2616 but didn't see anything. Or is it just an implementation detail?
This was subject of a fair bit of debate at the time; and from what I recall it was tried to reduce this to a non issue (i.e. letting the implementor make the call) by fairly carefully having the 2x/3x and 4x meaning right (success, retry with extra info and no-go) - along with making sure that the higher numbers are increasingly more narrow in their scope - with the assumption that implementors would only use those if the semantics where truly applicable and 'actionable' by a client.
Guess that does not answer the question - but in your example 403 (forbidden) vs 413 (too large) - one probably wants to ask the question - is there anything the client can do (perhaps change some POST/form parameter to reduce the requested size) - or is it purely forbidden because if its size. If it is the first I'd do a 413 (so smarter clients can reduce what they get) and distinguish it form a 403 lost case - while if it is the latter - a 403 will be more meaningful to a wider range of clients.
Hope that helps,
Dw