Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 2068

Hypertext Transfer Protocol -- HTTP/1.1

Pages: 162
Obsoleted by:  2616
Part 5 of 6 – Pages 110 to 139
First   Prev   Next

ToP   noToC   RFC2068 - Page 110   prevText
14.12 Content-Encoding

   The Content-Encoding entity-header field is used as a modifier to the
   media-type. When present, its value indicates what additional content
   codings have been applied to the entity-body, and thus what decoding
   mechanisms MUST be applied in order to obtain the media-type
   referenced by the Content-Type header field. Content-Encoding is
   primarily used to allow a document to be compressed without losing
   the identity of its underlying media type.

          Content-Encoding  = "Content-Encoding" ":" 1#content-coding

   Content codings are defined in section 3.5. An example of its use is

          Content-Encoding: gzip

   The Content-Encoding is a characteristic of the entity identified by
   the Request-URI. Typically, the entity-body is stored with this
   encoding and is only decoded before rendering or analogous usage.

   If multiple encodings have been applied to an entity, the content
   codings MUST be listed in the order in which they were applied.

   Additional information about the encoding parameters MAY be provided
   by other entity-header fields not defined by this specification.

14.13 Content-Language

   The Content-Language entity-header field describes the natural
   language(s) of the intended audience for the enclosed entity. Note
   that this may not be equivalent to all the languages used within the

          Content-Language  = "Content-Language" ":" 1#language-tag

   Language tags are defined in section 3.10. The primary purpose of
   Content-Language is to allow a user to identify and differentiate
   entities according to the user's own preferred language. Thus, if the
   body content is intended only for a Danish-literate audience, the
   appropriate field is

          Content-Language: da

   If no Content-Language is specified, the default is that the content
   is intended for all language audiences. This may mean that the sender
ToP   noToC   RFC2068 - Page 111
   does not consider it to be specific to any natural language, or that
   the sender does not know for which language it is intended.

   Multiple languages MAY be listed for content that is intended for
   multiple audiences. For example, a rendition of the "Treaty of
   Waitangi," presented simultaneously in the original Maori and English
   versions, would call for

          Content-Language: mi, en

   However, just because multiple languages are present within an entity
   does not mean that it is intended for multiple linguistic audiences.
   An example would be a beginner's language primer, such as "A First
   Lesson in Latin," which is clearly intended to be used by an
   English-literate audience. In this case, the Content-Language should
   only include "en".

   Content-Language may be applied to any media type -- it is not
   limited to textual documents.

14.14 Content-Length

   The Content-Length entity-header field indicates the size of the
   message-body, in decimal number of octets, sent to the recipient or,
   in the case of the HEAD method, the size of the entity-body that
   would have been sent had the request been a GET.

          Content-Length    = "Content-Length" ":" 1*DIGIT

   An example is

          Content-Length: 3495

   Applications SHOULD use this field to indicate the size of the
   message-body to be transferred, regardless of the media type of the
   entity. It must be possible for the recipient to reliably determine
   the end of HTTP/1.1 requests containing an entity-body, e.g., because
   the request has a valid Content-Length field, uses Transfer-Encoding:
   chunked or a multipart body.

   Any Content-Length greater than or equal to zero is a valid value.
   Section 4.4 describes how to determine the length of a message-body
   if a Content-Length is not given.
ToP   noToC   RFC2068 - Page 112
     Note: The meaning of this field is significantly different from the
     corresponding definition in MIME, where it is an optional field
     used within the "message/external-body" content-type. In HTTP, it
     SHOULD be sent whenever the message's length can be determined
     prior to being transferred.

