tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 7231

 
 
 

Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content

Part 3 of 5, p. 47 to 73
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 47 
6.  Response Status Codes

   The status-code element is a three-digit integer code giving the
   result of the attempt to understand and satisfy the request.

   HTTP status codes are extensible.  HTTP clients are not required to
   understand the meaning of all registered status codes, though such
   understanding is obviously desirable.  However, a client MUST
   understand the class of any status code, as indicated by the first
   digit, and treat an unrecognized status code as being equivalent to
   the x00 status code of that class, with the exception that a
   recipient MUST NOT cache a response with an unrecognized status code.

   For example, if an unrecognized status code of 471 is received by a
   client, the client can assume that there was something wrong with its
   request and treat the response as if it had received a 400 (Bad
   Request) status code.  The response message will usually contain a
   representation that explains the status.

   The first digit of the status-code defines the class of response.
   The last two digits do not have any categorization role.  There are
   five values for the first digit:

   o  1xx (Informational): The request was received, continuing process

   o  2xx (Successful): The request was successfully received,
      understood, and accepted

   o  3xx (Redirection): Further action needs to be taken in order to
      complete the request

   o  4xx (Client Error): The request contains bad syntax or cannot be
      fulfilled

Top      Up      ToC       Page 48 
   o  5xx (Server Error): The server failed to fulfill an apparently
      valid request

6.1.  Overview of Status Codes

   The status codes listed below are defined in this specification,
   Section 4 of [RFC7232], Section 4 of [RFC7233], and Section 3 of
   [RFC7235].  The reason phrases listed here are only recommendations
   -- they can be replaced by local equivalents without affecting the
   protocol.

   Responses with status codes that are defined as cacheable by default
   (e.g., 200, 203, 204, 206, 300, 301, 404, 405, 410, 414, and 501 in
   this specification) can be reused by a cache with heuristic
   expiration unless otherwise indicated by the method definition or
   explicit cache controls [RFC7234]; all other status codes are not
   cacheable by default.

Top      Up      ToC       Page 49 
   +------+-------------------------------+--------------------------+
   | Code | Reason-Phrase                 | Defined in...            |
   +------+-------------------------------+--------------------------+
   | 100  | Continue                      | Section 6.2.1            |
   | 101  | Switching Protocols           | Section 6.2.2            |
   | 200  | OK                            | Section 6.3.1            |
   | 201  | Created                       | Section 6.3.2            |
   | 202  | Accepted                      | Section 6.3.3            |
   | 203  | Non-Authoritative Information | Section 6.3.4            |
   | 204  | No Content                    | Section 6.3.5            |
   | 205  | Reset Content                 | Section 6.3.6            |
   | 206  | Partial Content               | Section 4.1 of [RFC7233] |
   | 300  | Multiple Choices              | Section 6.4.1            |
   | 301  | Moved Permanently             | Section 6.4.2            |
   | 302  | Found                         | Section 6.4.3            |
   | 303  | See Other                     | Section 6.4.4            |
   | 304  | Not Modified                  | Section 4.1 of [RFC7232] |
   | 305  | Use Proxy                     | Section 6.4.5            |
   | 307  | Temporary Redirect            | Section 6.4.7            |
   | 400  | Bad Request                   | Section 6.5.1            |
   | 401  | Unauthorized                  | Section 3.1 of [RFC7235] |
   | 402  | Payment Required              | Section 6.5.2            |
   | 403  | Forbidden                     | Section 6.5.3            |
   | 404  | Not Found                     | Section 6.5.4            |
   | 405  | Method Not Allowed            | Section 6.5.5            |
   | 406  | Not Acceptable                | Section 6.5.6            |
   | 407  | Proxy Authentication Required | Section 3.2 of [RFC7235] |
   | 408  | Request Timeout               | Section 6.5.7            |
   | 409  | Conflict                      | Section 6.5.8            |
   | 410  | Gone                          | Section 6.5.9            |
   | 411  | Length Required               | Section 6.5.10           |
   | 412  | Precondition Failed           | Section 4.2 of [RFC7232] |
   | 413  | Payload Too Large             | Section 6.5.11           |
   | 414  | URI Too Long                  | Section 6.5.12           |
   | 415  | Unsupported Media Type        | Section 6.5.13           |
   | 416  | Range Not Satisfiable         | Section 4.4 of [RFC7233] |
   | 417  | Expectation Failed            | Section 6.5.14           |
   | 426  | Upgrade Required              | Section 6.5.15           |
   | 500  | Internal Server Error         | Section 6.6.1            |
   | 501  | Not Implemented               | Section 6.6.2            |
   | 502  | Bad Gateway                   | Section 6.6.3            |
   | 503  | Service Unavailable           | Section 6.6.4            |
   | 504  | Gateway Timeout               | Section 6.6.5            |
   | 505  | HTTP Version Not Supported    | Section 6.6.6            |
   +------+-------------------------------+--------------------------+

Top      Up      ToC       Page 50 
   Note that this list is not exhaustive -- it does not include
   extension status codes defined in other specifications.  The complete
   list of status codes is maintained by IANA.  See Section 8.2 for
   details.

6.2.  Informational 1xx

   The 1xx (Informational) class of status code indicates an interim
   response for communicating connection status or request progress
   prior to completing the requested action and sending a final
   response. 1xx responses are terminated by the first empty line after
   the status-line (the empty line signaling the end of the header
   section).  Since HTTP/1.0 did not define any 1xx status codes, a
   server MUST NOT send a 1xx response to an HTTP/1.0 client.

   A client MUST be able to parse one or more 1xx responses received
   prior to a final response, even if the client does not expect one.  A
   user agent MAY ignore unexpected 1xx responses.

   A proxy MUST forward 1xx responses unless the proxy itself requested
   the generation of the 1xx response.  For example, if a proxy adds an
   "Expect: 100-continue" field when it forwards a request, then it need
   not forward the corresponding 100 (Continue) response(s).

