* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Ticket #303 (closed design: fixed)

Opened 3 years ago

Last modified 11 months ago

400 response isn't generic

Reported by: mnot@pobox.com Owned by: mnot@pobox.com
Priority: normal Milestone: 24
Component: p2-semantics Severity: Active WG Document
Keywords: Cc:
Origin: http://www.w3.org/mid/E7DE53B9-C374-4C9B-81D2-1F35BFCC174F@mnot.net

Description (last modified by mnot@pobox.com) (diff)

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). """

Also, it currently says:

The client SHOULD NOT repeat the request without modifications.

To make it generically useful, it should say something like:

The client SHOULD NOT repeat the request without modifications, unless the response has a Retry-After header.

Change History

comment:1 Changed 3 years ago by mnot@pobox.com

  • Description modified (diff)

comment:2 Changed 3 years ago by mnot@pobox.com

  • Owner changed from draft-ietf-httpbis-p2-semantics@tools.ietf.org to mnot@pobox.com
  • Status changed from new to assigned

comment:3 Changed 3 years ago by mnot@pobox.com

  • Milestone changed from unassigned to 16

comment:4 Changed 3 years ago by julian.reschke@gmx.de

From [1342]:

400 response isn't generic (see #303)

comment:5 Changed 3 years ago by julian.reschke@gmx.de

  • Status changed from assigned to closed
  • Resolution set to incorporated

comment:6 Changed 3 years ago by mnot@pobox.com

  • Status changed from closed to reopened
  • Resolution incorporated deleted

comment:7 Changed 3 years ago by mnot@pobox.com

  • Status changed from reopened to closed
  • Resolution set to fixed

comment:8 Changed 16 months ago by mnot@pobox.com

  • Status changed from closed to reopened
  • Resolution fixed deleted

comment:9 Changed 16 months ago by mnot@pobox.com

This decision was editorially overridden in -21; please revert to reflect the issue resolution, or bring up why on-list.

comment:10 Changed 14 months ago by julian.reschke@gmx.de

From [2316]:

make description of status code 400 generic again (see #303)

comment:11 Changed 14 months ago by julian.reschke@gmx.de

  • Status changed from reopened to closed
  • Resolution set to incorporated
  • Milestone changed from 16 to 24

comment:12 Changed 14 months ago by fielding@gbiv.com

From [2325]:

For 400, note that the error is perceived to be from the client, and supply at least the minimum examples that cover what we require a 400 to be sent in p1; updates [2316] which addresses #303

comment:13 Changed 11 months ago by mnot@pobox.com

  • Status changed from closed to reopened
  • Resolution incorporated deleted

comment:14 Changed 11 months ago by mnot@pobox.com

  • Status changed from reopened to closed
  • Resolution set to fixed
Note: See TracTickets for help on using tickets.