14.15 Content-Location

   The Content-Location entity-header field may be used to supply the
   resource location for the entity enclosed in the message. In the case
   where a resource has multiple entities associated with it, and those
   entities actually have separate locations by which they might be
   individually accessed, the server should provide a Content-Location
   for the particular variant which is returned. In addition, a server
   SHOULD provide a Content-Location for the resource corresponding to
   the response entity.

          Content-Location = "Content-Location" ":"
                            ( absoluteURI | relativeURI )

   If no Content-Base header field is present, the value of Content-
   Location also defines the base URL for the entity (see section

   The Content-Location value is not a replacement for the original
   requested URI; it is only a statement of the location of the resource
   corresponding to this particular entity at the time of the request.
   Future requests MAY use the Content-Location URI if the desire is to
   identify the source of that particular entity.

   A cache cannot assume that an entity with a Content-Location
   different from the URI used to retrieve it can be used to respond to
   later requests on that Content-Location URI. However, the Content-
   Location can be used to differentiate between multiple entities
   retrieved from a single requested resource, as described in section

   If the Content-Location is a relative URI, the URI is interpreted
   relative to any Content-Base URI provided in the response. If no
   Content-Base is provided, the relative URI is interpreted relative to
   the Request-URI.
ToP   noToC   RFC2068 - Page 113
14.16 Content-MD5

   The Content-MD5 entity-header field, as defined in RFC 1864 [23], is
   an MD5 digest of the entity-body for the purpose of providing an
   end-to-end message integrity check (MIC) of the entity-body. (Note: a
   MIC is good for detecting accidental modification of the entity-body
   in transit, but is not proof against malicious attacks.)

           Content-MD5   = "Content-MD5" ":" md5-digest

           md5-digest   = <base64 of 128 bit MD5 digest as per RFC 1864>

   The Content-MD5 header field may be generated by an origin server to
   function as an integrity check of the entity-body. Only origin
   servers may generate the Content-MD5 header field; proxies and
   gateways MUST NOT generate it, as this would defeat its value as an
   end-to-end integrity check. Any recipient of the entity-body,
   including gateways and proxies, MAY check that the digest value in
   this header field matches that of the entity-body as received.

   The MD5 digest is computed based on the content of the entity-body,
   including any Content-Encoding that has been applied, but not
   including any Transfer-Encoding that may have been applied to the
   message-body. If the message is received with a Transfer-Encoding,
   that encoding must be removed prior to checking the Content-MD5 value
   against the received entity.

   This has the result that the digest is computed on the octets of the
   entity-body exactly as, and in the order that, they would be sent if
   no Transfer-Encoding were being applied.

   HTTP extends RFC 1864 to permit the digest to be computed for MIME
   composite media-types (e.g., multipart/* and message/rfc822), but
   this does not change how the digest is computed as defined in the
   preceding paragraph.

     Note: There are several consequences of this. The entity-body for
     composite types may contain many body-parts, each with its own MIME
     and HTTP headers (including Content-MD5, Content-Transfer-Encoding,
     and Content-Encoding headers). If a body-part has a Content-
     Transfer-Encoding or Content-Encoding header, it is assumed that
     the content of the body-part has had the encoding applied, and the
     body-part is included in the Content-MD5 digest as is -- i.e.,
     after the application. The Transfer-Encoding header field is not
     allowed within body-parts.

     Note: while the definition of Content-MD5 is exactly the same for
     HTTP as in RFC 1864 for MIME entity-bodies, there are several ways
ToP   noToC   RFC2068 - Page 114
     in which the application of Content-MD5 to HTTP entity-bodies
     differs from its application to MIME entity-bodies. One is that
     HTTP, unlike MIME, does not use Content-Transfer-Encoding, and does
     use Transfer-Encoding and Content-Encoding. Another is that HTTP
     more frequently uses binary content types than MIME, so it is worth
     noting that, in such cases, the byte order used to compute the
     digest is the transmission byte order defined for the type. Lastly,
     HTTP allows transmission of text types with any of several line
     break conventions and not just the canonical form using CRLF.
     Conversion of all line breaks to CRLF should not be done before
     computing or checking the digest: the line break convention used in
     the text actually transmitted should be left unaltered when
     computing the digest.

14.17 Content-Range

   The Content-Range entity-header is sent with a partial entity-body to
   specify where in the full entity-body the partial body should be
   inserted. It also indicates the total size of the full entity-body.
   When a server returns a partial response to a client, it must
   describe both the extent of the range covered by the response, and
   the length of the entire entity-body.

          Content-Range = "Content-Range" ":" content-range-spec

          content-range-spec      = byte-content-range-spec

          byte-content-range-spec = bytes-unit SP first-byte-pos "-"
                                    last-byte-pos "/" entity-length

          entity-length           = 1*DIGIT

   Unlike byte-ranges-specifier values, a byte-content-range-spec may
   only specify one range, and must contain absolute byte positions for
   both the first and last byte of the range.

   A byte-content-range-spec whose last-byte-pos value is less than its
   first-byte-pos value, or whose entity-length value is less than or
   equal to its last-byte-pos value, is invalid. The recipient of an
   invalid byte-content-range-spec MUST ignore it and any content
   transferred along with it.
ToP   noToC   RFC2068 - Page 115
   Examples of byte-content-range-spec values, assuming that the entity
   contains a total of 1234 bytes:

     o  The first 500 bytes:

          bytes 0-499/1234

     o  The second 500 bytes:

          bytes 500-999/1234

     o  All except for the first 500 bytes:

          bytes 500-1233/1234

     o  The last 500 bytes:

          bytes 734-1233/1234

   When an HTTP message includes the content of a single range (for
   example, a response to a request for a single range, or to a request
   for a set of ranges that overlap without any holes), this content is
   transmitted with a Content-Range header, and a Content-Length header
   showing the number of bytes actually transferred. For example,

          HTTP/1.1 206 Partial content
          Date: Wed, 15 Nov 1995 06:25:24 GMT
          Last-modified: Wed, 15 Nov 1995 04:58:08 GMT
          Content-Range: bytes 21010-47021/47022
          Content-Length: 26012
          Content-Type: image/gif

   When an HTTP message includes the content of multiple ranges (for
   example, a response to a request for multiple non-overlapping
   ranges), these are transmitted as a multipart MIME message. The
   multipart MIME content-type used for this purpose is defined in this
   specification to be "multipart/byteranges". See appendix 19.2 for its

   A client that cannot decode a MIME multipart/byteranges message
   should not ask for multiple byte-ranges in a single request.

   When a client requests multiple byte-ranges in one request, the
   server SHOULD return them in the order that they appeared in the

   If the server ignores a byte-range-spec because it is invalid, the
   server should treat the request as if the invalid Range header field
ToP   noToC   RFC2068 - Page 116
   did not exist. (Normally, this means return a 200 response containing
   the full entity). The reason is that the only time a client will make
   such an invalid request is when the entity is smaller than the entity
   retrieved by a prior request.

14.18 Content-Type

   The Content-Type entity-header field indicates the media type of the
   entity-body sent to the recipient or, in the case of the HEAD method,
   the media type that would have been sent had the request been a GET.

          Content-Type   = "Content-Type" ":" media-type
   Media types are defined in section 3.7. An example of the field is

          Content-Type: text/html; charset=ISO-8859-4

   Further discussion of methods for identifying the media type of an
   entity is provided in section 7.2.1.

14.19 Date

   The Date general-header field represents the date and time at which
   the message was originated, having the same semantics as orig-date in
   RFC 822. The field value is an HTTP-date, as described in section

          Date  = "Date" ":" HTTP-date

   An example is

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

   If a message is received via direct connection with the user agent
   (in the case of requests) or the origin server (in the case of
   responses), then the date can be assumed to be the current date at
   the receiving end. However, since the date--as it is believed by the
   origin--is important for evaluating cached responses, origin servers
   MUST include a Date header field in all responses. Clients SHOULD
   only send a Date header field in messages that include an entity-
   body, as in the case of the PUT and POST requests, and even then it
   is optional. A received message which does not have a Date header
   field SHOULD be assigned one by the recipient if the message will be
   cached by that recipient or gatewayed via a protocol which requires a
ToP   noToC   RFC2068 - Page 117
   In theory, the date SHOULD represent the moment just before the
   entity is generated. In practice, the date can be generated at any
   time during the message origination without affecting its semantic

   The format of the Date is an absolute date and time as defined by
   HTTP-date in section 3.3; it MUST be sent in RFC1123 [8]-date format.

14.20 ETag

   The ETag entity-header field defines the entity tag for the
   associated entity. The headers used with entity tags are described in
   sections 14.20, 14.25, 14.26 and 14.43. The entity tag may be used
   for comparison with other entities from the same resource (see
   section 13.3.2).

         ETag = "ETag" ":" entity-tag


         ETag: "xyzzy"
         ETag: W/"xyzzy"
         ETag: ""

14.21 Expires

   The Expires entity-header field gives the date/time after which the
   response should be considered stale. A stale cache entry may not
   normally be returned by a cache (either a proxy cache or an user
   agent cache) unless it is first validated with the origin server (or
   with an intermediate cache that has a fresh copy of the entity). See
   section 13.2 for further discussion of the expiration model.

   The presence of an Expires field does not imply that the original
   resource will change or cease to exist at, before, or after that

   The format is an absolute date and time as defined by HTTP-date in
   section 3.3; it MUST be in RFC1123-date format:

         Expires = "Expires" ":" HTTP-date
ToP   noToC   RFC2068 - Page 118
   An example of its use is

         Expires: Thu, 01 Dec 1994 16:00:00 GMT

     Note: if a response includes a Cache-Control field with the max-age
     directive, that directive overrides the Expires field.

   HTTP/1.1 clients and caches MUST treat other invalid date formats,
   especially including the value "0", as in the past (i.e., "already

   To mark a response as "already expired," an origin server should use
   an Expires date that is equal to the Date header value. (See the
   rules for expiration calculations in section 13.2.4.)

   To mark a response as "never expires," an origin server should use an
   Expires date approximately one year from the time the response is
   sent.  HTTP/1.1 servers should not send Expires dates more than one
   year in the future.

   The presence of an Expires header field with a date value of some
   time in the future on an response that otherwise would by default be
   non-cacheable indicates that the response is cachable, unless
   indicated otherwise by a Cache-Control header field (section 14.9).

14.22 From

   The From request-header field, if given, SHOULD contain an Internet
   e-mail address for the human user who controls the requesting user
   agent.  The address SHOULD be machine-usable, as defined by mailbox
   in RFC 822 (as updated by RFC 1123 ):

          From   = "From" ":" mailbox

   An example is:


   This header field MAY be used for logging purposes and as a means for
   identifying the source of invalid or unwanted requests. It SHOULD NOT
   be used as an insecure form of access protection. The interpretation
   of this field is that the request is being performed on behalf of the
   person given, who accepts responsibility for the method performed. In
   particular, robot agents SHOULD include this header so that the
   person responsible for running the robot can be contacted if problems
   occur on the receiving end.
ToP   noToC   RFC2068 - Page 119
   The Internet e-mail address in this field MAY be separate from the
   Internet host which issued the request. For example, when a request
   is passed through a proxy the original issuer's address SHOULD be

     Note: The client SHOULD not send the From header field without the
     user's approval, as it may conflict with the user's privacy
     interests or their site's security policy. It is strongly
     recommended that the user be able to disable, enable, and modify
     the value of this field at any time prior to a request.

14.23 Host

   The Host request-header field specifies the Internet host and port
   number of the resource being requested, as obtained from the original
   URL given by the user or referring resource (generally an HTTP URL,
   as described in section 3.2.2). The Host field value MUST represent
   the network location of the origin server or gateway given by the
   original URL. This allows the origin server or gateway to
   differentiate between internally-ambiguous URLs, such as the root "/"
   URL of a server for multiple host names on a single IP address.

          Host = "Host" ":" host [ ":" port ]    ; Section 3.2.2

   A "host" without any trailing port information implies the default
   port for the service requested (e.g., "80" for an HTTP URL). For
   example, a request on the origin server for
   <> MUST include:

          GET /pub/WWW/ HTTP/1.1

   A client MUST include a Host header field in all HTTP/1.1 request
   messages on the Internet (i.e., on any message corresponding to a
   request for a URL which includes an Internet host address for the
   service being requested). If the Host field is not already present,
   an HTTP/1.1 proxy MUST add a Host field to the request message prior
   to forwarding it on the Internet. All Internet-based HTTP/1.1 servers
   MUST respond with a 400 status code to any HTTP/1.1 request message
   which lacks a Host header field.

   See sections 5.2 and 19.5.1 for other requirements relating to Host.

14.24 If-Modified-Since

   The If-Modified-Since request-header field is used with the GET
   method to make it conditional: if the requested variant has not been
   modified since the time specified in this field, an entity will not
ToP   noToC   RFC2068 - Page 120
   be returned from the server; instead, a 304 (not modified) response
   will be returned without any message-body.

          If-Modified-Since = "If-Modified-Since" ":" HTTP-date

   An example of the field is:

          If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT

   A GET method with an If-Modified-Since header and no Range header
   requests that the identified entity be transferred only if it has
   been modified since the date given by the If-Modified-Since header.
   The algorithm for determining this includes the following cases:

   a)If the request would normally result in anything other than a 200
     (OK) status, or if the passed If-Modified-Since date is invalid, the
     response is exactly the same as for a normal GET. A date which is
     later than the server's current time is invalid.

   b)If the variant has been modified since the If-Modified-Since date,
     the response is exactly the same as for a normal GET.

   c)If the variant has not been modified since a valid If-Modified-Since
     date, the server MUST return a 304 (Not Modified) response.

   The purpose of this feature is to allow efficient updates of cached
   information with a minimum amount of transaction overhead.

     Note that the Range request-header field modifies the meaning of
     If-Modified-Since; see section 14.36 for full details.

     Note that If-Modified-Since times are interpreted by the server,
     whose clock may not be synchronized with the client.

   Note that if a client uses an arbitrary date in the If-Modified-Since
   header instead of a date taken from the Last-Modified header for the
   same request, the client should be aware of the fact that this date
   is interpreted in the server's understanding of time. The client
   should consider unsynchronized clocks and rounding problems due to
   the different encodings of time between the client and server. This
   includes the possibility of race conditions if the document has
   changed between the time it was first requested and the If-Modified-
   Since date of a subsequent request, and the possibility of clock-
   skew-related problems if the If-Modified-Since date is derived from
   the client's clock without correction to the server's clock.
   Corrections for different time bases between client and server are at
   best approximate due to network latency.
ToP   noToC   RFC2068 - Page 121
14.25 If-Match

   The If-Match request-header field is used with a method to make it
   conditional. A client that has one or more entities previously
   obtained from the resource can verify that one of those entities is
   current by including a list of their associated entity tags in the
   If-Match header field. The purpose of this feature is to allow
   efficient updates of cached information with a minimum amount of
   transaction overhead. It is also used, on updating requests, to
   prevent inadvertent modification of the wrong version of a resource.
   As a special case, the value "*" matches any current entity of the

          If-Match = "If-Match" ":" ( "*" | 1#entity-tag )

   If any of the entity tags match the entity tag of the entity that
   would have been returned in the response to a similar GET request
   (without the If-Match header) on that resource, or if "*" is given
   and any current entity exists for that resource, then the server MAY
   perform the requested method as if the If-Match header field did not

   A server MUST use the strong comparison function (see section 3.11)
   to compare the entity tags in If-Match.

   If none of the entity tags match, or if "*" is given and no current
   entity exists, the server MUST NOT perform the requested method, and
   MUST return a 412 (Precondition Failed) response. This behavior is
   most useful when the client wants to prevent an updating method, such
   as PUT, from modifying a resource that has changed since the client
   last retrieved it.

   If the request would, without the If-Match header field, result in
   anything other than a 2xx status, then the If-Match header MUST be

   The meaning of "If-Match: *" is that the method SHOULD be performed
   if the representation selected by the origin server (or by a cache,
   possibly using the Vary mechanism, see section 14.43) exists, and
   MUST NOT be performed if the representation does not exist.
ToP   noToC   RFC2068 - Page 122
   A request intended to update a resource (e.g., a PUT) MAY include an
   If-Match header field to signal that the request method MUST NOT be
   applied if the entity corresponding to the If-Match value (a single
   entity tag) is no longer a representation of that resource.  This
   allows the user to indicate that they do not wish the request to be
   successful if the resource has been changed without their knowledge.

          If-Match: "xyzzy"
          If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
          If-Match: *

14.26 If-None-Match

   The If-None-Match request-header field is used with a method to make
   it conditional. A client that has one or more entities previously
   obtained from the resource can verify that none of those entities is
   current by including a list of their associated entity tags in the
   If-None-Match header field. The purpose of this feature is to allow
   efficient updates of cached information with a minimum amount of
   transaction overhead. It is also used, on updating requests, to
   prevent inadvertent modification of a resource which was not known to

   As a special case, the value "*" matches any current entity of the

          If-None-Match = "If-None-Match" ":" ( "*" | 1#entity-tag )

   If any of the entity tags match the entity tag of the entity that
   would have been returned in the response to a similar GET request
   (without the If-None-Match header) on that resource, or if "*" is
   given and any current entity exists for that resource, then the
   server MUST NOT perform the requested method. Instead, if the request
   method was GET or HEAD, the server SHOULD respond with a 304 (Not
   Modified) response, including the cache-related entity-header fields
   (particularly ETag) of one of the entities that matched. For all
   other request methods, the server MUST respond with a status of 412
   (Precondition Failed).

   See section 13.3.3 for rules on how to determine if two entity tags
   match. The weak comparison function can only be used with GET or HEAD

   If none of the entity tags match, or if "*" is given and no current
   entity exists, then the server MAY perform the requested method as if
   the If-None-Match header field did not exist.
ToP   noToC   RFC2068 - Page 123
   If the request would, without the If-None-Match header field, result
   in anything other than a 2xx status, then the If-None-Match header
   MUST be ignored.

   The meaning of "If-None-Match: *" is that the method MUST NOT be
   performed if the representation selected by the origin server (or by
   a cache, possibly using the Vary mechanism, see section 14.43)
   exists, and SHOULD be performed if the representation does not exist.
   This feature may be useful in preventing races between PUT


          If-None-Match: "xyzzy"
          If-None-Match: W/"xyzzy"
          If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
          If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz"
          If-None-Match: *

14.27 If-Range

   If a client has a partial copy of an entity in its cache, and wishes
   to have an up-to-date copy of the entire entity in its cache, it
   could use the Range request-header with a conditional GET (using
   either or both of If-Unmodified-Since and If-Match.) However, if the
   condition fails because the entity has been modified, the client
   would then have to make a second request to obtain the entire current

   The If-Range header allows a client to "short-circuit" the second
   request. Informally, its meaning is `if the entity is unchanged, send
   me the part(s) that I am missing; otherwise, send me the entire new

           If-Range = "If-Range" ":" ( entity-tag | HTTP-date )

   If the client has no entity tag for an entity, but does have a Last-
   Modified date, it may use that date in a If-Range header. (The server
   can distinguish between a valid HTTP-date and any form of entity-tag
   by examining no more than two characters.) The If-Range header should
   only be used together with a Range header, and must be ignored if the
   request does not include a Range header, or if the server does not
   support the sub-range operation.
ToP   noToC   RFC2068 - Page 124
   If the entity tag given in the If-Range header matches the current
   entity tag for the entity, then the server should provide the
   specified sub-range of the entity using a 206 (Partial content)
   response. If the entity tag does not match, then the server should
   return the entire entity using a 200 (OK) response.

14.28 If-Unmodified-Since

   The If-Unmodified-Since request-header field is used with a method to
   make it conditional. If the requested resource has not been modified
   since the time specified in this field, the server should perform the
   requested operation as if the If-Unmodified-Since header were not

   If the requested variant has been modified since the specified time,
   the server MUST NOT perform the requested operation, and MUST return
   a 412 (Precondition Failed).

         If-Unmodified-Since = "If-Unmodified-Since" ":" HTTP-date

   An example of the field is:

          If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT

   If the request normally (i.e., without the If-Unmodified-Since
   header) would result in anything other than a 2xx status, the If-
   Unmodified-Since header should be ignored.

   If the specified date is invalid, the header is ignored.

14.29 Last-Modified

   The Last-Modified entity-header field indicates the date and time at
   which the origin server believes the variant was last modified.

          Last-Modified  = "Last-Modified" ":" HTTP-date

   An example of its use is

          Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT

   The exact meaning of this header field depends on the implementation
   of the origin server and the nature of the original resource. For
   files, it may be just the file system last-modified time. For
   entities with dynamically included parts, it may be the most recent
   of the set of last-modify times for its component parts. For database
   gateways, it may be the last-update time stamp of the record. For
   virtual objects, it may be the last time the internal state changed.
ToP   noToC   RFC2068 - Page 125
   An origin server MUST NOT send a Last-Modified date which is later
   than the server's time of message origination. In such cases, where
   the resource's last modification would indicate some time in the
   future, the server MUST replace that date with the message
   origination date.

   An origin server should obtain the Last-Modified value of the entity
   as close as possible to the time that it generates the Date value of
   its response. This allows a recipient to make an accurate assessment
   of the entity's modification time, especially if the entity changes
   near the time that the response is generated.

   HTTP/1.1 servers SHOULD send Last-Modified whenever feasible.

14.30 Location

   The Location response-header field is used to redirect the recipient
   to a location other than the Request-URI for completion of the
   request or identification of a new resource. For 201 (Created)
   responses, the Location is that of the new resource which was created
   by the request.  For 3xx responses, the location SHOULD indicate the
   server's preferred URL for automatic redirection to the resource. The
   field value consists of a single absolute URL.

          Location       = "Location" ":" absoluteURI

   An example is


     Note: The Content-Location header field (section 14.15) differs
     from Location in that the Content-Location identifies the original
     location of the entity enclosed in the request. It is therefore
     possible for a response to contain header fields for both Location
     and Content-Location. Also see section 13.10 for cache requirements
     of some methods.

14.31 Max-Forwards

   The Max-Forwards request-header field may be used with the TRACE
   method (section 14.31) to limit the number of proxies or gateways
   that can forward the request to the next inbound server. This can be
   useful when the client is attempting to trace a request chain which
   appears to be failing or looping in mid-chain.

          Max-Forwards   = "Max-Forwards" ":" 1*DIGIT
ToP   noToC   RFC2068 - Page 126
   The Max-Forwards value is a decimal integer indicating the remaining
   number of times this request message may be forwarded.

   Each proxy or gateway recipient of a TRACE request containing a Max-
   Forwards header field SHOULD check and update its value prior to
   forwarding the request. If the received value is zero (0), the
   recipient SHOULD NOT forward the request; instead, it SHOULD respond
   as the final recipient with a 200 (OK) response containing the
   received request message as the response entity-body (as described in
   section 9.8). If the received Max-Forwards value is greater than
   zero, then the forwarded message SHOULD contain an updated Max-
   Forwards field with a value decremented by one (1).

   The Max-Forwards header field SHOULD be ignored for all other methods
   defined by this specification and for any extension methods for which
   it is not explicitly referred to as part of that method definition.

14.32 Pragma

   The Pragma general-header field is used to include implementation-
   specific directives that may apply to any recipient along the
   request/response chain. All pragma directives specify optional
   behavior from the viewpoint of the protocol; however, some systems
   MAY require that behavior be consistent with the directives.

          Pragma            = "Pragma" ":" 1#pragma-directive

          pragma-directive  = "no-cache" | extension-pragma
          extension-pragma  = token [ "=" ( token | quoted-string ) ]

   When the no-cache directive is present in a request message, an
   application SHOULD forward the request toward the origin server even
   if it has a cached copy of what is being requested. This pragma
   directive has the same semantics as the no-cache cache-directive (see
   section 14.9) and is defined here for backwards compatibility with
   HTTP/1.0.  Clients SHOULD include both header fields when a no-cache
   request is sent to a server not known to be HTTP/1.1 compliant.

   Pragma directives MUST be passed through by a proxy or gateway
   application, regardless of their significance to that application,
   since the directives may be applicable to all recipients along the
   request/response chain. It is not possible to specify a pragma for a
   specific recipient; however, any pragma directive not relevant to a
   recipient SHOULD be ignored by that recipient.
ToP   noToC   RFC2068 - Page 127
   HTTP/1.1 clients SHOULD NOT send the Pragma request-header. HTTP/1.1
   caches SHOULD treat "Pragma: no-cache" as if the client had sent
   "Cache-Control: no-cache". No new Pragma directives will be defined
   in HTTP.

14.33 Proxy-Authenticate

   The Proxy-Authenticate response-header field MUST be included as part
   of a 407 (Proxy Authentication Required) response. The field value
   consists of a challenge that indicates the authentication scheme and
   parameters applicable to the proxy for this Request-URI.

          Proxy-Authenticate  = "Proxy-Authenticate" ":" challenge

   The HTTP access authentication process is described in section 11.
   Unlike WWW-Authenticate, the Proxy-Authenticate header field applies
   only to the current connection and SHOULD NOT be passed on to
   downstream clients. However, an intermediate proxy may need to obtain
   its own credentials by requesting them from the downstream client,
   which in some circumstances will appear as if the proxy is forwarding
   the Proxy-Authenticate header field.

14.34 Proxy-Authorization

   The Proxy-Authorization request-header field allows the client to
   identify itself (or its user) to a proxy which requires
   authentication.  The Proxy-Authorization field value consists of
   credentials containing the authentication information of the user
   agent for the proxy and/or realm of the resource being requested.

       Proxy-Authorization     = "Proxy-Authorization" ":" credentials

   The HTTP access authentication process is described in section 11.
   Unlike Authorization, the Proxy-Authorization header field applies
   only to the next outbound proxy that demanded authentication using
   the Proxy-Authenticate field. When multiple proxies are used in a
   chain, the Proxy-Authorization header field is consumed by the first
   outbound proxy that was expecting to receive credentials. A proxy MAY
   relay the credentials from the client request to the next proxy if
   that is the mechanism by which the proxies cooperatively authenticate
   a given request.

14.35 Public

   The Public response-header field lists the set of methods supported
   by the server. The purpose of this field is strictly to inform the
   recipient of the capabilities of the server regarding unusual
   methods.  The methods listed may or may not be applicable to the
ToP   noToC   RFC2068 - Page 128
   Request-URI; the Allow header field (section 14.7) MAY be used to
   indicate methods allowed for a particular URI.

          Public         = "Public" ":" 1#method

   Example of use:

          Public: OPTIONS, MGET, MHEAD, GET, HEAD

   This header field applies only to the server directly connected to
   the client (i.e., the nearest neighbor in a chain of connections). If
   the response passes through a proxy, the proxy MUST either remove the
   Public header field or replace it with one applicable to its own

14.36 Range

14.36.1 Byte Ranges

   Since all HTTP entities are represented in HTTP messages as sequences
   of bytes, the concept of a byte range is meaningful for any HTTP
   entity.  (However, not all clients and servers need to support byte-
   range operations.)

   Byte range specifications in HTTP apply to the sequence of bytes in
   the entity-body (not necessarily the same as the message-body).

   A byte range operation may specify a single range of bytes, or a set
   of ranges within a single entity.

       ranges-specifier = byte-ranges-specifier

       byte-ranges-specifier = bytes-unit "=" byte-range-set

       byte-range-set  = 1#( byte-range-spec | suffix-byte-range-spec )

       byte-range-spec = first-byte-pos "-" [last-byte-pos]

       first-byte-pos  = 1*DIGIT

       last-byte-pos   = 1*DIGIT

   The first-byte-pos value in a byte-range-spec gives the byte-offset
   of the first byte in a range. The last-byte-pos value gives the
   byte-offset of the last byte in the range; that is, the byte
   positions specified are inclusive. Byte offsets start at zero.
ToP   noToC   RFC2068 - Page 129
   If the last-byte-pos value is present, it must be greater than or
   equal to the first-byte-pos in that byte-range-spec, or the byte-
   range-spec is invalid. The recipient of an invalid byte-range-spec
   must ignore it.

   If the last-byte-pos value is absent, or if the value is greater than
   or equal to the current length of the entity-body, last-byte-pos is
   taken to be equal to one less than the current length of the entity-
   body in bytes.

   By its choice of last-byte-pos, a client can limit the number of
   bytes retrieved without knowing the size of the entity.

          suffix-byte-range-spec = "-" suffix-length

          suffix-length = 1*DIGIT

   A suffix-byte-range-spec is used to specify the suffix of the
   entity-body, of a length given by the suffix-length value. (That is,
   this form specifies the last N bytes of an entity-body.) If the
   entity is shorter than the specified suffix-length, the entire
   entity-body is used.

   Examples of byte-ranges-specifier values (assuming an entity-body of
   length 10000):

     o  The first 500 bytes (byte offsets 0-499, inclusive):


     o  The second 500 bytes (byte offsets 500-999, inclusive):


     o  The final 500 bytes (byte offsets 9500-9999, inclusive):


     o  Or


     o  The first and last bytes only (bytes 0 and 9999):

ToP   noToC   RFC2068 - Page 130
     o  Several legal but not canonical specifications of the second
        500 bytes (byte offsets 500-999, inclusive):



14.36.2 Range Retrieval Requests

   HTTP retrieval requests using conditional or unconditional GET
   methods may request one or more sub-ranges of the entity, instead of
   the entire entity, using the Range request header, which applies to
   the entity returned as the result of the request:

         Range = "Range" ":" ranges-specifier

   A server MAY ignore the Range header. However, HTTP/1.1 origin
   servers and intermediate caches SHOULD support byte ranges when
   possible, since Range supports efficient recovery from partially
   failed transfers, and supports efficient partial retrieval of large

   If the server supports the Range header and the specified range or
   ranges are appropriate for the entity:

     o  The presence of a Range header in an unconditional GET modifies
        what is returned if the GET is otherwise successful. In other
        words, the response carries a status code of 206 (Partial
        Content) instead of 200 (OK).

     o  The presence of a Range header in a conditional GET (a request
        using one or both of If-Modified-Since and If-None-Match, or
        one or both of If-Unmodified-Since and If-Match) modifies what
        is returned if the GET is otherwise successful and the condition
        is true. It does not affect the 304 (Not Modified) response
        returned if the conditional is false.

   In some cases, it may be more appropriate to use the If-Range header
   (see section 14.27) in addition to the Range header.

   If a proxy that supports ranges receives a Range request, forwards
   the request to an inbound server, and receives an entire entity in
   reply, it SHOULD only return the requested range to its client. It
   SHOULD store the entire received response in its cache, if that is
   consistent with its cache allocation policies.
ToP   noToC   RFC2068 - Page 131
14.37 Referer

   The Referer[sic] request-header field allows the client to specify,
   for the server's benefit, the address (URI) of the resource from
   which the Request-URI was obtained (the "referrer", although the
   header field is misspelled.) The Referer request-header allows a
   server to generate lists of back-links to resources for interest,
   logging, optimized caching, etc. It also allows obsolete or mistyped
   links to be traced for maintenance. The Referer field MUST NOT be
   sent if the Request-URI was obtained from a source that does not have
   its own URI, such as input from the user keyboard.

        Referer        = "Referer" ":" ( absoluteURI | relativeURI )



   If the field value is a partial URI, it SHOULD be interpreted
   relative to the Request-URI. The URI MUST NOT include a fragment.

     Note: Because the source of a link may be private information or
     may reveal an otherwise private information source, it is strongly
     recommended that the user be able to select whether or not the
     Referer field is sent. For example, a browser client could have a
     toggle switch for browsing openly/anonymously, which would
     respectively enable/disable the sending of Referer and From

14.38 Retry-After

   The Retry-After response-header field can be used with a 503 (Service
   Unavailable) response to indicate how long the service is expected to
   be unavailable to the requesting client. The value of this field can
   be either an HTTP-date or an integer number of seconds (in decimal)
   after the time of the response.

          Retry-After  = "Retry-After" ":" ( HTTP-date | delta-seconds )

   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.
ToP   noToC   RFC2068 - Page 132
14.39 Server

   The Server response-header field contains information about the
   software used by the origin server to handle the request. The field
   can contain multiple product tokens (section 3.8) and comments
   identifying the server and any significant subproducts. The product
   tokens are listed in order of their significance for identifying the

          Server         = "Server" ":" 1*( product | comment )


          Server: CERN/3.0 libwww/2.17

   If the response is being forwarded through a proxy, the proxy
   application MUST NOT modify the Server response-header. Instead, it
   SHOULD include a Via field (as described in section 14.44).

     Note: Revealing the specific software version of the server may
     allow the server machine to become more vulnerable to attacks
     against software that is known to contain security holes. Server
     implementers are encouraged to make this field a configurable

14.40 Transfer-Encoding

   The Transfer-Encoding general-header field indicates what (if any)
   type of transformation has been applied to the message body in order
   to safely transfer it between the sender and the recipient. This
   differs from the Content-Encoding in that the transfer coding is a
   property of the message, not of the entity.

          Transfer-Encoding       = "Transfer-Encoding" ":" 1#transfer-

   Transfer codings are defined in section 3.6. An example is:

          Transfer-Encoding: chunked

   Many older HTTP/1.0 applications do not understand the Transfer-
   Encoding header.

14.41 Upgrade

   The Upgrade general-header allows the client to specify what
   additional communication protocols it supports and would like to use
   if the server finds it appropriate to switch protocols. The server
ToP   noToC   RFC2068 - Page 133
   MUST use the Upgrade header field within a 101 (Switching Protocols)
   response to indicate which protocol(s) are being switched.

          Upgrade        = "Upgrade" ":" 1#product

   For example,

          Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11

   The Upgrade header field is intended to provide a simple mechanism
   for transition from HTTP/1.1 to some other, incompatible protocol. It
   does so by allowing the client to advertise its desire to use another
   protocol, such as a later version of HTTP with a higher major version
   number, even though the current request has been made using HTTP/1.1.
   This eases the difficult transition between incompatible protocols by
   allowing the client to initiate a request in the more commonly
   supported protocol while indicating to the server that it would like
   to use a "better" protocol if available (where "better" is determined
   by the server, possibly according to the nature of the method and/or
   resource being requested).

   The Upgrade header field only applies to switching application-layer
   protocols upon the existing transport-layer connection. Upgrade
   cannot be used to insist on a protocol change; its acceptance and use
   by the server is optional. The capabilities and nature of the
   application-layer communication after the protocol change is entirely
   dependent upon the new protocol chosen, although the first action
   after changing the protocol MUST be a response to the initial HTTP
   request containing the Upgrade header field.

   The Upgrade header field only applies to the immediate connection.
   Therefore, the upgrade keyword MUST be supplied within a Connection
   header field (section 14.10) whenever Upgrade is present in an
   HTTP/1.1 message.

   The Upgrade header field cannot be used to indicate a switch to a
   protocol on a different connection. For that purpose, it is more
   appropriate to use a 301, 302, 303, or 305 redirection response.

   This specification only defines the protocol name "HTTP" for use by
   the family of Hypertext Transfer Protocols, as defined by the HTTP
   version rules of section 3.1 and future updates to this
   specification. Any token can be used as a protocol name; however, it
   will only be useful if both the client and server associate the name
   with the same protocol.
ToP   noToC   RFC2068 - Page 134
14.42 User-Agent

   The User-Agent request-header field contains information about the
   user agent originating the request. This is for statistical purposes,
   the tracing of protocol violations, and automated recognition of user
   agents for the sake of tailoring responses to avoid particular user
   agent limitations. User agents SHOULD include this field with
   requests. The field can contain multiple product tokens (section 3.8)
   and comments identifying the agent and any subproducts which form a
   significant part of the user agent. By convention, the product tokens
   are listed in order of their significance for identifying the

          User-Agent     = "User-Agent" ":" 1*( product | comment )


          User-Agent: CERN-LineMode/2.15 libwww/2.17b3

14.43 Vary

   The Vary response-header field is used by a server to signal that the
   response entity was selected from the available representations of
   the response using server-driven negotiation (section 12). Field-
   names listed in Vary headers are those of request-headers. The Vary
   field value indicates either that the given set of header fields
   encompass the dimensions over which the representation might vary, or
   that the dimensions of variance are unspecified ("*") and thus may
   vary over any aspect of future requests.

          Vary  = "Vary" ":" ( "*" | 1#field-name )

   An HTTP/1.1 server MUST include an appropriate Vary header field with
   any cachable response that is subject to server-driven negotiation.
   Doing so allows a cache to properly interpret future requests on that
   resource and informs the user agent about the presence of negotiation
   on that resource. A server SHOULD include an appropriate Vary header
   field with a non-cachable response that is subject to server-driven
   negotiation, since this might provide the user agent with useful
   information about the dimensions over which the response might vary.

   The set of header fields named by the Vary field value is known as
   the "selecting" request-headers.

   When the cache receives a subsequent request whose Request-URI
   specifies one or more cache entries including a Vary header, the
   cache MUST NOT use such a cache entry to construct a response to the
   new request unless all of the headers named in the cached Vary header
ToP   noToC   RFC2068 - Page 135
   are present in the new request, and all of the stored selecting
   request-headers from the previous request match the corresponding
   headers in the new request.

   The selecting request-headers from two requests are defined to match
   if and only if the selecting request-headers in the first request can
   be transformed to the selecting request-headers in the second request
   by adding or removing linear whitespace (LWS) at places where this is
   allowed by the corresponding BNF, and/or combining multiple message-
   header fields with the same field name following the rules about
   message headers in section 4.2.

   A Vary field value of "*" signals that unspecified parameters,
   possibly other than the contents of request-header fields (e.g., the
   network address of the client), play a role in the selection of the
   response representation. Subsequent requests on that resource can
   only be properly interpreted by the origin server, and thus a cache
   MUST forward a (possibly conditional) request even when it has a
   fresh response cached for the resource. See section 13.6 for use of
   the Vary header by caches.

   A Vary field value consisting of a list of field-names signals that
   the representation selected for the response is based on a selection
   algorithm which considers ONLY the listed request-header field values
   in selecting the most appropriate representation. A cache MAY assume
   that the same selection will be made for future requests with the
   same values for the listed field names, for the duration of time in
   which the response is fresh.

   The field-names given are not limited to the set of standard
   request-header fields defined by this specification. Field names are

14.44 Via

   The Via general-header field MUST be used by gateways and proxies to
   indicate the intermediate protocols and recipients between the user
   agent and the server on requests, and between the origin server and
   the client on responses. It is analogous to the "Received" field of
   RFC 822 and is intended to be used for tracking message forwards,
   avoiding request loops, and identifying the protocol capabilities of
   all senders along the request/response chain.
ToP   noToC   RFC2068 - Page 136
      Via =  "Via" ":" 1#( received-protocol received-by [ comment ] )

      received-protocol = [ protocol-name "/" ] protocol-version
      protocol-name     = token
      protocol-version  = token
      received-by       = ( host [ ":" port ] ) | pseudonym
      pseudonym         = token

   The received-protocol indicates the protocol version of the message
   received by the server or client along each segment of the
   request/response chain. The received-protocol version is appended to
   the Via field value when the message is forwarded so that information
   about the protocol capabilities of upstream applications remains
   visible to all recipients.

   The protocol-name is optional if and only if it would be "HTTP". The
   received-by field is normally the host and optional port number of a
   recipient server or client that subsequently forwarded the message.
   However, if the real host is considered to be sensitive information,
   it MAY be replaced by a pseudonym. If the port is not given, it MAY
   be assumed to be the default port of the received-protocol.

   Multiple Via field values represent each proxy or gateway that has
   forwarded the message. Each recipient MUST append its information
   such that the end result is ordered according to the sequence of
   forwarding applications.

   Comments MAY be used in the Via header field to identify the software
   of the recipient proxy or gateway, analogous to the User-Agent and
   Server header fields. However, all comments in the Via field are
   optional and MAY be removed by any recipient prior to forwarding the

   For example, a request message could be sent from an HTTP/1.0 user
   agent to an internal proxy code-named "fred", which uses HTTP/1.1 to
   forward the request to a public proxy at, which completes
   the request by forwarding it to the origin server at
   The request received by would then have the following
   Via header field:

          Via: 1.0 fred, 1.1 (Apache/1.1)

   Proxies and gateways used as a portal through a network firewall
   SHOULD NOT, by default, forward the names and ports of hosts within
   the firewall region. This information SHOULD only be propagated if
   explicitly enabled. If not enabled, the received-by host of any host
   behind the firewall SHOULD be replaced by an appropriate pseudonym
   for that host.
ToP   noToC   RFC2068 - Page 137
   For organizations that have strong privacy requirements for hiding
   internal structures, a proxy MAY combine an ordered subsequence of
   Via header field entries with identical received-protocol values into
   a single such entry. For example,

          Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy

           could be collapsed to

          Via: 1.0 ricky, 1.1 mertz, 1.0 lucy

   Applications SHOULD NOT combine multiple entries unless they are all
   under the same organizational control and the hosts have already been
   replaced by pseudonyms. Applications MUST NOT combine entries which
   have different received-protocol values.

14.45 Warning

   The Warning response-header field is used to carry additional
   information about the status of a response which may not be reflected
   by the response status code. This information is typically, though
   not exclusively, used to warn about a possible lack of semantic
   transparency from caching operations.

   Warning headers are sent with responses using:

          Warning    = "Warning" ":" 1#warning-value

          warning-value = warn-code SP warn-agent SP warn-text
          warn-code  = 2DIGIT
          warn-agent = ( host [ ":" port ] ) | pseudonym
                          ; the name or pseudonym of the server adding
                          ; the Warning header, for use in debugging
          warn-text  = quoted-string

   A response may carry more than one Warning header.

   The warn-text should be in a natural language and character set that
   is most likely to be intelligible to the human user receiving the
   response.  This decision may be based on any available knowledge,
   such as the location of the cache or user, the Accept-Language field
   in a request, the Content-Language field in a response, etc. The
   default language is English and the default character set is ISO-

   If a character set other than ISO-8859-1 is used, it MUST be encoded
   in the warn-text using the method described in RFC 1522 [14].
ToP   noToC   RFC2068 - Page 138
   Any server or cache may add Warning headers to a response. New
   Warning headers should be added after any existing Warning headers. A
   cache MUST NOT delete any Warning header that it received with a
   response. However, if a cache successfully validates a cache entry,
   it SHOULD remove any Warning headers previously attached to that
   entry except as specified for specific Warning codes. It MUST then
   add any Warning headers received in the validating response. In other
   words, Warning headers are those that would be attached to the most
   recent relevant response.

   When multiple Warning headers are attached to a response, the user
   agent SHOULD display as many of them as possible, in the order that
   they appear in the response. If it is not possible to display all of
   the warnings, the user agent should follow these heuristics:

     o  Warnings that appear early in the response take priority over those
        appearing later in the response.
     o  Warnings in the user's preferred character set take priority over
        warnings in other character sets but with identical warn-codes and

   Systems that generate multiple Warning headers should order them with
   this user agent behavior in mind.

   This is a list of the currently-defined warn-codes, each with a
   recommended warn-text in English, and a description of its meaning.

10 Response is stale
  MUST be included whenever the returned response is stale. A cache may
  add this warning to any response, but may never remove it until the
  response is known to be fresh.

11 Revalidation failed
  MUST be included if a cache returns a stale response because an
  attempt to revalidate the response failed, due to an inability to
  reach the server. A cache may add this warning to any response, but
  may never remove it until the response is successfully revalidated.

12 Disconnected operation
   SHOULD be included if the cache is intentionally disconnected from
  the rest of the network for a period of time.

13 Heuristic expiration
  MUST be included if the cache heuristically chose a freshness
  lifetime greater than 24 hours and the response's age is greater than
  24 hours.
ToP   noToC   RFC2068 - Page 139
14 Transformation applied
  MUST be added by an intermediate cache or proxy if it applies any
  transformation changing the content-coding (as specified in the
  Content-Encoding header) or media-type (as specified in the
  Content-Type header) of the response, unless this Warning code
  already appears in the response. MUST NOT be deleted from a response
  even after revalidation.

99 Miscellaneous warning
  The warning text may include arbitrary information to be presented to
  a human user, or logged. A system receiving this warning MUST NOT
  take any automated action.

14.46 WWW-Authenticate

   The WWW-Authenticate response-header field MUST be included in 401
   (Unauthorized) response messages. The field value consists of at
   least one challenge that indicates the authentication scheme(s) and
   parameters applicable to the Request-URI.

          WWW-Authenticate  = "WWW-Authenticate" ":" 1#challenge

   The HTTP access authentication process is described in section 11.
   User agents MUST take special care in parsing the WWW-Authenticate
   field value if it contains more than one challenge, or if more than
   one WWW-Authenticate header field is provided, since the contents of
   a challenge may itself contain a comma-separated list of
   authentication parameters.

(page 139 continued on part 6)

Next Section