6.2.1.  100 Continue

   The 100 (Continue) status code indicates that the initial part of a
   request has been received and has not yet been rejected by the
   server.  The server intends to send a final response after the
   request has been fully received and acted upon.

   When the request contains an Expect header field that includes a
   100-continue expectation, the 100 response indicates that the server
   wishes to receive the request payload body, as described in
   Section 5.1.1.  The client ought to continue sending the request and
   discard the 100 response.

   If the request did not contain an Expect header field containing the
   100-continue expectation, the client can simply discard this interim
   response.

6.2.2.  101 Switching Protocols

   The 101 (Switching Protocols) status code indicates that the server
   understands and is willing to comply with the client's request, via
   the Upgrade header field (Section 6.7 of [RFC7230]), for a change in
   the application protocol being used on this connection.  The server

Top      Up      ToC       Page 51 
   MUST generate an Upgrade header field in the response that indicates
   which protocol(s) will be switched to immediately after the empty
   line that terminates the 101 response.

   It is assumed that the server will only agree to switch protocols
   when it is advantageous to do so.  For example, switching to a newer
   version of HTTP might be advantageous over older versions, and
   switching to a real-time, synchronous protocol might be advantageous
   when delivering resources that use such features.

6.3.  Successful 2xx

   The 2xx (Successful) class of status code indicates that the client's
   request was successfully received, understood, and accepted.

6.3.1.  200 OK

   The 200 (OK) status code indicates that the request has succeeded.
   The payload sent in a 200 response depends on the request method.
   For the methods defined by this specification, the intended meaning
   of the payload can be summarized as:

   GET  a representation of the target resource;

   HEAD  the same representation as GET, but without the representation
      data;

   POST  a representation of the status of, or results obtained from,
      the action;

   PUT, DELETE  a representation of the status of the action;

   OPTIONS  a representation of the communications options;

   TRACE  a representation of the request message as received by the end
      server.

   Aside from responses to CONNECT, a 200 response always has a payload,
   though an origin server MAY generate a payload body of zero length.
   If no payload is desired, an origin server ought to send 204 (No
   Content) instead.  For CONNECT, no payload is allowed because the
   successful result is a tunnel, which begins immediately after the 200
   response header section.

   A 200 response is cacheable by default; i.e., unless otherwise
   indicated by the method definition or explicit cache controls (see
   Section 4.2.2 of [RFC7234]).

Top      Up      ToC       Page 52 
6.3.2.  201 Created

   The 201 (Created) status code indicates that the request has been
   fulfilled and has resulted in one or more new resources being
   created.  The primary resource created by the request is identified
   by either a Location header field in the response or, if no Location
   field is received, by the effective request URI.

   The 201 response payload typically describes and links to the
   resource(s) created.  See Section 7.2 for a discussion of the meaning
   and purpose of validator header fields, such as ETag and
   Last-Modified, in a 201 response.

6.3.3.  202 Accepted

   The 202 (Accepted) status code indicates that the request has been
   accepted for processing, but the processing has not been completed.
   The request might or might not eventually be acted upon, as it might
   be disallowed when processing actually takes place.  There is no
   facility in HTTP for re-sending a status code from an asynchronous
   operation.

   The 202 response is intentionally noncommittal.  Its purpose is to
   allow a server to accept a request for some other process (perhaps a
   batch-oriented process that is only run once per day) without
   requiring that the user agent's connection to the server persist
   until the process is completed.  The representation sent with this
   response ought to describe the request's current status and point to
   (or embed) a status monitor that can provide the user with an
   estimate of when the request will be fulfilled.

6.3.4.  203 Non-Authoritative Information

   The 203 (Non-Authoritative Information) status code indicates that
   the request was successful but the enclosed payload has been modified
   from that of the origin server's 200 (OK) response by a transforming
   proxy (Section 5.7.2 of [RFC7230]).  This status code allows the
   proxy to notify recipients when a transformation has been applied,
   since that knowledge might impact later decisions regarding the
   content.  For example, future cache validation requests for the
   content might only be applicable along the same request path (through
   the same proxies).

   The 203 response is similar to the Warning code of 214 Transformation
   Applied (Section 5.5 of [RFC7234]), which has the advantage of being
   applicable to responses with any status code.

Top      Up      ToC       Page 53 
   A 203 response is cacheable by default; i.e., unless otherwise
   indicated by the method definition or explicit cache controls (see
   Section 4.2.2 of [RFC7234]).

6.3.5.  204 No Content

   The 204 (No Content) status code indicates that the server has
   successfully fulfilled the request and that there is no additional
   content to send in the response payload body.  Metadata in the
   response header fields refer to the target resource and its selected
   representation after the requested action was applied.

   For example, if a 204 status code is received in response to a PUT
   request and the response contains an ETag header field, then the PUT
   was successful and the ETag field-value contains the entity-tag for
   the new representation of that target resource.

   The 204 response allows a server to indicate that the action has been
   successfully applied to the target resource, while implying that the
   user agent does not need to traverse away from its current "document
   view" (if any).  The server assumes that the user agent will provide
   some indication of the success to its user, in accord with its own
   interface, and apply any new or updated metadata in the response to
   its active representation.

   For example, a 204 status code is commonly used with document editing
   interfaces corresponding to a "save" action, such that the document
   being saved remains available to the user for editing.  It is also
   frequently used with interfaces that expect automated data transfers
   to be prevalent, such as within distributed version control systems.

   A 204 response is terminated by the first empty line after the header
   fields because it cannot contain a message body.

   A 204 response is cacheable by default; i.e., unless otherwise
   indicated by the method definition or explicit cache controls (see
   Section 4.2.2 of [RFC7234]).

6.3.6.  205 Reset Content

   The 205 (Reset Content) status code indicates that the server has
   fulfilled the request and desires that the user agent reset the
   "document view", which caused the request to be sent, to its original
   state as received from the origin server.

   This response is intended to support a common data entry use case
   where the user receives content that supports data entry (a form,
   notepad, canvas, etc.), enters or manipulates data in that space,

