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