Subject: Generic semantics for the 400 status code

From: Mark Nottingham <[email-masked]>
Date: Fri, 15 Jul 2011 22:53:09 +1000

When people have error states that don't cleanly fit into an existing status code, they're often encouraged to use 400 or 500, depending on whether the client or server were at fault, as they're the most "generic" status codes.

500's definition fits this:

> 8.5.1.  500 Internal Server Error
> 
>    The server encountered an unexpected condition which prevented it
>    from fulfilling the request.

However, 400 is much more specific:

> 8.4.1.  400 Bad Request
> 
>    The request could not be understood by the server due to malformed
>    syntax.  The client SHOULD NOT repeat the request without
>    modifications.

I think the 400 definition needs to be broadened, so that people don't invent their own status codes, or misuse existing ones.

E.g.,

"""
The server can or will not process the request, due to a client error (e.g., malformed syntax).
"""

Additionally, I think we should move the caution against retrying the request to the general 4xx section (8.4)*.

Background:
  http://docs.openstack.org/cactus/openstack-compute/developer/openstack-compute-api-1.1/content/Synchronous_Faults-d1e1729.html#comment-213643851

Thoughts?

Cheers,

* Why is the "If the client is sending data..." section in p2 8.4? Seems like this belongs in p1...

--
Mark Nottingham   http://www.mnot.net/

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 15 Jul 2011 15:51:33 +0200

Hi Mark,

>   http://docs.openstack.org/cactus/openstack-compute/developer/openstack-compute-api-1.1/content/Synchronous_Faults-d1e1729.html#comment-213643851

I have mixed opinions on this point.

On the one hand, yes we said a server could use 503 + Retry-After for rate
shaping when it's overloaded. However in my opinion this is irrelevant to
the client and it might return that to any request during the overload
period. If the server is refusing to serve a client which is abusing, a 4xx
seems more appropriate, since the cause is this specific client, but I don't
see any existing one which fits the purpose.

I have a principle of always ensuring that a client cannot cause a server
to emit 5xx codes if the server is working correctly. This is important
for someone like me who spends a lot of time staring at gigs of logs,
because when you spot a 5xx, it means something is going wrong with the
server. The only exception I found to this was 501.

So my understanding has always been this :
  - if the request is rejected because of the client, 4xx
  - if the request is rejected regardless of the client, 5xx

The difference is important when intermediaries look at return codes.
Some might want to reduce connection pools to the server when they see
5xx. Some will declare a server down or failing when they see 5xx.

Anyway, in the discussion at the link above, I'm not even sure the user
needs to get a Retry-After : if the client is abusing its contract, then
we don't necessarily want to see him reconnect ASAP when the abuse is
over. Still it can make sense to define one 4xx for client abuse.

Just my 2 cents,
Willy

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 15 Jul 2011 23:55:45 +1000

Hi Willy,

> over. Still it can make sense to define one 4xx for client abuse.

So, do you support the proposal I made?

Note that this doesn't preclude minting a new status code if that's the right thing to do.

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 15 Jul 2011 16:05:32 +0200

> I think the 400 definition needs to be broadened, so that people don't invent their own status codes, or misuse existing ones.

Then yes I do support it. What I'm not in favor of is the use of the 503 that
was suggested on the openstack discussion -for this specific use- (and like
you, I too think that 403 was much closer to the need than 413).

Cheers,
Willy

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 17 Jul 2011 10:54:39 +1000

> The server can or will not process the request, due to a client error (e.g., malformed syntax).

This was logged as <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/303>.

> * Why is the "If the client is sending data..." section in p2 8.4? Seems like this belongs in p1...

This is now #302 <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/302> (editorial)

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 19 Jul 2011 23:02:01 +1000

I'm not hearing any pushback on this, so assigning for -16.

---

From: Julian Reschke <[email-masked]>
Date: Sat, 23 Jul 2011 19:38:48 +0200

> I'm not hearing any pushback on this, so assigning for -16.

Applied with <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/1342>.

Best regards, Julian