Top      Up      ToC       Page 54 
   causes the entered data to be submitted in a request, and then the
   data entry mechanism is reset for the next entry so that the user can
   easily initiate another input action.

   Since the 205 status code implies that no additional content will be
   provided, a server MUST NOT generate a payload in a 205 response.  In
   other words, a server MUST do one of the following for a 205
   response: a) indicate a zero-length body for the response by
   including a Content-Length header field with a value of 0; b)
   indicate a zero-length payload for the response by including a
   Transfer-Encoding header field with a value of chunked and a message
   body consisting of a single chunk of zero-length; or, c) close the
   connection immediately after sending the blank line terminating the
   header section.

6.4.  Redirection 3xx

   The 3xx (Redirection) class of status code indicates that further
   action needs to be taken by the user agent in order to fulfill the
   request.  If a Location header field (Section 7.1.2) is provided, the
   user agent MAY automatically redirect its request to the URI
   referenced by the Location field value, even if the specific status
   code is not understood.  Automatic redirection needs to done with
   care for methods not known to be safe, as defined in Section 4.2.1,
   since the user might not wish to redirect an unsafe request.

   There are several types of redirects:

   1.  Redirects that indicate the resource might be available at a
       different URI, as provided by the Location field, as in the
       status codes 301 (Moved Permanently), 302 (Found), and 307
       (Temporary Redirect).

   2.  Redirection that offers a choice of matching resources, each
       capable of representing the original request target, as in the
       300 (Multiple Choices) status code.

   3.  Redirection to a different resource, identified by the Location
       field, that can represent an indirect response to the request, as
       in the 303 (See Other) status code.

   4.  Redirection to a previously cached result, as in the 304 (Not
       Modified) status code.

      Note: In HTTP/1.0, the status codes 301 (Moved Permanently) and
      302 (Found) were defined for the first type of redirect
      ([RFC1945], Section 9.3).  Early user agents split on whether the
      method applied to the redirect target would be the same as the

Top      Up      ToC       Page 55 
      original request or would be rewritten as GET.  Although HTTP
      originally defined the former semantics for 301 and 302 (to match
      its original implementation at CERN), and defined 303 (See Other)
      to match the latter semantics, prevailing practice gradually
      converged on the latter semantics for 301 and 302 as well.  The
      first revision of HTTP/1.1 added 307 (Temporary Redirect) to
      indicate the former semantics without being impacted by divergent
      practice.  Over 10 years later, most user agents still do method
      rewriting for 301 and 302; therefore, this specification makes
      that behavior conformant when the original request is POST.

   A client SHOULD detect and intervene in cyclical redirections (i.e.,
   "infinite" redirection loops).

      Note: An earlier version of this specification recommended a
      maximum of five redirections ([RFC2068], Section 10.3).  Content
      developers need to be aware that some clients might implement such
      a fixed limitation.

6.4.1.  300 Multiple Choices

   The 300 (Multiple Choices) status code indicates that the target
   resource has more than one representation, each with its own more
   specific identifier, and information about the alternatives is being
   provided so that the user (or user agent) can select a preferred
   representation by redirecting its request to one or more of those
   identifiers.  In other words, the server desires that the user agent
   engage in reactive negotiation to select the most appropriate
   representation(s) for its needs (Section 3.4).

   If the server has a preferred choice, the server SHOULD generate a
   Location header field containing a preferred choice's URI reference.
   The user agent MAY use the Location field value for automatic
   redirection.

   For request methods other than HEAD, the server SHOULD generate a
   payload in the 300 response containing a list of representation
   metadata and URI reference(s) from which the user or user agent can
   choose the one most preferred.  The user agent MAY make a selection
   from that list automatically if it understands the provided media
   type.  A specific format for automatic selection is not defined by
   this specification because HTTP tries to remain orthogonal to the
   definition of its payloads.  In practice, the representation is
   provided in some easily parsed format believed to be acceptable to
   the user agent, as determined by shared design or content
   negotiation, or in some commonly accepted hypertext format.

Top      Up      ToC       Page 56 
   A 300 response is cacheable by default; i.e., unless otherwise
   indicated by the method definition or explicit cache controls (see
   Section 4.2.2 of [RFC7234]).

      Note: The original proposal for the 300 status code defined the
      URI header field as providing a list of alternative
      representations, such that it would be usable for 200, 300, and
      406 responses and be transferred in responses to the HEAD method.
      However, lack of deployment and disagreement over syntax led to
      both URI and Alternates (a subsequent proposal) being dropped from
      this specification.  It is possible to communicate the list using
      a set of Link header fields [RFC5988], each with a relationship of
      "alternate", though deployment is a chicken-and-egg problem.

6.4.2.  301 Moved Permanently

   The 301 (Moved Permanently) status code indicates that the target
   resource has been assigned a new permanent URI and any future
   references to this resource ought to use one of the enclosed URIs.
   Clients with link-editing capabilities ought to automatically re-link
   references to the effective request URI to one or more of the new
   references sent by the server, where possible.

   The server SHOULD generate a Location header field in the response
   containing a preferred URI reference for the new permanent URI.  The
   user agent MAY use the Location field value for automatic
   redirection.  The server's response payload usually contains a short
   hypertext note with a hyperlink to the new URI(s).

      Note: For historical reasons, a user agent MAY change the request
      method from POST to GET for the subsequent request.  If this
      behavior is undesired, the 307 (Temporary Redirect) status code
      can be used instead.

   A 301 response is cacheable by default; i.e., unless otherwise
   indicated by the method definition or explicit cache controls (see
   Section 4.2.2 of [RFC7234]).

6.4.3.  302 Found

   The 302 (Found) status code indicates that the target resource
   resides temporarily under a different URI.  Since the redirection
   might be altered on occasion, the client ought to continue to use the
   effective request URI for future requests.

