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

Ticket #229 (closed design: fixed)

Opened 4 years ago

Last modified 3 years ago

Considerations for new status codes

Reported by: mnot@pobox.com Owned by: mnot@pobox.com
Priority: normal Milestone: 12
Component: p2-semantics Severity: Active WG Document
Keywords: Cc:
Origin:

Description

We need to document what those who want to define new status codes need to consider / document.

E.g.,

  • Whether it allows heuristic freshness (p6)
  • What resource it carries a representation of (p2 6.1)

Change History

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

  • What the appropriate error class is
  • Considerations for zero-length bodies (i.e., you can't say it doesn't have a body)

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

HTTP status codes SHOULD be registered in a document that isn't specific to an application or other use of HTTP, so that it's clear that they are not specific to that application or extension.

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

  • Owner set to mnot@pobox.com

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

Proposal for new section in p2:

4.2 Considerations for New Status Codes

When it is necessary to express new semantics for a HTTP response that aren't specific to a single application or media type, and currently defined status codes are inadequate, a new status code can be registered [ref to 4.1].

New HTTP status codes MUST be defined in one of the categories defined in [ref to section 8]. They MUST NOT disallow a response body, although they MAY mandate a zero-length response body. They MAY require the presence of particular HTTP response header.

Likewise, their definitions MAY specify that caches are allowed to use heuristics to determine their freshness [ref to p6] (by default, it is not allowed), and MAY define how to determine the resource which they carry a representation for [ref to p2 6.1] (by default, it is anonymous).

If there are particular request conditions that produce a response containing the status code (e.g., request headers and/or method(s)), they SHOULD be described in detail.

New HTTP status codes SHOULD be registered in a document that isn't specific to an application or other use of HTTP, so that it's clear that they are not specific to that application or extension.

comment:5 Changed 4 years ago by mnot@pobox.com

  • Milestone changed from unassigned to 12

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

From [1035]:

Explain considerations for new status codes; addresses #229.

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

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

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

From [1038]:

Source reformat, update Changes section (see #229 and [1035])

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

  • Status changed from closed to reopened
  • Resolution incorporated deleted

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

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