| "503"   ; Service Unavailable
                      | extension-code

       extension-code = 3DIGIT

       Reason-Phrase  = *<TEXT, excluding CR, LF>

   HTTP status codes are extensible, but the above codes are the only
   ones generally recognized in current practice. HTTP applications are
   not required to understand the meaning of all registered status




 
RFC 1945                        HTTP/1.0                        May 1996


   codes, though such understanding is obviously desirable. However,
   applications must understand the class of any status code, as
   indicated by the first digit, and treat any unrecognized response as
   being equivalent to the x00 status code of that class, with the
   exception that an unrecognized response must not be cached. For
   example, if an unrecognized status code of 431 is received by the
   client, it can safely assume that there was something wrong with its
   request and treat the response as if it had received a 400 status
   code. In such cases, user agents should present to the user the
   entity returned with the response, since that entity is likely to
   include human-readable information which will explain the unusual
   status.

6.2  Response Header Fields

   The response header fields allow the server to pass additional
   information about the response which cannot be placed in the Status-
   Line. These header fields give information about the server and about
   further access to the resource identified by the Request-URI.

       Response-Header = Location                ; Section 10.11
                       | Server                  ; Section 10.14
                       | WWW-Authenticate        ; Section 10.16

   Response-Header field names can be extended reliably only in
   combination with a change in the protocol version. However, new or
   experimental header fields may be given the semantics of response
   header fields if all parties in the communication recognize them to
    be response header fields. Unrecognized header fields are treated as
   Entity-Header fields.

7.  Entity

   Full-Request and Full-Response messages may transfer an entity within
   some requests and responses. An entity consists of Entity-Header
   fields and (usually) an Entity-Body. In this section, both sender and
   recipient refer to either the client or the server, depending on who
   sends and who receives the entity.














 
RFC 1945                        HTTP/1.0                        May 1996


7.1  Entity Header Fields

   Entity-Header fields define optional metainformation about the
   Entity-Body or, if no body is present, about the resource identified
   by the request.

       Entity-Header  = Allow                    ; Section 10.1
                      | Content-Encoding         ; Section 10.3
                      | Content-Length           ; Section 10.4
                      | Content-Type             ; Section 10.5
                      | Expires                  ; Section 10.7
                      | Last-Modified            ; Section 10.10
                      | extension-header

       extension-header = HTTP-header

   The extension-header mechanism allows additional Entity-Header fields
   to be defined without changing the protocol, but these fields cannot
   be assumed to be recognizable by the recipient. Unrecognized header
   fields should be ignored by the recipient and forwarded by proxies.

7.2  Entity Body

   The entity body (if any) sent with an HTTP request or response is in
   a format and encoding defined by the Entity-Header fields.