Top      Up      ToC       Page 57 
   The server SHOULD generate a Location header field in the response
   containing a URI reference for the different URI.  The user agent MAY
   use the Location field value for automatic redirection.  The server's
   response payload usually contains a short hypertext note with a
   hyperlink to the different URI(s).

      Note: For historical reasons, a user agent MAY change the request
      method from POST to GET for the subsequent request.  If this
      behavior is undesired, the 307 (Temporary Redirect) status code
      can be used instead.

6.4.4.  303 See Other

   The 303 (See Other) status code indicates that the server is
   redirecting the user agent to a different resource, as indicated by a
   URI in the Location header field, which is intended to provide an
   indirect response to the original request.  A user agent can perform
   a retrieval request targeting that URI (a GET or HEAD request if
   using HTTP), which might also be redirected, and present the eventual
   result as an answer to the original request.  Note that the new URI
   in the Location header field is not considered equivalent to the
   effective request URI.

   This status code is applicable to any HTTP method.  It is primarily
   used to allow the output of a POST action to redirect the user agent
   to a selected resource, since doing so provides the information
   corresponding to the POST response in a form that can be separately
   identified, bookmarked, and cached, independent of the original
   request.

   A 303 response to a GET request indicates that the origin server does
   not have a representation of the target resource that can be
   transferred by the server over HTTP.  However, the Location field
   value refers to a resource that is descriptive of the target
   resource, such that making a retrieval request on that other resource
   might result in a representation that is useful to recipients without
   implying that it represents the original target resource.  Note that
   answers to the questions of what can be represented, what
   representations are adequate, and what might be a useful description
   are outside the scope of HTTP.

   Except for responses to a HEAD request, the representation of a 303
   response ought to contain a short hypertext note with a hyperlink to
   the same URI reference provided in the Location header field.

Top      Up      ToC       Page 58 
6.4.5.  305 Use Proxy

   The 305 (Use Proxy) status code was defined in a previous version of
   this specification and is now deprecated (Appendix B).

6.4.6.  306 (Unused)

   The 306 status code was defined in a previous version of this
   specification, is no longer used, and the code is reserved.

6.4.7.  307 Temporary Redirect

   The 307 (Temporary Redirect) status code indicates that the target
   resource resides temporarily under a different URI and the user agent
   MUST NOT change the request method if it performs an automatic
   redirection to that URI.  Since the redirection can change over time,
   the client ought to continue using the original effective request URI
   for future requests.

   The server SHOULD generate a Location header field in the response
   containing a URI reference for the different URI.  The user agent MAY
   use the Location field value for automatic redirection.  The server's
   response payload usually contains a short hypertext note with a
   hyperlink to the different URI(s).

      Note: This status code is similar to 302 (Found), except that it
      does not allow changing the request method from POST to GET.  This
      specification defines no equivalent counterpart for 301 (Moved
      Permanently) ([RFC7238], however, defines the status code 308
      (Permanent Redirect) for this purpose).

6.5.  Client Error 4xx

   The 4xx (Client Error) class of status code indicates that the client
   seems to have erred.  Except when responding to a HEAD request, the
   server SHOULD send a representation containing an explanation of the
   error situation, and whether it is a temporary or permanent
   condition.  These status codes are applicable to any request method.
   User agents SHOULD display any included representation to the user.

6.5.1.  400 Bad Request

   The 400 (Bad Request) status code indicates that the server cannot or
   will not process the request due to something that is perceived to be
   a client error (e.g., malformed request syntax, invalid request
   message framing, or deceptive request routing).

Top      Up      ToC       Page 59 
6.5.2.  402 Payment Required

   The 402 (Payment Required) status code is reserved for future use.

6.5.3.  403 Forbidden

   The 403 (Forbidden) status code indicates that the server understood
   the request but refuses to authorize it.  A server that wishes to
   make public why the request has been forbidden can describe that
   reason in the response payload (if any).

   If authentication credentials were provided in the request, the
   server considers them insufficient to grant access.  The client
   SHOULD NOT automatically repeat the request with the same
   credentials.  The client MAY repeat the request with new or different
   credentials.  However, a request might be forbidden for reasons
   unrelated to the credentials.

   An origin server that wishes to "hide" the current existence of a
   forbidden target resource MAY instead respond with a status code of
   404 (Not Found).

6.5.4.  404 Not Found

   The 404 (Not Found) status code indicates that the origin server did
   not find a current representation for the target resource or is not
   willing to disclose that one exists.  A 404 status code does not
   indicate whether this lack of representation is temporary or
   permanent; the 410 (Gone) status code is preferred over 404 if the
   origin server knows, presumably through some configurable means, that
   the condition is likely to be permanent.

   A 404 response is cacheable by default; i.e., unless otherwise
   indicated by the method definition or explicit cache controls (see
   Section 4.2.2 of [RFC7234]).

6.5.5.  405 Method Not Allowed

   The 405 (Method Not Allowed) status code indicates that the method
   received in the request-line is known by the origin server but not
   supported by the target resource.  The origin server MUST generate an
   Allow header field in a 405 response containing a list of the target
   resource's currently supported methods.

   A 405 response is cacheable by default; i.e., unless otherwise
   indicated by the method definition or explicit cache controls (see
   Section 4.2.2 of [RFC7234]).

Top      Up      ToC       Page 60 
6.5.6.  406 Not Acceptable

   The 406 (Not Acceptable) status code indicates that the target
   resource does not have a current representation that would be
   acceptable to the user agent, according to the proactive negotiation
   header fields received in the request (Section 5.3), and the server
   is unwilling to supply a default representation.

   The server SHOULD generate a payload containing a list of available
   representation characteristics and corresponding resource identifiers
   from which the user or user agent can choose the one most
   appropriate.  A user agent MAY automatically select the most
   appropriate choice from that list.  However, this specification does
   not define any standard for such automatic selection, as described in
   Section 6.4.1.

6.5.7.  408 Request Timeout

   The 408 (Request Timeout) status code indicates that the server did
   not receive a complete request message within the time that it was
   prepared to wait.  A server SHOULD send the "close" connection option
   (Section 6.1 of [RFC7230]) in the response, since 408 implies that
   the server has decided to close the connection rather than continue
   waiting.  If the client has an outstanding request in transit, the
   client MAY repeat that request on a new connection.

6.5.8.  409 Conflict

   The 409 (Conflict) status code indicates that the request could not
   be completed due to a conflict with the current state of the target
   resource.  This code is used in situations where the user might be
   able to resolve the conflict and resubmit the request.  The server
   SHOULD generate a payload that includes enough information for a user
   to recognize the source of the conflict.

   Conflicts are most likely to occur in response to a PUT request.  For
   example, if versioning were being used and the representation being
   PUT included changes to a resource that conflict with those made by
   an earlier (third-party) request, the origin server might use a 409
   response to indicate that it can't complete the request.  In this
   case, the response representation would likely contain information
   useful for merging the differences based on the revision history.

6.5.9.  410 Gone

   The 410 (Gone) status code indicates that access to the target
   resource is no longer available at the origin server and that this
   condition is likely to be permanent.  If the origin server does not

Top      Up      ToC       Page 61 
   know, or has no facility to determine, whether or not the condition
   is permanent, the status code 404 (Not Found) ought to be used
   instead.

   The 410 response is primarily intended to assist the task of web
   maintenance by notifying the recipient that the resource is
   intentionally unavailable and that the server owners desire that
   remote links to that resource be removed.  Such an event is common
   for limited-time, promotional services and for resources belonging to
   individuals no longer associated with the origin server's site.  It
   is not necessary to mark all permanently unavailable resources as
   "gone" or to keep the mark for any length of time -- that is left to
   the discretion of the server owner.

   A 410 response is cacheable by default; i.e., unless otherwise
   indicated by the method definition or explicit cache controls (see
   Section 4.2.2 of [RFC7234]).

6.5.10.  411 Length Required

   The 411 (Length Required) status code indicates that the server
   refuses to accept the request without a defined Content-Length
   (Section 3.3.2 of [RFC7230]).  The client MAY repeat the request if
   it adds a valid Content-Length header field containing the length of
   the message body in the request message.

6.5.11.  413 Payload Too Large

   The 413 (Payload Too Large) status code indicates that the server is
   refusing to process a request because the request payload is larger
   than the server is willing or able to process.  The server MAY close
   the connection to prevent the client from continuing the request.

   If the condition is temporary, the server SHOULD generate a
   Retry-After header field to indicate that it is temporary and after
   what time the client MAY try again.

6.5.12.  414 URI Too Long

   The 414 (URI Too Long) status code indicates that the server is
   refusing to service the request because the request-target (Section
   5.3 of [RFC7230]) is longer than the server is willing to interpret.
   This rare condition is only likely to occur when a client has
   improperly converted a POST request to a GET request with long query
   information, when the client has descended into a "black hole" of
   redirection (e.g., a redirected URI prefix that points to a suffix of
   itself) or when the server is under attack by a client attempting to
   exploit potential security holes.

Top      Up      ToC       Page 62 
   A 414 response is cacheable by default; i.e., unless otherwise
   indicated by the method definition or explicit cache controls (see
   Section 4.2.2 of [RFC7234]).

6.5.13.  415 Unsupported Media Type

   The 415 (Unsupported Media Type) status code indicates that the
   origin server is refusing to service the request because the payload
   is in a format not supported by this method on the target resource.
   The format problem might be due to the request's indicated
   Content-Type or Content-Encoding, or as a result of inspecting the
   data directly.

6.5.14.  417 Expectation Failed

   The 417 (Expectation Failed) status code indicates that the
   expectation given in the request's Expect header field
   (Section 5.1.1) could not be met by at least one of the inbound
   servers.

6.5.15.  426 Upgrade Required

   The 426 (Upgrade Required) status code indicates that the server
   refuses to perform the request using the current protocol but might
   be willing to do so after the client upgrades to a different
   protocol.  The server MUST send an Upgrade header field in a 426
   response to indicate the required protocol(s) (Section 6.7 of
   [RFC7230]).

   Example:

     HTTP/1.1 426 Upgrade Required
     Upgrade: HTTP/3.0
     Connection: Upgrade
     Content-Length: 53
     Content-Type: text/plain

     This service requires use of the HTTP/3.0 protocol.

6.6.  Server Error 5xx

   The 5xx (Server Error) class of status code indicates that the server
   is aware that it has erred or is incapable of performing the
   requested method.  Except when responding to a HEAD request, the
   server SHOULD send a representation containing an explanation of the
   error situation, and whether it is a temporary or permanent

Top      Up      ToC       Page 63 
   condition.  A user agent SHOULD display any included representation
   to the user.  These response codes are applicable to any request
   method.

6.6.1.  500 Internal Server Error

   The 500 (Internal Server Error) status code indicates that the server
   encountered an unexpected condition that prevented it from fulfilling
   the request.

6.6.2.  501 Not Implemented

   The 501 (Not Implemented) status code indicates that the server does
   not support the functionality required to fulfill the request.  This
   is the appropriate response when the server does not recognize the
   request method and is not capable of supporting it for any resource.

   A 501 response is cacheable by default; i.e., unless otherwise
   indicated by the method definition or explicit cache controls (see
   Section 4.2.2 of [RFC7234]).

6.6.3.  502 Bad Gateway

   The 502 (Bad Gateway) status code indicates that the server, while
   acting as a gateway or proxy, received an invalid response from an
   inbound server it accessed while attempting to fulfill the request.

6.6.4.  503 Service Unavailable

   The 503 (Service Unavailable) status code indicates that the server
   is currently unable to handle the request due to a temporary overload
   or scheduled maintenance, which will likely be alleviated after some
   delay.  The server MAY send a Retry-After header field
   (Section 7.1.3) to suggest an appropriate amount of time for the
   client to wait before retrying the request.

      Note: The existence of the 503 status code does not imply that a
      server has to use it when becoming overloaded.  Some servers might
      simply refuse the connection.

6.6.5.  504 Gateway Timeout

   The 504 (Gateway Timeout) status code indicates that the server,
   while acting as a gateway or proxy, did not receive a timely response
   from an upstream server it needed to access in order to complete the
   request.

Top      Up      ToC       Page 64 
6.6.6.  505 HTTP Version Not Supported

   The 505 (HTTP Version Not Supported) status code indicates that the
   server does not support, or refuses to support, the major version of
   HTTP that was used in the request message.  The server is indicating
   that it is unable or unwilling to complete the request using the same
   major version as the client, as described in Section 2.6 of
   [RFC7230], other than with this error message.  The server SHOULD
   generate a representation for the 505 response that describes why
   that version is not supported and what other protocols are supported
   by that server.

7.  Response Header Fields

   The response header fields allow the server to pass additional
   information about the response beyond what is placed in the
   status-line.  These header fields give information about the server,
   about further access to the target resource, or about related
   resources.

   Although each response header field has a defined meaning, in
   general, the precise semantics might be further refined by the
   semantics of the request method and/or response status code.

7.1.  Control Data

   Response header fields can supply control data that supplements the
   status code, directs caching, or instructs the client where to go
   next.

   +-------------------+--------------------------+
   | Header Field Name | Defined in...            |
   +-------------------+--------------------------+
   | Age               | Section 5.1 of [RFC7234] |
   | Cache-Control     | Section 5.2 of [RFC7234] |
   | Expires           | Section 5.3 of [RFC7234] |
   | Date              | Section 7.1.1.2          |
   | Location          | Section 7.1.2            |
   | Retry-After       | Section 7.1.3            |
   | Vary              | Section 7.1.4            |
   | Warning           | Section 5.5 of [RFC7234] |
   +-------------------+--------------------------+

Top      Up      ToC       Page 65 
7.1.1.  Origination Date

7.1.1.1.  Date/Time Formats

   Prior to 1995, there were three different formats commonly used by
   servers to communicate timestamps.  For compatibility with old
   implementations, all three are defined here.  The preferred format is
   a fixed-length and single-zone subset of the date and time
   specification used by the Internet Message Format [RFC5322].

     HTTP-date    = IMF-fixdate / obs-date

   An example of the preferred format is

     Sun, 06 Nov 1994 08:49:37 GMT    ; IMF-fixdate

   Examples of the two obsolete formats are

     Sunday, 06-Nov-94 08:49:37 GMT   ; obsolete RFC 850 format
     Sun Nov  6 08:49:37 1994         ; ANSI C's asctime() format

   A recipient that parses a timestamp value in an HTTP header field
   MUST accept all three HTTP-date formats.  When a sender generates a
   header field that contains one or more timestamps defined as
   HTTP-date, the sender MUST generate those timestamps in the
   IMF-fixdate format.

   An HTTP-date value represents time as an instance of Coordinated
   Universal Time (UTC).  The first two formats indicate UTC by the
   three-letter abbreviation for Greenwich Mean Time, "GMT", a
   predecessor of the UTC name; values in the asctime format are assumed
   to be in UTC.  A sender that generates HTTP-date values from a local
   clock ought to use NTP ([RFC5905]) or some similar protocol to
   synchronize its clock to UTC.

   Preferred format:

     IMF-fixdate  = day-name "," SP date1 SP time-of-day SP GMT
     ; fixed length/zone/capitalization subset of the format
     ; see Section 3.3 of [RFC5322]

     day-name     = %x4D.6F.6E ; "Mon", case-sensitive
                  / %x54.75.65 ; "Tue", case-sensitive
                  / %x57.65.64 ; "Wed", case-sensitive
                  / %x54.68.75 ; "Thu", case-sensitive
                  / %x46.72.69 ; "Fri", case-sensitive
                  / %x53.61.74 ; "Sat", case-sensitive
                  / %x53.75.6E ; "Sun", case-sensitive

Top      Up      ToC       Page 66 
     date1        = day SP month SP year
                  ; e.g., 02 Jun 1982

     day          = 2DIGIT
     month        = %x4A.61.6E ; "Jan", case-sensitive
                  / %x46.65.62 ; "Feb", case-sensitive
                  / %x4D.61.72 ; "Mar", case-sensitive
                  / %x41.70.72 ; "Apr", case-sensitive
                  / %x4D.61.79 ; "May", case-sensitive
                  / %x4A.75.6E ; "Jun", case-sensitive
                  / %x4A.75.6C ; "Jul", case-sensitive
                  / %x41.75.67 ; "Aug", case-sensitive
                  / %x53.65.70 ; "Sep", case-sensitive
                  / %x4F.63.74 ; "Oct", case-sensitive
                  / %x4E.6F.76 ; "Nov", case-sensitive
                  / %x44.65.63 ; "Dec", case-sensitive
     year         = 4DIGIT

     GMT          = %x47.4D.54 ; "GMT", case-sensitive

     time-of-day  = hour ":" minute ":" second
                  ; 00:00:00 - 23:59:60 (leap second)

     hour         = 2DIGIT
     minute       = 2DIGIT
     second       = 2DIGIT

   Obsolete formats:

     obs-date     = rfc850-date / asctime-date

     rfc850-date  = day-name-l "," SP date2 SP time-of-day SP GMT
     date2        = day "-" month "-" 2DIGIT
                  ; e.g., 02-Jun-82

     day-name-l   = %x4D.6F.6E.64.61.79    ; "Monday", case-sensitive
            / %x54.75.65.73.64.61.79       ; "Tuesday", case-sensitive
            / %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case-sensitive
            / %x54.68.75.72.73.64.61.79    ; "Thursday", case-sensitive
            / %x46.72.69.64.61.79          ; "Friday", case-sensitive
            / %x53.61.74.75.72.64.61.79    ; "Saturday", case-sensitive
            / %x53.75.6E.64.61.79          ; "Sunday", case-sensitive


     asctime-date = day-name SP date3 SP time-of-day SP year
     date3        = month SP ( 2DIGIT / ( SP 1DIGIT ))
                  ; e.g., Jun  2

Top      Up      ToC       Page 67 
   HTTP-date is case sensitive.  A sender MUST NOT generate additional
   whitespace in an HTTP-date beyond that specifically included as SP in
   the grammar.  The semantics of day-name, day, month, year, and
   time-of-day are the same as those defined for the Internet Message
   Format constructs with the corresponding name ([RFC5322], Section
   3.3).

   Recipients of a timestamp value in rfc850-date format, which uses a
   two-digit year, MUST interpret a timestamp that appears to be more
   than 50 years in the future as representing the most recent year in
   the past that had the same last two digits.

   Recipients of timestamp values are encouraged to be robust in parsing
   timestamps unless otherwise restricted by the field definition.  For
   example, messages are occasionally forwarded over HTTP from a
   non-HTTP source that might generate any of the date and time
   specifications defined by the Internet Message Format.

      Note: HTTP requirements for the date/time stamp format apply only
      to their usage within the protocol stream.  Implementations are
      not required to use these formats for user presentation, request
      logging, etc.

7.1.1.2.  Date

   The "Date" header field represents the date and time at which the
   message was originated, having the same semantics as the Origination
   Date Field (orig-date) defined in Section 3.6.1 of [RFC5322].  The
   field value is an HTTP-date, as defined in Section 7.1.1.1.

     Date = HTTP-date

   An example is

     Date: Tue, 15 Nov 1994 08:12:31 GMT

   When a Date header field is generated, the sender SHOULD generate its
   field value as the best available approximation of the date and time
   of message generation.  In theory, the date ought to represent the
   moment just before the payload is generated.  In practice, the date
   can be generated at any time during message origination.

   An origin server MUST NOT send a Date header field if it does not
   have a clock capable of providing a reasonable approximation of the
   current instance in Coordinated Universal Time.  An origin server MAY
   send a Date header field if the response is in the 1xx
   (Informational) or 5xx (Server Error) class of status codes.  An
   origin server MUST send a Date header field in all other cases.

Top      Up      ToC       Page 68 
   A recipient with a clock that receives a response message without a
   Date header field MUST record the time it was received and append a
   corresponding Date header field to the message's header section if it
   is cached or forwarded downstream.

   A user agent MAY send a Date header field in a request, though
   generally will not do so unless it is believed to convey useful
   information to the server.  For example, custom applications of HTTP
   might convey a Date if the server is expected to adjust its
   interpretation of the user's request based on differences between the
   user agent and server clocks.

7.1.2.  Location

   The "Location" header field is used in some responses to refer to a
   specific resource in relation to the response.  The type of
   relationship is defined by the combination of request method and
   status code semantics.

     Location = URI-reference

   The field value consists of a single URI-reference.  When it has the
   form of a relative reference ([RFC3986], Section 4.2), the final
   value is computed by resolving it against the effective request URI
   ([RFC3986], Section 5).

   For 201 (Created) responses, the Location value refers to the primary
   resource created by the request.  For 3xx (Redirection) responses,
   the Location value refers to the preferred target resource for
   automatically redirecting the request.

   If the Location value provided in a 3xx (Redirection) response does
   not have a fragment component, a user agent MUST process the
   redirection as if the value inherits the fragment component of the
   URI reference used to generate the request target (i.e., the
   redirection inherits the original reference's fragment, if any).

   For example, a GET request generated for the URI reference
   "http://www.example.org/~tim" might result in a 303 (See Other)
   response containing the header field:

     Location: /People.html#tim

   which suggests that the user agent redirect to
   "http://www.example.org/People.html#tim"

Top      Up      ToC       Page 69 
   Likewise, a GET request generated for the URI reference
   "http://www.example.org/index.html#larry" might result in a 301
   (Moved Permanently) response containing the header field:

     Location: http://www.example.net/index.html

   which suggests that the user agent redirect to
   "http://www.example.net/index.html#larry", preserving the original
   fragment identifier.

   There are circumstances in which a fragment identifier in a Location
   value would not be appropriate.  For example, the Location header
   field in a 201 (Created) response is supposed to provide a URI that
   is specific to the created resource.

      Note: Some recipients attempt to recover from Location fields that
      are not valid URI references.  This specification does not mandate
      or define such processing, but does allow it for the sake of
      robustness.

      Note: The Content-Location header field (Section 3.1.4.2) differs
      from Location in that the Content-Location refers to the most
      specific resource corresponding to the enclosed representation.
      It is therefore possible for a response to contain both the
      Location and Content-Location header fields.

7.1.3.  Retry-After

   Servers send the "Retry-After" header field to indicate how long the
   user agent ought to wait before making a follow-up request.  When
   sent with a 503 (Service Unavailable) response, Retry-After indicates
   how long the service is expected to be unavailable to the client.
   When sent with any 3xx (Redirection) response, Retry-After indicates
   the minimum time that the user agent is asked to wait before issuing
   the redirected request.

   The value of this field can be either an HTTP-date or a number of
   seconds to delay after the response is received.

     Retry-After = HTTP-date / delay-seconds

   A delay-seconds value is a non-negative decimal integer, representing
   time in seconds.

     delay-seconds  = 1*DIGIT

Top      Up      ToC       Page 70 
   Two examples of its use are

     Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
     Retry-After: 120

   In the latter example, the delay is 2 minutes.

7.1.4.  Vary

   The "Vary" header field in a response describes what parts of a
   request message, aside from the method, Host header field, and
   request target, might influence the origin server's process for
   selecting and representing this response.  The value consists of
   either a single asterisk ("*") or a list of header field names
   (case-insensitive).

     Vary = "*" / 1#field-name

   A Vary field value of "*" signals that anything about the request
   might play a role in selecting the response representation, possibly
   including elements outside the message syntax (e.g., the client's
   network address).  A recipient will not be able to determine whether
   this response is appropriate for a later request without forwarding
   the request to the origin server.  A proxy MUST NOT generate a Vary
   field with a "*" value.

   A Vary field value consisting of a comma-separated list of names
   indicates that the named request header fields, known as the
   selecting header fields, might have a role in selecting the
   representation.  The potential selecting header fields are not
   limited to those defined by this specification.

   For example, a response that contains

     Vary: accept-encoding, accept-language

   indicates that the origin server might have used the request's
   Accept-Encoding and Accept-Language fields (or lack thereof) as
   determining factors while choosing the content for this response.

   An origin server might send Vary with a list of fields for two
   purposes:

   1.  To inform cache recipients that they MUST NOT use this response
       to satisfy a later request unless the later request has the same
       values for the listed fields as the original request (Section 4.1
       of [RFC7234]).  In other words, Vary expands the cache key
       required to match a new request to the stored cache entry.

Top      Up      ToC       Page 71 
   2.  To inform user agent recipients that this response is subject to
       content negotiation (Section 5.3) and that a different
       representation might be sent in a subsequent request if
       additional parameters are provided in the listed header fields
       (proactive negotiation).

   An origin server SHOULD send a Vary header field when its algorithm
   for selecting a representation varies based on aspects of the request
   message other than the method and request target, unless the variance
   cannot be crossed or the origin server has been deliberately
   configured to prevent cache transparency.  For example, there is no
   need to send the Authorization field name in Vary because reuse
   across users is constrained by the field definition (Section 4.2 of
   [RFC7235]).  Likewise, an origin server might use Cache-Control
   directives (Section 5.2 of [RFC7234]) to supplant Vary if it
   considers the variance less significant than the performance cost of
   Vary's impact on caching.

7.2.  Validator Header Fields

   Validator header fields convey metadata about the selected
   representation (Section 3).  In responses to safe requests, validator
   fields describe the selected representation chosen by the origin
   server while handling the response.  Note that, depending on the
   status code semantics, the selected representation for a given
   response is not necessarily the same as the representation enclosed
   as response payload.

   In a successful response to a state-changing request, validator
   fields describe the new representation that has replaced the prior
   selected representation as a result of processing the request.

   For example, an ETag header field in a 201 (Created) response
   communicates the entity-tag of the newly created resource's
   representation, so that it can be used in later conditional requests
   to prevent the "lost update" problem [RFC7232].

   +-------------------+--------------------------+
   | Header Field Name | Defined in...            |
   +-------------------+--------------------------+
   | ETag              | Section 2.3 of [RFC7232] |
   | Last-Modified     | Section 2.2 of [RFC7232] |
   +-------------------+--------------------------+

Top      Up      ToC       Page 72 
7.3.  Authentication Challenges

   Authentication challenges indicate what mechanisms are available for
   the client to provide authentication credentials in future requests.

   +--------------------+--------------------------+
   | Header Field Name  | Defined in...            |
   +--------------------+--------------------------+
   | WWW-Authenticate   | Section 4.1 of [RFC7235] |
   | Proxy-Authenticate | Section 4.3 of [RFC7235] |
   +--------------------+--------------------------+

7.4.  Response Context

   The remaining response header fields provide more information about
   the target resource for potential use in later requests.

   +-------------------+--------------------------+
   | Header Field Name | Defined in...            |
   +-------------------+--------------------------+
   | Accept-Ranges     | Section 2.3 of [RFC7233] |
   | Allow             | Section 7.4.1            |
   | Server            | Section 7.4.2            |
   +-------------------+--------------------------+

7.4.1.  Allow

   The "Allow" header field lists the set of methods advertised as
   supported by the target resource.  The purpose of this field is
   strictly to inform the recipient of valid request methods associated
   with the resource.

     Allow = #method

   Example of use:

     Allow: GET, HEAD, PUT

   The actual set of allowed methods is defined by the origin server at
   the time of each request.  An origin server MUST generate an Allow
   field in a 405 (Method Not Allowed) response and MAY do so in any
   other response.  An empty Allow field value indicates that the
   resource allows no methods, which might occur in a 405 response if
   the resource has been temporarily disabled by configuration.

   A proxy MUST NOT modify the Allow header field -- it does not need to
   understand all of the indicated methods in order to handle them
   according to the generic message handling rules.

Top      Up      ToC       Page 73 
7.4.2.  Server

   The "Server" header field contains information about the software
   used by the origin server to handle the request, which is often used
   by clients to help identify the scope of reported interoperability
   problems, to work around or tailor requests to avoid particular
   server limitations, and for analytics regarding server or operating
   system use.  An origin server MAY generate a Server field in its
   responses.

     Server = product *( RWS ( product / comment ) )

   The Server field-value consists of one or more product identifiers,
   each followed by zero or more comments (Section 3.2 of [RFC7230]),
   which together identify the origin server software and its
   significant subproducts.  By convention, the product identifiers are
   listed in decreasing order of their significance for identifying the
   origin server software.  Each product identifier consists of a name
   and optional version, as defined in Section 5.5.3.

   Example:

     Server: CERN/3.0 libwww/2.17

   An origin server SHOULD NOT generate a Server field containing
   needlessly fine-grained detail and SHOULD limit the addition of
   subproducts by third parties.  Overly long and detailed Server field
   values increase response latency and potentially reveal internal
   implementation details that might make it (slightly) easier for
   attackers to find and exploit known security holes.



(page 73 continued on part 4)

Next RFC Part