şükela:  tümü | bugün
  • fielding, et al. standards track [page 111]

    rfc 2616 http/1.1 june 1999

    s-maxage
    if a response includes an s-maxage directive, then for a shared
    cache (but not for a private cache), the maximum age specified by
    this directive overrides the maximum age specified by either the
    max-age directive or the expires header. the s-maxage directive
    also implies the semantics of the proxy-revalidate directive (see
    section 14.9.4), i.e., that the shared cache must not use the
    entry after it becomes stale to respond to a subsequent request
    without first revalidating it with the origin server. the s-
    maxage directive is always ignored by a private cache.

    note that most older caches, not compliant with this specification,
    do not implement any cache-control directives. an origin server
    wishing to use a cache-control directive that restricts, but does not
    prevent, caching by an http/1.1-compliant cache may exploit the
    requirement that the max-age directive overrides the expires header,
    and the fact that pre-http/1.1-compliant caches do not observe the
    max-age directive.

    other directives allow a user agent to modify the basic expiration
    mechanism. these directives may be specified on a request:

    max-age
    indicates that the client is willing to accept a response whose
    age is no greater than the specified time in seconds. unless max-
    stale directive is also included, the client is not willing to
    accept a stale response.

    min-fresh
    indicates that the client is willing to accept a response whose
    freshness lifetime is no less than its current age plus the
    specified time in seconds. that is, the client wants a response
    that will still be fresh for at least the specified number of
    seconds.

    max-stale
    indicates that the client is willing to accept a response that has
    exceeded its expiration time. if max-stale is assigned a value,
    then the client is willing to accept a response that has exceeded
    its expiration time by no more than the specified number of
    seconds. if no value is assigned to max-stale, then the client is
    willing to accept a stale response of any age.

    if a cache returns a stale response, either because of a max-stale
    directive on a request, or because the cache is configured to
    override the expiration time of a response, the cache must attach a
    warning header to the stale response, using warning 110 (response is
    stale).

    fielding, et al. standards track [page 112]

    rfc 2616 http/1.1 june 1999

    a cache may be configured to return stale responses without
    validation, but only if this does not conflict with any "must"-level
    requirements concerning cache validation (e.g., a "must-revalidate"
    cache-control directive).

    if both the new request and the cached entry include "max-age"
    directives, then the lesser of the two values is used for determining
    the freshness of the cached entry for that request.

    14.9.4 cache revalidation and reload controls

    sometimes a user agent might want or need to insist that a cache
    revalidate its cache entry with the origin server (and not just with
    the next cache along the path to the origin server), or to reload its
    cache entry from the origin server. end-to-end revalidation might be
    necessary if either the cache or the origin server has overestimated
    the expiration time of the cached response. end-to-end reload may be
    necessary if the cache entry has become corrupted for some reason.

    end-to-end revalidation may be requested either when the client does
    not have its own local cached copy, in which case we call it
    "unspecified end-to-end revalidation", or when the client does have a
    local cached copy, in which case we call it "specific end-to-end
    revalidation."

    the client can specify these three kinds of action using cache-
    control request directives:

    end-to-end reload
    the request includes a "no-cache" cache-control directive or, for
    compatibility with http/1.0 clients, "pragma: no-cache". field
    names must not be included with the no-cache directive in a
    request. the server must not use a cached copy when responding to
    such a request.

    specific end-to-end revalidation
    the request includes a "max-age=0" cache-control directive, which
    forces each cache along the path to the origin server to
    revalidate its own entry, if any, with the next cache or server.
    the initial request includes a cache-validating conditional with
    the client's current validator.

    unspecified end-to-end revalidation
    the request includes "max-age=0" cache-control directive, which
    forces each cache along the path to the origin server to
    revalidate its own entry, if any, with the next cache or server.
    the initial request does not include a cache-validating

    fielding, et al. standards track [page 113]

    rfc 2616 http/1.1 june 1999

    conditional; the first cache along the path (if any) that holds a
    cache entry for this resource includes a cache-validating
    conditional with its current validator.

    max-age
    when an intermediate cache is forced, by means of a max-age=0
    directive, to revalidate its own cache entry, and the client has
    supplied its own validator in the request, the supplied validator
    might differ from the validator currently stored with the cache
    entry. in this case, the cache may use either validator in making
    its own request without affecting semantic transparency.

    however, the choice of validator might affect performance. the
    best approach is for the intermediate cache to use its own
    validator when making its request. if the server replies with 304
    (not modified), then the cache can return its now validated copy
    to the client with a 200 (ok) response. if the server replies with
    a new entity and cache validator, however, the intermediate cache
    can compare the returned validator with the one provided in the
    client's request, using the strong comparison function. if the
    client's validator is equal to the origin server's, then the
    intermediate cache simply returns 304 (not modified). otherwise,
    it returns the new entity with a 200 (ok) response.

    if a request includes the no-cache directive, it should not
    include min-fresh, max-stale, or max-age.

    only-if-cached
    in some cases, such as times of extremely poor network
    connectivity, a client may want a cache to return only those
    responses that it currently has stored, and not to reload or
    revalidate with the origin server. to do this, the client may
    include the only-if-cached directive in a request. if it receives
    this directive, a cache should either respond using a cached entry
    that is consistent with the other constraints of the request, or
    respond with a 504 (gateway timeout) status. however, if a group
    of caches is being operated as a unified system with good internal
    connectivity, such a request may be forwarded within that group of
    caches.

    must-revalidate
    because a cache may be configured to ignore a server's specified
    expiration time, and because a client request may include a max-
    stale directive (which has a similar effect), the protocol also
    includes a mechanism for the origin server to require revalidation
    of a cache entry on any subsequent use. when the must-revalidate
    directive is present in a response received by a cache, that cache
    must not use the entry after it becomes stale to respond to a

    fielding, et al. standards track [page 114]

    rfc 2616 http/1.1 june 1999

    subsequent request without first revalidating it with the origin
    server. (i.e., the cache must do an end-to-end revalidation every
    time, if, based solely on the origin server's expires or max-age
    value, the cached response is stale.)

    the must-revalidate directive is necessary to support reliable
    operation for certain protocol features. in all circumstances an
    http/1.1 cache must obey the must-revalidate directive; in
    particular, if the cache cannot reach the origin server for any
    reason, it must generate a 504 (gateway timeout) response.

    servers should send the must-revalidate directive if and only if
    failure to revalidate a request on the entity could result in
    incorrect operation, such as a silently unexecuted financial
    transaction. recipients must not take any automated action that
    violates this directive, and must not automatically provide an
    unvalidated copy of the entity if revalidation fails.

    although this is not recommended, user agents operating under
    severe connectivity constraints may violate this directive but, if
    so, must explicitly warn the user that an unvalidated response has
    been provided. the warning must be provided on each unvalidated
    access, and should require explicit user confirmation.

    proxy-revalidate
    the proxy-revalidate directive has the same meaning as the must-
    revalidate directive, except that it does not apply to non-shared
    user agent caches. it can be used on a response to an
    authenticated request to permit the user's cache to store and
    later return the response without needing to revalidate it (since
    it has already been authenticated once by that user), while still
    requiring proxies that service many users to revalidate each time
    (in order to make sure that each user has been authenticated).
    note that such authenticated responses also need the public cache
    control directive in order to allow them to be cached at all.

    14.9.5 no-transform directive

    no-transform
    implementors of intermediate caches (proxies) have found it useful
    to convert the media type of certain entity bodies. a non-
    transparent proxy might, for example, convert between image
    formats in order to save cache space or to reduce the amount of
    traffic on a slow link.

    serious operational problems occur, however, when these
    transformations are applied to entity bodies intended for certain
    kinds of applications. for example, applications for medical

    fielding, et al. standards track [page 115]

    rfc 2616 http/1.1 june 1999

    imaging, scientific data analysis and those using end-to-end
    authentication, all depend on receiving an entity body that is bit
    for bit identical to the original entity-body.

    therefore, if a message includes the no-transform directive, an
    intermediate cache or proxy must not change those headers that are
    listed in section 13.5.2 as being subject to the no-transform
    directive. this implies that the cache or proxy must not change
    any aspect of the entity-body that is specified by these headers,
    including the value of the entity-body itself.

    14.9.6 cache control extensions

    the cache-control header field can be extended through the use of one
    or more cache-extension tokens, each with an optional assigned value.
    informational extensions (those which do not require a change in
    cache behavior) may be added without changing the semantics of other
    directives. behavioral extensions are designed to work by acting as
    modifiers to the existing base of cache directives. both the new
    directive and the standard directive are supplied, such that
    applications which do not understand the new directive will default
    to the behavior specified by the standard directive, and those that
    understand the new directive will recognize it as modifying the
    requirements associated with the standard directive. in this way,
    extensions to the cache-control directives can be made without
    requiring changes to the base protocol.

    this extension mechanism depends on an http cache obeying all of the
    cache-control directives defined for its native http-version, obeying
    certain extensions, and ignoring all directives that it does not
    understand.

    for example, consider a hypothetical new response directive called
    community which acts as a modifier to the private directive. we
    define this new directive to mean that, in addition to any non-shared
    cache, any cache which is shared only by members of the community
    named within its value may cache the response. an origin server
    wishing to allow the uci community to use an otherwise private
    response in their shared cache(s) could do so by including

    cache-control: private, community="uci"

    a cache seeing this header field will act correctly even if the cache
    does not understand the community cache-extension, since it will also
    see and understand the private directive and thus default to the safe
    behavior.

    fielding, et al. standards track [page 116]

    rfc 2616 http/1.1 june 1999

    unrecognized cache-directives must be ignored; it is assumed that any
    cache-directive likely to be unrecognized by an http/1.1 cache will
    be combined with standard directives (or the response's default
    cacheability) such that the cache behavior will remain minimally
    correct even if the cache does not understand the extension(s).

    14.10 connection

    the connection general-header field allows the sender to specify
    options that are desired for that particular connection and must not
    be communicated by proxies over further connections.

    the connection header has the following grammar:

    connection = "connection" ":" 1#(connection-token)
    connection-token = token

    http/1.1 proxies must parse the connection header field before a
    message is forwarded and, for each connection-token in this field,
    remove any header field(s) from the message with the same name as the
    connection-token. connection options are signaled by the presence of
    a connection-token in the connection header field, not by any
    corresponding additional header field(s), since the additional header
    field may not be sent if there are no parameters associated with that
    connection option.

    message headers listed in the connection header must not include
    end-to-end headers, such as cache-control.

    http/1.1 defines the "close" connection option for the sender to
    signal that the connection will be closed after completion of the
    response. for example,

    connection: close

    in either the request or the response header fields indicates that
    the connection should not be considered `persistent' (section 8.1)
    after the current request/response is complete.

    http/1.1 applications that do not support persistent connections must
    include the "close" connection option in every message.

    a system receiving an http/1.0 (or lower-version) message that
    includes a connection header must, for each connection-token in this
    field, remove and ignore any header field(s) from the message with
    the same name as the connection-token. this protects against mistaken
    forwarding of such header fields by pre-http/1.1 proxies. see section
    19.6.2.

    fielding, et al. standards track [page 117]

    rfc 2616 http/1.1 june 1999

    14.11 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-coding 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.
    however, a non-transparent proxy may modify the content-coding if the
    new coding is known to be acceptable to the recipient, unless the
    "no-transform" cache-control directive is present in the message.

    if the content-coding of an entity is not "identity", then the
    response must include a content-encoding entity-header (section
    14.11) that lists the non-identity content-coding(s) used.

    if the content-coding of an entity in a request message is not
    acceptable to the origin server, the server should respond with a
    status code of 415 (unsupported media type).

    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.12 content-language

    the content-language entity-header field describes the natural
    language(s) of the intended audience for the enclosed entity. note
    that this might not be equivalent to all the languages used within
    the entity-body.

    content-language = "content-language" ":" 1#language-tag

    fielding, et al. standards track [page 118]

    rfc 2616 http/1.1 june 1999

    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 might mean that the
    sender 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 would
    properly only include "en".

    content-language may be applied to any media type -- it is not
    limited to textual documents.

    14.13 content-length

    the content-length entity-header field indicates the size of the
    entity-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 transfer-length of
    the message-body, unless this is prohibited by the rules in section
    4.4.

    fielding, et al. standards track [page 119]

    rfc 2616 http/1.1 june 1999

    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.

    note that 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, unless this is prohibited by the rules in
    section 4.4.

    14.14 content-location

    the content-location entity-header field may be used to supply the
    resource location for the entity enclosed in the message when that
    entity is accessible from a location separate from the requested
    resource's uri. a server should provide a content-location for the
    variant corresponding to the response entity; especially 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.

    content-location = "content-location" ":"
    ( absoluteuri | relativeuri )

    the value of content-location also defines the base uri for the
    entity.

    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 specify the content-location uri as the request-
    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
    13.6.

    if the content-location is a relative uri, the relative uri is
    interpreted relative to the request-uri.

    the meaning of the content-location header in put or post requests is
    undefined; servers are free to ignore it in those cases.

    fielding, et al. standards track [page 120]

    rfc 2616 http/1.1 june 1999

    14.15 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 or
    client to function as an integrity check of the entity-body. only
    origin servers or clients 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-coding that has been applied, but not including
    any transfer-encoding 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.

    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.

    conversion of all line breaks to crlf must not be done before
    computing or checking the digest: the line break convention used in
    the text actually transmitted must be left unaltered when computing
    the digest.
  • fielding, et al. standards track [page 121]

    rfc 2616 http/1.1 june 1999

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

    14.16 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
    applied. range units are defined in section 3.12.

    content-range = "content-range" ":" content-range-spec

    content-range-spec = byte-content-range-spec
    byte-content-range-spec = bytes-unit sp
    byte-range-resp-spec "/"
    ( instance-length | "*" )

    byte-range-resp-spec = (first-byte-pos "-" last-byte-pos)
    | "*"
    instance-length = 1*digit

    the header should indicate the total length of the full entity-body,
    unless this length is unknown or difficult to determine. the asterisk
    "*" character means that the instance-length is unknown at the time
    when the response was generated.

    unlike byte-ranges-specifier values (see section 14.35.1), a byte-
    range-resp-spec must 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 with a byte-range-resp-spec whose last-
    byte-pos value is less than its first-byte-pos value, or whose
    instance-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.

    a server sending a response with status code 416 (requested range not
    satisfiable) should include a content-range field with a byte-range-
    resp-spec of "*". the instance-length specifies the current length of

    fielding, et al. standards track [page 122]

    rfc 2616 http/1.1 june 1999

    the selected resource. a response with status code 206 (partial
    content) must not include a content-range field with a byte-range-
    resp-spec of "*".

    examples of byte-content-range-spec values, assuming that the entity
    contains a total of 1234 bytes:

    . the first 500 bytes:
    bytes 0-499/1234

    . the second 500 bytes:
    bytes 500-999/1234

    . all except for the first 500 bytes:
    bytes 500-1233/1234

    . 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 message. the multipart
    media type used for this purpose is "multipart/byteranges" as defined
    in appendix 19.2. see appendix 19.6.3 for a compatibility issue.

    a response to a request for a single range must not be sent using the
    multipart/byteranges media type. a response to a request for
    multiple ranges, whose result is a single range, may be sent as a
    multipart/byteranges media type with one part. a client that cannot
    decode a multipart/byteranges message must 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
    request.

    fielding, et al. standards track [page 123]

    rfc 2616 http/1.1 june 1999

    if the server ignores a byte-range-spec because it is syntactically
    invalid, the server should treat the request as if the invalid range
    header field did not exist. (normally, this means return a 200
    response containing the full entity).

    if the server receives a request (other than one including an if-
    range request-header field) with an unsatisfiable range request-
    header field (that is, all of whose byte-range-spec values have a
    first-byte-pos value greater than the current length of the selected
    resource), it should return a response code of 416 (requested range
    not satisfiable) (section 10.4.17).

    note: clients cannot depend on servers to send a 416 (requested
    range not satisfiable) response instead of a 200 (ok) response for
    an unsatisfiable range request-header, since not all servers
    implement this request-header.

    14.17 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.18 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
    3.3.1; it must be sent in rfc 1123 [8]-date format.

    date = "date" ":" http-date

    an example is

    date: tue, 15 nov 1994 08:12:31 gmt

    origin servers must include a date header field in all responses,
    except in these cases:

    fielding, et al. standards track [page 124]

    rfc 2616 http/1.1 june 1999

    1. if the response status code is 100 (continue) or 101 (switching
    protocols), the response may include a date header field, at
    the server's option.

    2. if the response status code conveys a server error, e.g. 500
    (internal server error) or 503 (service unavailable), and it is
    inconvenient or impossible to generate a valid date.

    3. if the server does not have a clock that can provide a
    reasonable approximation of the current time, its responses
    must not include a date header field. in this case, the rules
    in section 14.18.1 must be followed.

    a received message that does not have a date header field must be
    assigned one by the recipient if the message will be cached by that
    recipient or gatewayed via a protocol which requires a date. an http
    implementation without a clock must not cache responses without
    revalidating them on every use. an http cache, especially a shared
    cache, should use a mechanism, such as ntp [28], to synchronize its
    clock with a reliable external standard.

    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 client without a clock must not send a date
    header field in a request.

    the http-date sent in a date header should not represent a date and
    time subsequent to the generation of the message. it should represent
    the best available approximation of the date and time of message
    generation, unless the implementation has no means of generating a
    reasonably accurate date and time. in theory, the date ought to
    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 value.

    14.18.1 clockless origin server operation

    some origin server implementations might not have a clock available.
    an origin server without a clock must not assign expires or last-
    modified values to a response, unless these values were associated
    with the resource by a system or user with a reliable clock. it may
    assign an expires value that is known, at or before server
    configuration time, to be in the past (this allows "pre-expiration"
    of responses without storing separate expires values for each
    resource).

    fielding, et al. standards track [page 125]

    rfc 2616 http/1.1 june 1999

    14.19 etag

    the etag response-header field provides the current value of the
    entity tag for the requested variant. the headers used with entity
    tags are described in sections 14.24, 14.26 and 14.44. the entity tag
    may be used for comparison with other entities from the same resource
    (see section 13.3.3).

    etag = "etag" ":" entity-tag

    examples:

    etag: "xyzzy"
    etag: w/"xyzzy"
    etag: ""

    14.20 expect

    the expect request-header field is used to indicate that particular
    server behaviors are required by the client.

    expect = "expect" ":" 1#expectation

    expectation = "100-continue" | expectation-extension
    expectation-extension = token [ "=" ( token | quoted-string )
    *expect-params ]
    expect-params = ";" token [ "=" ( token | quoted-string ) ]

    a server that does not understand or is unable to comply with any of
    the expectation values in the expect field of a request must respond
    with appropriate error status. the server must respond with a 417
    (expectation failed) status if any of the expectations cannot be met
    or, if there are other problems with the request, some other 4xx
    status.

    this header field is defined with extensible syntax to allow for
    future extensions. if a server receives a request containing an
    expect field that includes an expectation-extension that it does not
    support, it must respond with a 417 (expectation failed) status.

    comparison of expectation values is case-insensitive for unquoted
    tokens (including the 100-continue token), and is case-sensitive for
    quoted-string expectation-extensions.

    fielding, et al. standards track [page 126]

    rfc 2616 http/1.1 june 1999

    the expect mechanism is hop-by-hop: that is, an http/1.1 proxy must
    return a 417 (expectation failed) status if it receives a request
    with an expectation that it cannot meet. however, the expect
    request-header itself is end-to-end; it must be forwarded if the
    request is forwarded.

    many older http/1.0 and http/1.1 applications do not understand the
    expect header.

    see section 8.2.3 for the use of the 100 (continue) status.

    14.21 expires

    the expires entity-header field gives the date/time after which the
    response is considered stale. a stale cache entry may not normally be
    returned by a cache (either a proxy cache or a 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
    time.

    the format is an absolute date and time as defined by http-date in
    section 3.3.1; it must be in rfc 1123 date format:

    expires = "expires" ":" http-date

    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 (see section 14.9.3), 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
    expired").

    to mark a response as "already expired," an origin server sends an
    expires date that is equal to the date header value. (see the rules
    for expiration calculations in section 13.2.4.)

    fielding, et al. standards track [page 127]

    rfc 2616 http/1.1 june 1999

    to mark a response as "never expires," an origin server sends 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 a response that otherwise would by default be
    non-cacheable indicates that the response is cacheable, 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 [9] as updated by rfc 1123 [8]:

    from = "from" ":" mailbox

    an example is:

    from: webmaster@w3.org

    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.

    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
    used.

    the client should not send the from header field without the user's
    approval, as it might 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
    uri given by the user or referring resource (generally an http url,

    fielding, et al. standards track [page 128]

    rfc 2616 http/1.1 june 1999

    as described in section 3.2.2). the host field value must represent
    the naming authority 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
    <http://www.w3.org/pub/www/> would properly include:

    get /pub/www/ http/1.1
    host: www.w3.org

    a client must include a host header field in all http/1.1 request
    messages . if the requested uri does not include an internet host
    name for the service being requested, then the host header field must
    be given with an empty value. an http/1.1 proxy must ensure that any
    request message it forwards does contain an appropriate host header
    field that identifies the service being requested by the proxy. all
    internet-based http/1.1 servers must respond with a 400 (bad request)
    status code to any http/1.1 request message which lacks a host header
    field.

    see sections 5.2 and 19.6.1.1 for other requirements relating to
    host.

    14.24 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. entity tags are defined in section 3.11. 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 resource.

    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

    fielding, et al. standards track [page 129]

    rfc 2616 http/1.1 june 1999

    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
    exist.

    a server must use the strong comparison function (see section 13.3.3)
    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 or 412 status, then the if-match header
    must be ignored.

    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.44) exists, and
    must not be performed if the representation does not exist.

    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.
    examples:

    if-match: "xyzzy"
    if-match: "xyzzy", "r2d2xxxx", "c3piozzzz"
    if-match: *

    the result of a request having both an if-match header field and
    either an if-none-match or an if-modified-since header fields is
    undefined by this specification.

    14.25 if-modified-since

    the if-modified-since request-header field is used with a method to
    make it conditional: if the requested variant has not been modified
    since the time specified in this field, an entity will not 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

    fielding, et al. standards track [page 130]

    rfc 2616 http/1.1 june 1999

    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 should 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: the range request-header field modifies the meaning of if-
    modified-since; see section 14.35 for full details.

    note: if-modified-since times are interpreted by the server, whose
    clock might not be synchronized with the client.

    note: when handling an if-modified-since header field, some
    servers will use an exact date comparison function, rather than a
    less-than function, for deciding whether to send a 304 (not
    modified) response. to get best results when sending an if-
    modified-since header field for cache validation, clients are
    advised to use the exact date string received in a previous last-
    modified header field whenever possible.

    note: 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
  • fielding, et al. standards track [page 131]

    rfc 2616 http/1.1 june 1999

    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.

    the result of a request having both an if-modified-since header field
    and either an if-match or an if-unmodified-since header fields is
    undefined by this specification.

    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 to prevent a method (e.g. put)
    from inadvertently modifying an existing resource when the client
    believes that the resource does not exist.

    as a special case, the value "*" matches any current entity of the
    resource.

    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, unless required to do
    so because the resource's modification date fails to match that
    supplied in an if-modified-since header field in the request.
    instead, if the request method was get or head, the server should
    respond with a 304 (not modified) response, including the cache-
    related 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 entities tags
    match. the weak comparison function can only be used with get or head
    requests.

    fielding, et al. standards track [page 132]

    rfc 2616 http/1.1 june 1999

    if none of the entity tags match, then the server may perform the
    requested method as if the if-none-match header field did not exist,
    but must also ignore any if-modified-since header field(s) in the
    request. that is, if no entity tags match, then the server must not
    return a 304 (not modified) response.

    if the request would, without the if-none-match header field, result
    in anything other than a 2xx or 304 status, then the if-none-match
    header must be ignored. (see section 13.3.4 for a discussion of
    server behavior when both if-modified-since and if-none-match appear
    in the same request.)

    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.44)
    exists, and should be performed if the representation does not exist.
    this feature is intended to be useful in preventing races between put
    operations.

    examples:

    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: *

    the result of a request having both an if-none-match header field and
    either an if-match or an if-unmodified-since header fields is
    undefined by this specification.

    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
    entity-body.

    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
    entity'.

    if-range = "if-range" ":" ( entity-tag | http-date )

    fielding, et al. standards track [page 133]

    rfc 2616 http/1.1 june 1999

    if the client has no entity tag for an entity, but does have a last-
    modified date, it may use that date in an 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.

    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
    present.

    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 or 412 status, the
    if-unmodified-since header should be ignored.

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

    the result of a request having both an if-unmodified-since header
    field and either an if-none-match or an if-modified-since header
    fields is undefined by this specification.

    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

    fielding, et al. standards track [page 134]

    rfc 2616 http/1.1 june 1999

    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.

    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 uri for automatic redirection to the resource. the
    field value consists of a single absolute uri.

    location = "location" ":" absoluteuri

    an example is:

    location: http://www.w3.org/pub/www/people.html

    note: the content-location header field (section 14.14) 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.

    fielding, et al. standards track [page 135]

    rfc 2616 http/1.1 june 1999

    14.31 max-forwards

    the max-forwards request-header field provides a mechanism with the
    trace (section 9.8) and options (section 9.2) methods 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

    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 or options request
    containing a max-forwards header field must check and update its
    value prior to forwarding the request. if the received value is zero
    (0), the recipient must not forward the request; instead, it must
    respond as the final recipient. if the received max-forwards value is
    greater than zero, then the forwarded message must contain an updated
    max-forwards field with a value decremented by one (1).

    the max-forwards header field may 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 might 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 backward 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.

    fielding, et al. standards track [page 136]

    rfc 2616 http/1.1 june 1999

    pragma directives must be passed through by a proxy or gateway
    application, regardless of their significance to that application,
    since the directives might 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.

    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.

    note: because the meaning of "pragma: no-cache as a response
    header field is not actually specified, it does not provide a
    reliable replacement for "cache-control: no-cache" in a response

    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" ":" 1#challenge

    the http access authentication process is described in "http
    authentication: basic and digest access authentication" [43]. 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 might 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 "http
    authentication: basic and digest access authentication" [43] . 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

    fielding, et al. standards track [page 137]

    rfc 2616 http/1.1 june 1999

    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 range

    14.35.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.

    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 syntactically invalid. the recipient of a byte-range-
    set that includes one or more syntactically invalid byte-range-spec
    values must ignore the header field that includes that byte-range-
    set.

    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.

    fielding, et al. standards track [page 138]

    rfc 2616 http/1.1 june 1999

    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.

    if a syntactically valid byte-range-set includes at least one byte-
    range-spec whose first-byte-pos is less than the current length of
    the entity-body, or at least one suffix-byte-range-spec with a non-
    zero suffix-length, then the byte-range-set is satisfiable.
    otherwise, the byte-range-set is unsatisfiable. if the byte-range-set
    is unsatisfiable, the server should return a response with a status
    of 416 (requested range not satisfiable). otherwise, the server
    should return a response with a status of 206 (partial content)
    containing the satisfiable ranges of the entity-body.

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

    - the first 500 bytes (byte offsets 0-499, inclusive): bytes=0-
    499

    - the second 500 bytes (byte offsets 500-999, inclusive):
    bytes=500-999

    - the final 500 bytes (byte offsets 9500-9999, inclusive):
    bytes=-500

    - or bytes=9500-

    - the first and last bytes only (bytes 0 and 9999): bytes=0-0,-1

    - several legal but not canonical specifications of the second 500
    bytes (byte offsets 500-999, inclusive):
    bytes=500-600,601-999
    bytes=500-700,601-999

    14.35.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

    fielding, et al. standards track [page 139]

    rfc 2616 http/1.1 june 1999

    a server may ignore the range header. however, http/1.1 origin
    servers and intermediate caches ought to support byte ranges when
    possible, since range supports efficient recovery from partially
    failed transfers, and supports efficient partial retrieval of large
    entities.

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

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

    - 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 might 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.

    14.36 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 )

    example:

    referer: http://www.w3.org/…ertext/datasources/overview.html

    fielding, et al. standards track [page 140]

    rfc 2616 http/1.1 june 1999

    if the field value is a relative uri, it should be interpreted
    relative to the request-uri. the uri must not include a fragment. see
    section 15.1.3 for security considerations.

    14.37 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. this field may also be used
    with any 3xx (redirection) response to indicate the minimum time the
    user-agent is asked wait before issuing the redirected request. 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.

    14.38 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
    application.

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

    example:

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

    note: revealing the specific software version of the server might
    allow the server machine to become more vulnerable to attacks
    against software that is known to contain security holes. server
    implementors are encouraged to make this field a configurable
    option.
  • fielding, et al. standards track [page 141]

    rfc 2616 http/1.1 june 1999

    14.39 te

    the te request-header field indicates what extension transfer-codings
    it is willing to accept in the response and whether or not it is
    willing to accept trailer fields in a chunked transfer-coding. its
    value may consist of the keyword "trailers" and/or a comma-separated
    list of extension transfer-coding names with optional accept
    parameters (as described in section 3.6).

    te = "te" ":" #( t-codings )
    t-codings = "trailers" | ( transfer-extension [ accept-params ] )

    the presence of the keyword "trailers" indicates that the client is
    willing to accept trailer fields in a chunked transfer-coding, as
    defined in section 3.6.1. this keyword is reserved for use with
    transfer-coding values even though it does not itself represent a
    transfer-coding.

    examples of its use are:

    te: deflate
    te:
    te: trailers, deflate;q=0.5

    the te header field only applies to the immediate connection.
    therefore, the keyword must be supplied within a connection header
    field (section 14.10) whenever te is present in an http/1.1 message.

    a server tests whether a transfer-coding is acceptable, according to
    a te field, using these rules:

    1. the "chunked" transfer-coding is always acceptable. if the
    keyword "trailers" is listed, the client indicates that it is
    willing to accept trailer fields in the chunked response on
    behalf of itself and any downstream clients. the implication is
    that, if given, the client is stating that either all
    downstream clients are willing to accept trailer fields in the
    forwarded response, or that it will attempt to buffer the
    response on behalf of downstream recipients.

    note: http/1.1 does not define any means to limit the size of a
    chunked response such that a client can be assured of buffering
    the entire response.

    2. if the transfer-coding being tested is one of the transfer-
    codings listed in the te field, then it is acceptable unless it
    is accompanied by a qvalue of 0. (as defined in section 3.9, a
    qvalue of 0 means "not acceptable.")

    fielding, et al. standards track [page 142]

    rfc 2616 http/1.1 june 1999

    3. if multiple transfer-codings are acceptable, then the
    acceptable transfer-coding with the highest non-zero qvalue is
    preferred. the "chunked" transfer-coding always has a qvalue
    of 1.

    if the te field-value is empty or if no te field is present, the only
    transfer-coding is "chunked". a message with no transfer-coding is
    always acceptable.

    14.40 trailer

    the trailer general field value indicates that the given set of
    header fields is present in the trailer of a message encoded with
    chunked transfer-coding.

    trailer = "trailer" ":" 1#field-name

    an http/1.1 message should include a trailer header field in a
    message using chunked transfer-coding with a non-empty trailer. doing
    so allows the recipient to know which header fields to expect in the
    trailer.

    if no trailer header field is present, the trailer should not include
    any header fields. see section 3.6.1 for restrictions on the use of
    trailer fields in a "chunked" transfer-coding.

    message header fields listed in the trailer header field must not
    include the following header fields:

    . transfer-encoding

    . content-length

    . trailer

    14.41 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-coding in that the transfer-coding is a
    property of the message, not of the entity.

    transfer-encoding = "transfer-encoding" ":" 1#transfer-coding

    transfer-codings are defined in section 3.6. an example is:

    transfer-encoding: chunked

    fielding, et al. standards track [page 143]

    rfc 2616 http/1.1 june 1999

    if multiple encodings have been applied to an entity, the transfer-
    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.

    many older http/1.0 applications do not understand the transfer-
    encoding header.

    14.42 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
    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.

    fielding, et al. standards track [page 144]

    rfc 2616 http/1.1 june 1999

    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.

    14.43 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
    application.

    user-agent = "user-agent" ":" 1*( product | comment )

    example:

    user-agent: cern-linemode/2.15 libwww/2.17b3

    14.44 vary

    the vary field value indicates the set of request-header fields that
    fully determines, while the response is fresh, whether a cache is
    permitted to use the response to reply to a subsequent request
    without revalidation. for uncacheable or stale responses, the vary
    field value advises the user agent about the criteria that were used
    to select the representation. a vary field value of "*" implies that
    a cache cannot determine from the request headers of a subsequent
    request whether this response is the appropriate representation. see
    section 13.6 for use of the vary header field by caches.

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

    an http/1.1 server should include a vary header field with any
    cacheable 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

    fielding, et al. standards track [page 145]

    rfc 2616 http/1.1 june 1999

    on that resource. a server may include a vary header field with a
    non-cacheable 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 varies at the time of the
    response.

    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 for
    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
    case-insensitive.

    a vary field value of "*" signals that unspecified parameters not
    limited to the request-headers (e.g., the network address of the
    client), play a role in the selection of the response representation.
    the "*" value must not be generated by a proxy server; it may only be
    generated by an origin server.

    14.45 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 [9] 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.

    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.

    fielding, et al. standards track [page 146]

    rfc 2616 http/1.1 june 1999

    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 represents 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
    message.

    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 nowhere.com, which completes
    the request by forwarding it to the origin server at www.ics.uci.edu.
    the request received by www.ics.uci.edu would then have the following
    via header field:

    via: 1.0 fred, 1.1 nowhere.com (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.

    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

    fielding, et al. standards track [page 147]

    rfc 2616 http/1.1 june 1999

    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.46 warning

    the warning general-header field is used to carry additional
    information about the status or transformation of a message which
    might not be reflected in the message. this information is typically
    used to warn about a possible lack of semantic transparency from
    caching operations or transformations applied to the entity body of
    the message.

    warning headers are sent with responses using:

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

    warning-value = warn-code sp warn-agent sp warn-text
    [sp warn-date]

    warn-code = 3digit
    warn-agent = ( host [ ":" port ] ) | pseudonym
    ; the name or pseudonym of the server adding
    ; the warning header, for use in debugging
    warn-text = quoted-string
    warn-date = <"> http-date <">

    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-8859-1.

    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 2047 [14].

    warning headers can in general be applied to any message, however
    some specific warn-codes are specific to caches and can only be
    applied to response messages. new warning headers should be added
    after any existing warning headers. a cache must not delete any
    warning header that it received with a message. however, if a cache
    successfully validates a cache entry, it should remove any warning
    headers previously attached to that entry except as specified for

    fielding, et al. standards track [page 148]

    rfc 2616 http/1.1 june 1999

    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 ought to inform the user of as many of them as possible, in the
    order that they appear in the response. if it is not possible to
    inform the user of all of the warnings, the user agent should follow
    these heuristics:

    - warnings that appear early in the response take priority over
    those appearing later in the response.

    - warnings in the user's preferred character set take priority
    over warnings in other character sets but with identical warn-
    codes and warn-agents.

    systems that generate multiple warning headers should order them with
    this user agent behavior in mind.

    requirements for the behavior of caches with respect to warnings are
    stated in section 13.1.2.

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

    110 response is stale
    must be included whenever the returned response is stale.

    111 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.

    112 disconnected operation
    should be included if the cache is intentionally disconnected from
    the rest of the network for a period of time.

    113 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.

    199 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, besides presenting the warning to
    the user.

    fielding, et al. standards track [page 149]

    rfc 2616 http/1.1 june 1999

    214 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, or the entity-body of the
    response, unless this warning code already appears in the response.

    299 miscellaneous persistent 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.

    if an implementation sends a message with one or more warning headers
    whose version is http/1.0 or lower, then the sender must include in
    each warning-value a warn-date that matches the date in the response.

    if an implementation receives a message with a warning-value that
    includes a warn-date, and that warn-date is different from the date
    value in the response, then that warning-value must be deleted from
    the message before storing, forwarding, or using it. (this prevents
    bad consequences of naive caching of warning header fields.) if all
    of the warning-values are deleted for this reason, the warning header
    must be deleted as well.

    14.47 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 "http
    authentication: basic and digest access authentication" [43]. user
    agents are advised to take special care in parsing the www-
    authenticate field value as it might contain more than one challenge,
    or if more than one www-authenticate header field is provided, the
    contents of a challenge itself can contain a comma-separated list of
    authentication parameters.

    15 security considerations

    this section is meant to inform application developers, information
    providers, and users of the security limitations in http/1.1 as
    described by this document. the discussion does not include
    definitive solutions to the problems revealed, though it does make
    some suggestions for reducing security risks.

    fielding, et al. standards track [page 150]

    rfc 2616 http/1.1 june 1999

    15.1 personal information

    http clients are often privy to large amounts of personal information
    (e.g. the user's name, location, mail address, passwords, encryption
    keys, etc.), and should be very careful to prevent unintentional
    leakage of this information via the http protocol to other sources.
    we very strongly recommend that a convenient interface be provided
    for the user to control dissemination of such information, and that
    designers and implementors be particularly careful in this area.
    history shows that errors in this area often create serious security
    and/or privacy problems and generate highly adverse publicity for the
    implementor's company.

    15.1.1 abuse of server log information

    a server is in the position to save personal data about a user's
    requests which might identify their reading patterns or subjects of
    interest. this information is clearly confidential in nature and its
    handling can be constrained by law in certain countries. people using
    the http protocol to provide data are responsible for ensuring that
    such material is not distributed without the permission of any
    individuals that are identifiable by the published results.

    15.1.2 transfer of sensitive information

    like any generic data transfer protocol, http cannot regulate the
    content of the data that is transferred, nor is there any a priori
    method of determining the sensitivity of any particular piece of
    information within the context of any given request. therefore,
    applications should supply as much control over this information as
    possible to the provider of that information. four header fields are
    worth special mention in this context: server, via, referer and from.

    revealing the specific software version of the server might allow the
    server machine to become more vulnerable to attacks against software
    that is known to contain security holes. implementors should make the
    server header field a configurable option.

    proxies which serve as a portal through a network firewall should
    take special precautions regarding the transfer of header information
    that identifies the hosts behind the firewall. in particular, they
    should remove, or replace with sanitized versions, any via fields
    generated behind the firewall.

    the referer header allows reading patterns to be studied and reverse
    links drawn. although it can be very useful, its power can be abused
    if user details are not separated from the information contained in
  • fielding, et al. standards track [page 151]

    rfc 2616 http/1.1 june 1999

    the referer. even when the personal information has been removed, the
    referer header might indicate a private document's uri whose
    publication would be inappropriate.

    the information sent in the from field might conflict with the user's
    privacy interests or their site's security policy, and hence it
    should not be transmitted without the user being able to disable,
    enable, and modify the contents of the field. the user must be able
    to set the contents of this field within a user preference or
    application defaults configuration.

    we suggest, though do not require, that a convenient toggle interface
    be provided for the user to enable or disable the sending of from and
    referer information.

    the user-agent (section 14.43) or server (section 14.38) header
    fields can sometimes be used to determine that a specific client or
    server have a particular security hole which might be exploited.
    unfortunately, this same information is often used for other valuable
    purposes for which http currently has no better mechanism.

    15.1.3 encoding sensitive information in uri's

    because the source of a link might be private information or might
    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
    information.

    clients should not include a referer header field in a (non-secure)
    http request if the referring page was transferred with a secure
    protocol.

    authors of services which use the http protocol should not use get
    based forms for the submission of sensitive data, because this will
    cause this data to be encoded in the request-uri. many existing
    servers, proxies, and user agents will log the request uri in some
    place where it might be visible to third parties. servers can use
    post-based form submission instead

    15.1.4 privacy issues connected to accept headers

    accept request-headers can reveal information about the user to all
    servers which are accessed. the accept-language header in particular
    can reveal information the user would consider to be of a private
    nature, because the understanding of particular languages is often

    fielding, et al. standards track [page 152]

    rfc 2616 http/1.1 june 1999

    strongly correlated to the membership of a particular ethnic group.
    user agents which offer the option to configure the contents of an
    accept-language header to be sent in every request are strongly
    encouraged to let the configuration process include a message which
    makes the user aware of the loss of privacy involved.

    an approach that limits the loss of privacy would be for a user agent
    to omit the sending of accept-language headers by default, and to ask
    the user whether or not to start sending accept-language headers to a
    server if it detects, by looking for any vary response-header fields
    generated by the server, that such sending could improve the quality
    of service.

    elaborate user-customized accept header fields sent in every request,
    in particular if these include quality values, can be used by servers
    as relatively reliable and long-lived user identifiers. such user
    identifiers would allow content providers to do click-trail tracking,
    and would allow collaborating content providers to match cross-server
    click-trails or form submissions of individual users. note that for
    many users not behind a proxy, the network address of the host
    running the user agent will also serve as a long-lived user
    identifier. in environments where proxies are used to enhance
    privacy, user agents ought to be conservative in offering accept
    header configuration options to end users. as an extreme privacy
    measure, proxies could filter the accept headers in relayed requests.
    general purpose user agents which provide a high degree of header
    configurability should warn users about the loss of privacy which can
    be involved.

    15.2 attacks based on file and path names

    implementations of http origin servers should be careful to restrict
    the documents returned by http requests to be only those that were
    intended by the server administrators. if an http server translates
    http uris directly into file system calls, the server must take
    special care not to serve files that were not intended to be
    delivered to http clients. for example, unix, microsoft windows, and
    other operating systems use ".." as a path component to indicate a
    directory level above the current one. on such a system, an http
    server must disallow any such construct in the request-uri if it
    would otherwise allow access to a resource outside those intended to
    be accessible via the http server. similarly, files intended for
    reference only internally to the server (such as access control
    files, configuration files, and script code) must be protected from
    inappropriate retrieval, since they might contain sensitive
    information. experience has shown that minor bugs in such http server
    implementations have turned into security risks.

    fielding, et al. standards track [page 153]

    rfc 2616 http/1.1 june 1999

    15.3 dns spoofing

    clients using http rely heavily on the domain name service, and are
    thus generally prone to security attacks based on the deliberate
    mis-association of ip addresses and dns names. clients need to be
    cautious in assuming the continuing validity of an ip number/dns name
    association.

    in particular, http clients should rely on their name resolver for
    confirmation of an ip number/dns name association, rather than
    caching the result of previous host name lookups. many platforms
    already can cache host name lookups locally when appropriate, and
    they should be configured to do so. it is proper for these lookups to
    be cached, however, only when the ttl (time to live) information
    reported by the name server makes it likely that the cached
    information will remain useful.

    if http clients cache the results of host name lookups in order to
    achieve a performance improvement, they must observe the ttl
    information reported by dns.

    if http clients do not observe this rule, they could be spoofed when
    a previously-accessed server's ip address changes. as network
    renumbering is expected to become increasingly common [24], the
    possibility of this form of attack will grow. observing this
    requirement thus reduces this potential security vulnerability.

    this requirement also improves the load-balancing behavior of clients
    for replicated servers using the same dns name and reduces the
    likelihood of a user's experiencing failure in accessing sites which
    use that strategy.

    15.4 location headers and spoofing

    if a single server supports multiple organizations that do not trust
    one another, then it must check the values of location and content-
    location headers in responses that are generated under control of
    said organizations to make sure that they do not attempt to
    invalidate resources over which they have no authority.

    15.5 content-disposition issues

    rfc 1806 [35], from which the often implemented content-disposition
    (see section 19.5.1) header in http is derived, has a number of very
    serious security considerations. content-disposition is not part of
    the http standard, but since it is widely implemented, we are
    documenting its use and risks for implementors. see rfc 2183 [49]
    (which updates rfc 1806) for details.

    fielding, et al. standards track [page 154]

    rfc 2616 http/1.1 june 1999

    15.6 authentication credentials and idle clients

    existing http clients and user agents typically retain authentication
    information indefinitely. http/1.1. does not provide a method for a
    server to direct clients to discard these cached credentials. this is
    a significant defect that requires further extensions to http.
    circumstances under which credential caching can interfere with the
    application's security model include but are not limited to:

    - clients which have been idle for an extended period following
    which the server might wish to cause the client to reprompt the
    user for credentials.

    - applications which include a session termination indication
    (such as a logout' orcommit' button on a page) after which
    the server side of the application `knows' that there is no
    further reason for the client to retain the credentials.

    this is currently under separate study. there are a number of work-
    arounds to parts of this problem, and we encourage the use of
    password protection in screen savers, idle time-outs, and other
    methods which mitigate the security problems inherent in this
    problem. in particular, user agents which cache credentials are
    encouraged to provide a readily accessible mechanism for discarding
    cached credentials under user control.

    15.7 proxies and caching

    by their very nature, http proxies are men-in-the-middle, and
    represent an opportunity for man-in-the-middle attacks. compromise of
    the systems on which the proxies run can result in serious security
    and privacy problems. proxies have access to security-related
    information, personal information about individual users and
    organizations, and proprietary information belonging to users and
    content providers. a compromised proxy, or a proxy implemented or
    configured without regard to security and privacy considerations,
    might be used in the commission of a wide range of potential attacks.

    proxy operators should protect the systems on which proxies run as
    they would protect any system that contains or transports sensitive
    information. in particular, log information gathered at proxies often
    contains highly sensitive personal information, and/or information
    about organizations. log information should be carefully guarded, and
    appropriate guidelines for use developed and followed. (section
    15.1.1).

    fielding, et al. standards track [page 155]

    rfc 2616 http/1.1 june 1999

    caching proxies provide additional potential vulnerabilities, since
    the contents of the cache represent an attractive target for
    malicious exploitation. because cache contents persist after an http
    request is complete, an attack on the cache can reveal information
    long after a user believes that the information has been removed from
    the network. therefore, cache contents should be protected as
    sensitive information.

    proxy implementors should consider the privacy and security
    implications of their design and coding decisions, and of the
    configuration options they provide to proxy operators (especially the
    default configuration).

    users of a proxy need to be aware that they are no trustworthier than
    the people who run the proxy; http itself cannot solve this problem.

    the judicious use of cryptography, when appropriate, may suffice to
    protect against a broad range of security and privacy attacks. such
    cryptography is beyond the scope of the http/1.1 specification.

    15.7.1 denial of service attacks on proxies

    they exist. they are hard to defend against. research continues.
    beware.

    16 acknowledgments

    this specification makes heavy use of the augmented bnf and generic
    constructs defined by david h. crocker for rfc 822 [9]. similarly, it
    reuses many of the definitions provided by nathaniel borenstein and
    ned freed for mime [7]. we hope that their inclusion in this
    specification will help reduce past confusion over the relationship
    between http and internet mail message formats.

    the http protocol has evolved considerably over the years. it has
    benefited from a large and active developer community--the many
    people who have participated on the www-talk mailing list--and it is
    that community which has been most responsible for the success of
    http and of the world-wide web in general. marc andreessen, robert
    cailliau, daniel w. connolly, bob denny, john franks, jean-francois
    groff, phillip m. hallam-baker, hakon w. lie, ari luotonen, rob
    mccool, lou montulli, dave raggett, tony sanders, and marc
    vanheyningen deserve special recognition for their efforts in
    defining early aspects of the protocol.

    this document has benefited greatly from the comments of all those
    participating in the http-wg. in addition to those already mentioned,
    the following individuals have contributed to this specification:

    fielding, et al. standards track [page 156]

    rfc 2616 http/1.1 june 1999

    gary adams ross patterson
    harald tveit alvestrand albert lunde
    keith ball john c. mallery
    brian behlendorf jean-philippe martin-flatin
    paul burchard mitra
    maurizio codogno david morris
    mike cowlishaw gavin nicol
    roman czyborra bill perry
    michael a. dolan jeffrey perry
    david j. fiander scott powers
    alan freier owen rees
    marc hedlund luigi rizzo
    greg herlihy david robinson
    koen holtman marc salomon
    alex hopmann rich salz
    bob jernigan allan m. schiffman
    shel kaphan jim seidman
    rohit khare chuck shotton
    john klensin eric w. sink
    martijn koster simon e. spero
    alexei kosut richard n. taylor
    david m. kristol robert s. thau
    daniel laliberte bill (bearheart) weinman
    ben laurie francois yergeau
    paul j. leach mary ellen zurko
    daniel dubois josh cohen

    much of the content and presentation of the caching design is due to
    suggestions and comments from individuals including: shel kaphan,
    paul leach, koen holtman, david morris, and larry masinter.

    most of the specification of ranges is based on work originally done
    by ari luotonen and john franks, with additional input from steve
    zilles.

    thanks to the "cave men" of palo alto. you know who you are.

    jim gettys (the current editor of this document) wishes particularly
    to thank roy fielding, the previous editor of this document, along
    with john klensin, jeff mogul, paul leach, dave kristol, koen
    holtman, john franks, josh cohen, alex hopmann, scott lawrence, and
    larry masinter for their help. and thanks go particularly to jeff
    mogul and scott lawrence for performing the "must/may/should" audit.

    fielding, et al. standards track [page 157]

    rfc 2616 http/1.1 june 1999

    the apache group, anselm baird-smith, author of jigsaw, and henrik
    frystyk implemented rfc 2068 early, and we wish to thank them for the
    discovery of many of the problems that this document attempts to
    rectify.

    17 references

    [1] alvestrand, h., "tags for the identification of languages", rfc
    1766, march 1995.

    [2] anklesaria, f., mccahill, m., lindner, p., johnson, d., torrey,
    d. and b. alberti, "the internet gopher protocol (a distributed
    document search and retrieval protocol)", rfc 1436, march 1993.

    [3] berners-lee, t., "universal resource identifiers in www", rfc
    1630, june 1994.

    [4] berners-lee, t., masinter, l. and m. mccahill, "uniform resource
    locators (url)", rfc 1738, december 1994.

    [5] berners-lee, t. and d. connolly, "hypertext markup language -
    2.0", rfc 1866, november 1995.

    [6] berners-lee, t., fielding, r. and h. frystyk, "hypertext transfer
    protocol -- http/1.0", rfc 1945, may 1996.

    [7] freed, n. and n. borenstein, "multipurpose internet mail
    extensions (mime) part one: format of internet message bodies",
    rfc 2045, november 1996.

    [8] braden, r., "requirements for internet hosts -- communication
    layers", std 3, rfc 1123, october 1989.

    [9] crocker, d., "standard for the format of arpa internet text
    messages", std 11, rfc 822, august 1982.

    [10] davis, f., kahle, b., morris, h., salem, j., shen, t., wang, r.,
    sui, j., and m. grinbaum, "wais interface protocol prototype
    functional specification," (v1.5), thinking machines
    corporation, april 1990.

    [11] fielding, r., "relative uniform resource locators", rfc 1808,
    june 1995.

    [12] horton, m. and r. adams, "standard for interchange of usenet
    messages", rfc 1036, december 1987.

    fielding, et al. standards track [page 158]

    rfc 2616 http/1.1 june 1999

    [13] kantor, b. and p. lapsley, "network news transfer protocol", rfc
    977, february 1986.

    [14] moore, k., "mime (multipurpose internet mail extensions) part
    three: message header extensions for non-ascii text", rfc 2047,
    november 1996.

    [15] nebel, e. and l. masinter, "form-based file upload in html", rfc
    1867, november 1995.

    [16] postel, j., "simple mail transfer protocol", std 10, rfc 821,
    august 1982.

    [17] postel, j., "media type registration procedure", rfc 1590,
    november 1996.

    [18] postel, j. and j. reynolds, "file transfer protocol", std 9, rfc
    959, october 1985.

    [19] reynolds, j. and j. postel, "assigned numbers", std 2, rfc 1700,
    october 1994.

    [20] sollins, k. and l. masinter, "functional requirements for
    uniform resource names", rfc 1737, december 1994.

    [21] us-ascii. coded character set - 7-bit american standard code for
    information interchange. standard ansi x3.4-1986, ansi, 1986.

    [22] iso-8859. international standard -- information processing --
    8-bit single-byte coded graphic character sets --
    part 1: latin alphabet no. 1, iso-8859-1:1987.
    part 2: latin alphabet no. 2, iso-8859-2, 1987.
    part 3: latin alphabet no. 3, iso-8859-3, 1988.
    part 4: latin alphabet no. 4, iso-8859-4, 1988.
    part 5: latin/cyrillic alphabet, iso-8859-5, 1988.
    part 6: latin/arabic alphabet, iso-8859-6, 1987.
    part 7: latin/greek alphabet, iso-8859-7, 1987.
    part 8: latin/hebrew alphabet, iso-8859-8, 1988.
    part 9: latin alphabet no. 5, iso-8859-9, 1990.

    [23] meyers, j. and m. rose, "the content-md5 header field", rfc
    1864, october 1995.

    [24] carpenter, b. and y. rekhter, "renumbering needs work", rfc
    1900, february 1996.

    [25] deutsch, p., "gzip file format specification version 4.3", rfc
    1952, may 1996.

    fielding, et al. standards track [page 159]

    rfc 2616 http/1.1 june 1999

    [26] venkata n. padmanabhan, and jeffrey c. mogul. "improving http
    latency", computer networks and isdn systems, v. 28, pp. 25-35,
    dec. 1995. slightly revised version of paper in proc. 2nd
    international www conference '94: mosaic and the web, oct. 1994,
    which is available at
    http://www.ncsa.uiuc.edu/…edings/dday/mogul/httplat
    ency.html.

    [27] joe touch, john heidemann, and katia obraczka. "analysis of http
    performance", <url: http://www.isi.edu/touch/pubs/http-perf96/>,
    isi research report isi/rr-98-463, (original report dated aug.
    1996), usc/information sciences institute, august 1998.

    [28] mills, d., "network time protocol (version 3) specification,
    implementation and analysis", rfc 1305, march 1992.

    [29] deutsch, p., "deflate compressed data format specification
    version 1.3", rfc 1951, may 1996.

    [30] s. spero, "analysis of http performance problems,"
    http://sunsite.unc.edu/…dma-release/http-prob.html.

    [31] deutsch, p. and j. gailly, "zlib compressed data format
    specification version 3.3", rfc 1950, may 1996.

    [32] franks, j., hallam-baker, p., hostetler, j., leach, p.,
    luotonen, a., sink, e. and l. stewart, "an extension to http:
    digest access authentication", rfc 2069, january 1997.

    [33] fielding, r., gettys, j., mogul, j., frystyk, h. and t.
    berners-lee, "hypertext transfer protocol -- http/1.1", rfc
    2068, january 1997.

    [34] bradner, s., "key words for use in rfcs to indicate requirement
    levels", bcp 14, rfc 2119, march 1997.

    [35] troost, r. and dorner, s., "communicating presentation
    information in internet messages: the content-disposition
    header", rfc 1806, june 1995.

    [36] mogul, j., fielding, r., gettys, j. and h. frystyk, "use and
    interpretation of http version numbers", rfc 2145, may 1997.
    [jg639]

    [37] palme, j., "common internet message headers", rfc 2076, february
    1997. [jg640]

    fielding, et al. standards track [page 160]

    rfc 2616 http/1.1 june 1999

    [38] yergeau, f., "utf-8, a transformation format of unicode and
    iso-10646", rfc 2279, january 1998. [jg641]

    [39] nielsen, h.f., gettys, j., baird-smith, a., prud'hommeaux, e.,
    lie, h., and c. lilley. "network performance effects of
    http/1.1, css1, and png," proceedings of acm sigcomm '97, cannes
    france, september 1997.[jg642]

    [40] freed, n. and n. borenstein, "multipurpose internet mail
    extensions (mime) part two: media types", rfc 2046, november
    1996. [jg643]

    [41] alvestrand, h., "ietf policy on character sets and languages",
    bcp 18, rfc 2277, january 1998. [jg644]

    [42] berners-lee, t., fielding, r. and l. masinter, "uniform resource
    identifiers (uri): generic syntax and semantics", rfc 2396,
    august 1998. [jg645]

    [43] franks, j., hallam-baker, p., hostetler, j., lawrence, s.,
    leach, p., luotonen, a., sink, e. and l. stewart, "http
    authentication: basic and digest access authentication", rfc
    2617, june 1999. [jg646]

    [44] luotonen, a., "tunneling tcp based protocols through web proxy
    servers," work in progress. [jg647]

    [45] palme, j. and a. hopmann, "mime e-mail encapsulation of
    aggregate documents, such as html (mhtml)", rfc 2110, march
    1997.

    [46] bradner, s., "the internet standards process -- revision 3", bcp
    9, rfc 2026, october 1996.

    [47] masinter, l., "hyper text coffee pot control protocol
    (htcpcp/1.0)", rfc 2324, 1 april 1998.

    [48] freed, n. and n. borenstein, "multipurpose internet mail
    extensions (mime) part five: conformance criteria and examples",
    rfc 2049, november 1996.

    [49] troost, r., dorner, s. and k. moore, "communicating presentation
    information in internet messages: the content-disposition header
    field", rfc 2183, august 1997.
  • fielding, et al. standards track [page 161]

    rfc 2616 http/1.1 june 1999

    18 authors' addresses

    roy t. fielding
    information and computer science
    university of california, irvine
    irvine, ca 92697-3425, usa

    fax: +1 (949) 824-1715
    email: fielding@ics.uci.edu

    james gettys
    world wide web consortium
    mit laboratory for computer science
    545 technology square
    cambridge, ma 02139, usa

    fax: +1 (617) 258 8682
    email: jg@w3.org

    jeffrey c. mogul
    western research laboratory
    compaq computer corporation
    250 university avenue
    palo alto, california, 94305, usa

    email: mogul@wrl.dec.com

    henrik frystyk nielsen
    world wide web consortium
    mit laboratory for computer science
    545 technology square
    cambridge, ma 02139, usa

    fax: +1 (617) 258 8682
    email: frystyk@w3.org

    larry masinter
    xerox corporation
    3333 coyote hill road
    palo alto, ca 94034, usa

    email: masinter@parc.xerox.com

    fielding, et al. standards track [page 162]

    rfc 2616 http/1.1 june 1999

    paul j. leach
    microsoft corporation
    1 microsoft way
    redmond, wa 98052, usa

    email: paulle@microsoft.com

    tim berners-lee
    director, world wide web consortium
    mit laboratory for computer science
    545 technology square
    cambridge, ma 02139, usa

    fax: +1 (617) 258 8682
    email: timbl@w3.org

    fielding, et al. standards track [page 163]

    rfc 2616 http/1.1 june 1999

    19 appendices

    19.1 internet media type message/http and application/http

    in addition to defining the http/1.1 protocol, this document serves
    as the specification for the internet media type "message/http" and
    "application/http". the message/http type can be used to enclose a
    single http request or response message, provided that it obeys the
    mime restrictions for all "message" types regarding line length and
    encodings. the application/http type can be used to enclose a
    pipeline of one or more http request or response messages (not
    intermixed). the following is to be registered with iana [17].

    media type name: message
    media subtype name: http
    required parameters: none
    optional parameters: version, msgtype
    version: the http-version number of the enclosed message
    (e.g., "1.1"). if not present, the version can be
    determined from the first line of the body.
    msgtype: the message type -- "request" or "response". if not
    present, the type can be determined from the first
    line of the body.
    encoding considerations: only "7bit", "8bit", or "binary" are
    permitted
    security considerations: none

    media type name: application
    media subtype name: http
    required parameters: none
    optional parameters: version, msgtype
    version: the http-version number of the enclosed messages
    (e.g., "1.1"). if not present, the version can be
    determined from the first line of the body.
    msgtype: the message type -- "request" or "response". if not
    present, the type can be determined from the first
    line of the body.
    encoding considerations: http messages enclosed by this type
    are in "binary" format; use of an appropriate
    content-transfer-encoding is required when
    transmitted via e-mail.
    security considerations: none

    fielding, et al. standards track [page 164]

    rfc 2616 http/1.1 june 1999

    19.2 internet media type multipart/byteranges

    when an http 206 (partial content) response message includes the
    content of multiple ranges (a response to a request for multiple
    non-overlapping ranges), these are transmitted as a multipart
    message-body. the media type for this purpose is called
    "multipart/byteranges".

    the multipart/byteranges media type includes two or more parts, each
    with its own content-type and content-range fields. the required
    boundary parameter specifies the boundary string used to separate
    each body-part.

    media type name: multipart
    media subtype name: byteranges
    required parameters: boundary
    optional parameters: none
    encoding considerations: only "7bit", "8bit", or "binary" are
    permitted
    security considerations: none

    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-type: multipart/byteranges; boundary=this_string_separates

    --this_string_separates
    content-type: application/pdf
    content-range: bytes 500-999/8000

    ...the first range...
    --this_string_separates
    content-type: application/pdf
    content-range: bytes 7000-7999/8000

    ...the second range
    --this_string_separates--

    notes:

    1) additional crlfs may precede the first boundary string in the
    entity.

    fielding, et al. standards track [page 165]

    rfc 2616 http/1.1 june 1999

    2) although rfc 2046 [40] permits the boundary string to be
    quoted, some existing implementations handle a quoted boundary
    string incorrectly.

    3) a number of browsers and servers were coded to an early draft
    of the byteranges specification to use a media type of
    multipart/x-byteranges, which is almost, but not quite
    compatible with the version documented in http/1.1.

    19.3 tolerant applications

    although this document specifies the requirements for the generation
    of http/1.1 messages, not all applications will be correct in their
    implementation. we therefore recommend that operational applications
    be tolerant of deviations whenever those deviations can be
    interpreted unambiguously.

    clients should be tolerant in parsing the status-line and servers
    tolerant when parsing the request-line. in particular, they should
    accept any amount of sp or ht characters between fields, even though
    only a single sp is required.

    the line terminator for message-header fields is the sequence crlf.
    however, we recommend that applications, when parsing such headers,
    recognize a single lf as a line terminator and ignore the leading cr.

    the character set of an entity-body should be labeled as the lowest
    common denominator of the character codes used within that body, with
    the exception that not labeling the entity is preferred over labeling
    the entity with the labels us-ascii or iso-8859-1. see section 3.7.1
    and 3.4.1.

    additional rules for requirements on parsing and encoding of dates
    and other potential problems with date encodings include:

    - http/1.1 clients and caches should assume that an rfc-850 date
    which appears to be more than 50 years in the future is in fact
    in the past (this helps solve the "year 2000" problem).

    - an http/1.1 implementation may internally represent a parsed
    expires date as earlier than the proper value, but must not
    internally represent a parsed expires date as later than the
    proper value.

    - all expiration-related calculations must be done in gmt. the
    local time zone must not influence the calculation or comparison
    of an age or expiration time.

    fielding, et al. standards track [page 166]

    rfc 2616 http/1.1 june 1999

    - if an http header incorrectly carries a date value with a time
    zone other than gmt, it must be converted into gmt using the
    most conservative possible conversion.

    19.4 differences between http entities and rfc 2045 entities

    http/1.1 uses many of the constructs defined for internet mail (rfc
    822 [9]) and the multipurpose internet mail extensions (mime [7]) to
    allow entities to be transmitted in an open variety of
    representations and with extensible mechanisms. however, rfc 2045
    discusses mail, and http has a few features that are different from
    those described in rfc 2045. these differences were carefully chosen
    to optimize performance over binary connections, to allow greater
    freedom in the use of new media types, to make date comparisons
    easier, and to acknowledge the practice of some early http servers
    and clients.

    this appendix describes specific areas where http differs from rfc
    2045. proxies and gateways to strict mime environments should be
    aware of these differences and provide the appropriate conversions
    where necessary. proxies and gateways from mime environments to http
    also need to be aware of the differences because some conversions
    might be required.

    19.4.1 mime-version

    http is not a mime-compliant protocol. however, http/1.1 messages may
    include a single mime-version general-header field to indicate what
    version of the mime protocol was used to construct the message. use
    of the mime-version header field indicates that the message is in
    full compliance with the mime protocol (as defined in rfc 2045[7]).
    proxies/gateways are responsible for ensuring full compliance (where
    possible) when exporting http messages to strict mime environments.

    mime-version = "mime-version" ":" 1*digit "." 1*digit

    mime version "1.0" is the default for use in http/1.1. however,
    http/1.1 message parsing and semantics are defined by this document
    and not the mime specification.

    19.4.2 conversion to canonical form

    rfc 2045 [7] requires that an internet mail entity be converted to
    canonical form prior to being transferred, as described in section 4
    of rfc 2049 [48]. section 3.7.1 of this document describes the forms
    allowed for subtypes of the "text" media type when transmitted over
    http. rfc 2046 requires that content with a type of "text" represent
    line breaks as crlf and forbids the use of cr or lf outside of line

    fielding, et al. standards track [page 167]

    rfc 2616 http/1.1 june 1999

    break sequences. http allows crlf, bare cr, and bare lf to indicate a
    line break within text content when a message is transmitted over
    http.

    where it is possible, a proxy or gateway from http to a strict mime
    environment should translate all line breaks within the text media
    types described in section 3.7.1 of this document to the rfc 2049
    canonical form of crlf. note, however, that this might be complicated
    by the presence of a content-encoding and by the fact that http
    allows the use of some character sets which do not use octets 13 and
    10 to represent cr and lf, as is the case for some multi-byte
    character sets.

    implementors should note that conversion will break any cryptographic
    checksums applied to the original content unless the original content
    is already in canonical form. therefore, the canonical form is
    recommended for any content that uses such checksums in http.

    19.4.3 conversion of date formats

    http/1.1 uses a restricted set of date formats (section 3.3.1) to
    simplify the process of date comparison. proxies and gateways from
    other protocols should ensure that any date header field present in a
    message conforms to one of the http/1.1 formats and rewrite the date
    if necessary.

    19.4.4 introduction of content-encoding

    rfc 2045 does not include any concept equivalent to http/1.1's
    content-encoding header field. since this acts as a modifier on the
    media type, proxies and gateways from http to mime-compliant
    protocols must either change the value of the content-type header
    field or decode the entity-body before forwarding the message. (some
    experimental applications of content-type for internet mail have used
    a media-type parameter of ";conversions=<content-coding>" to perform
    a function equivalent to content-encoding. however, this parameter is
    not part of rfc 2045.)

    19.4.5 no content-transfer-encoding

    http does not use the content-transfer-encoding (cte) field of rfc
    2045. proxies and gateways from mime-compliant protocols to http must
    remove any non-identity cte ("quoted-printable" or "base64") encoding
    prior to delivering the response message to an http client.

    proxies and gateways from http to mime-compliant protocols are
    responsible for ensuring that the message is in the correct format
    and encoding for safe transport on that protocol, where "safe

    fielding, et al. standards track [page 168]

    rfc 2616 http/1.1 june 1999

    transport" is defined by the limitations of the protocol being used.
    such a proxy or gateway should label the data with an appropriate
    content-transfer-encoding if doing so will improve the likelihood of
    safe transport over the destination protocol.

    19.4.6 introduction of transfer-encoding

    http/1.1 introduces the transfer-encoding header field (section
    14.41). proxies/gateways must remove any transfer-coding prior to
    forwarding a message via a mime-compliant protocol.

    a process for decoding the "chunked" transfer-coding (section 3.6)
    can be represented in pseudo-code as:

    length := 0
    read chunk-size, chunk-extension (if any) and crlf
    while (chunk-size > 0) {
    read chunk-data and crlf
    append chunk-data to entity-body
    length := length + chunk-size
    read chunk-size and crlf
    }
    read entity-header
    while (entity-header not empty) {
    append entity-header to existing header fields
    read entity-header
    }
    content-length := length
    remove "chunked" from transfer-encoding

    19.4.7 mhtml and line length limitations

    http implementations which share code with mhtml [45] implementations
    need to be aware of mime line length limitations. since http does not
    have this limitation, http does not fold long lines. mhtml messages
    being transported by http follow all conventions of mhtml, including
    line length limitations and folding, canonicalization, etc., since
    http transports all message-bodies as payload (see section 3.7.2) and
    does not interpret the content or any mime header lines that might be
    contained therein.

    19.5 additional features

    rfc 1945 and rfc 2068 document protocol elements used by some
    existing http implementations, but not consistently and correctly
    across most http/1.1 applications. implementors are advised to be
    aware of these features, but cannot rely upon their presence in, or
    interoperability with, other http/1.1 applications. some of these

    fielding, et al. standards track [page 169]

    rfc 2616 http/1.1 june 1999

    describe proposed experimental features, and some describe features
    that experimental deployment found lacking that are now addressed in
    the base http/1.1 specification.

    a number of other headers, such as content-disposition and title,
    from smtp and mime are also often implemented (see rfc 2076 [37]).

    19.5.1 content-disposition

    the content-disposition response-header field has been proposed as a
    means for the origin server to suggest a default filename if the user
    requests that the content is saved to a file. this usage is derived
    from the definition of content-disposition in rfc 1806 [35].

    content-disposition = "content-disposition" ":"
    disposition-type *( ";" disposition-parm )
    disposition-type = "attachment" | disp-extension-token
    disposition-parm = filename-parm | disp-extension-parm
    filename-parm = "filename" "=" quoted-string
    disp-extension-token = token
    disp-extension-parm = token "=" ( token | quoted-string )

    an example is

    content-disposition: attachment; filename="fname.ext"

    the receiving user agent should not respect any directory path
    information present in the filename-parm parameter, which is the only
    parameter believed to apply to http implementations at this time. the
    filename should be treated as a terminal component only.

    if this header is used in a response with the application/octet-
    stream content-type, the implied suggestion is that the user agent
    should not display the response, but directly enter a `save response
    as...' dialog.

    see section 15.5 for content-disposition security issues.

    19.6 compatibility with previous versions

    it is beyond the scope of a protocol specification to mandate
    compliance with previous versions. http/1.1 was deliberately
    designed, however, to make supporting previous versions easy. it is
    worth noting that, at the time of composing this specification
    (1996), we would expect commercial http/1.1 servers to:

    - recognize the format of the request-line for http/0.9, 1.0, and
    1.1 requests;

    fielding, et al. standards track [page 170]

    rfc 2616 http/1.1 june 1999

    - understand any valid request in the format of http/0.9, 1.0, or
    1.1;

    - respond appropriately with a message in the same major version
    used by the client.

    and we would expect http/1.1 clients to:

    - recognize the format of the status-line for http/1.0 and 1.1
    responses;

    - understand any valid response in the format of http/0.9, 1.0, or
    1.1.

    for most implementations of http/1.0, each connection is established
    by the client prior to the request and closed by the server after
    sending the response. some implementations implement the keep-alive
    version of persistent connections described in section 19.7.1 of rfc
    2068 [33].

    19.6.1 changes from http/1.0

    this section summarizes major differences between versions http/1.0
    and http/1.1.

    19.6.1.1 changes to simplify multi-homed web servers and conserve ip
    addresses

    the requirements that clients and servers support the host request-
    header, report an error if the host request-header (section 14.23) is
    missing from an http/1.1 request, and accept absolute uris (section
    5.1.2) are among the most important changes defined by this
    specification.

    older http/1.0 clients assumed a one-to-one relationship of ip
    addresses and servers; there was no other established mechanism for
    distinguishing the intended server of a request than the ip address
    to which that request was directed. the changes outlined above will
    allow the internet, once older http clients are no longer common, to
    support multiple web sites from a single ip address, greatly
    simplifying large operational web servers, where allocation of many
    ip addresses to a single host has created serious problems. the
    internet will also be able to recover the ip addresses that have been
    allocated for the sole purpose of allowing special-purpose domain
    names to be used in root-level http urls. given the rate of growth of
    the web, and the number of servers already deployed, it is extremely
  • fielding, et al. standards track [page 171]

    rfc 2616 http/1.1 june 1999

    important that all implementations of http (including updates to
    existing http/1.0 applications) correctly implement these
    requirements:

    - both clients and servers must support the host request-header.

    - a client that sends an http/1.1 request must send a host header.

    - servers must report a 400 (bad request) error if an http/1.1
    request does not include a host request-header.

    - servers must accept absolute uris.

    19.6.2 compatibility with http/1.0 persistent connections

    some clients and servers might wish to be compatible with some
    previous implementations of persistent connections in http/1.0
    clients and servers. persistent connections in http/1.0 are
    explicitly negotiated as they are not the default behavior. http/1.0
    experimental implementations of persistent connections are faulty,
    and the new facilities in http/1.1 are designed to rectify these
    problems. the problem was that some existing 1.0 clients may be
    sending keep-alive to a proxy server that doesn't understand
    connection, which would then erroneously forward it to the next
    inbound server, which would establish the keep-alive connection and
    result in a hung http/1.0 proxy waiting for the close on the
    response. the result is that http/1.0 clients must be prevented from
    using keep-alive when talking to proxies.

    however, talking to proxies is the most important use of persistent
    connections, so that prohibition is clearly unacceptable. therefore,
    we need some other mechanism for indicating a persistent connection
    is desired, which is safe to use even when talking to an old proxy
    that ignores connection. persistent connections are the default for
    http/1.1 messages; we introduce a new keyword (connection: close) for
    declaring non-persistence. see section 14.10.

    the original http/1.0 form of persistent connections (the connection:
    keep-alive and keep-alive header) is documented in rfc 2068. [33]

    19.6.3 changes from rfc 2068

    this specification has been carefully audited to correct and
    disambiguate key word usage; rfc 2068 had many problems in respect to
    the conventions laid out in rfc 2119 [34].

    clarified which error code should be used for inbound server failures
    (e.g. dns failures). (section 10.5.5).

    fielding, et al. standards track [page 172]

    rfc 2616 http/1.1 june 1999

    create had a race that required an etag be sent when a resource is
    first created. (section 10.2.2).

    content-base was deleted from the specification: it was not
    implemented widely, and there is no simple, safe way to introduce it
    without a robust extension mechanism. in addition, it is used in a
    similar, but not identical fashion in mhtml [45].

    transfer-coding and message lengths all interact in ways that
    required fixing exactly when chunked encoding is used (to allow for
    transfer encoding that may not be self delimiting); it was important
    to straighten out exactly how message lengths are computed. (sections
    3.6, 4.4, 7.2.2, 13.5.2, 14.13, 14.16)

    a content-coding of "identity" was introduced, to solve problems
    discovered in caching. (section 3.5)

    quality values of zero should indicate that "i don't want something"
    to allow clients to refuse a representation. (section 3.9)

    the use and interpretation of http version numbers has been clarified
    by rfc 2145. require proxies to upgrade requests to highest protocol
    version they support to deal with problems discovered in http/1.0
    implementations (section 3.1)

    charset wildcarding is introduced to avoid explosion of character set
    names in accept headers. (section 14.2)

    a case was missed in the cache-control model of http/1.1; s-maxage
    was introduced to add this missing case. (sections 13.4, 14.8, 14.9,
    14.9.3)

    the cache-control: max-age directive was not properly defined for
    responses. (section 14.9.3)

    there are situations where a server (especially a proxy) does not
    know the full length of a response but is capable of serving a
    byterange request. we therefore need a mechanism to allow byteranges
    with a content-range not indicating the full length of the message.
    (section 14.16)

    range request responses would become very verbose if all meta-data
    were always returned; by allowing the server to only send needed
    headers in a 206 response, this problem can be avoided. (section
    10.2.7, 13.5.3, and 14.27)

    fielding, et al. standards track [page 173]

    rfc 2616 http/1.1 june 1999

    fix problem with unsatisfiable range requests; there are two cases:
    syntactic problems, and range doesn't exist in the document. the 416
    status code was needed to resolve this ambiguity needed to indicate
    an error for a byte range request that falls outside of the actual
    contents of a document. (section 10.4.17, 14.16)

    rewrite of message transmission requirements to make it much harder
    for implementors to get it wrong, as the consequences of errors here
    can have significant impact on the internet, and to deal with the
    following problems:

    1. changing "http/1.1 or later" to "http/1.1", in contexts where
    this was incorrectly placing a requirement on the behavior of
    an implementation of a future version of http/1.x

    2. made it clear that user-agents should retry requests, not
    "clients" in general.

    3. converted requirements for clients to ignore unexpected 100
    (continue) responses, and for proxies to forward 100 responses,
    into a general requirement for 1xx responses.

    4. modified some tcp-specific language, to make it clearer that
    non-tcp transports are possible for http.

    5. require that the origin server must not wait for the request
    body before it sends a required 100 (continue) response.

    6. allow, rather than require, a server to omit 100 (continue) if
    it has already seen some of the request body.

    7. allow servers to defend against denial-of-service attacks and
    broken clients.

    this change adds the expect header and 417 status code. the message
    transmission requirements fixes are in sections 8.2, 10.4.18,
    8.1.2.2, 13.11, and 14.20.

    proxies should be able to add content-length when appropriate.
    (section 13.5.2)

    clean up confusion between 403 and 404 responses. (section 10.4.4,
    10.4.5, and 10.4.11)

    warnings could be cached incorrectly, or not updated appropriately.
    (section 13.1.2, 13.2.4, 13.5.2, 13.5.3, 14.9.3, and 14.46) warning
    also needed to be a general header, as put or other methods may have
    need for it in requests.

    fielding, et al. standards track [page 174]

    rfc 2616 http/1.1 june 1999

    transfer-coding had significant problems, particularly with
    interactions with chunked encoding. the solution is that transfer-
    codings become as full fledged as content-codings. this involves
    adding an iana registry for transfer-codings (separate from content
    codings), a new header field (te) and enabling trailer headers in the
    future. transfer encoding is a major performance benefit, so it was
    worth fixing [39]. te also solves another, obscure, downward
    interoperability problem that could have occurred due to interactions
    between authentication trailers, chunked encoding and http/1.0
    clients.(section 3.6, 3.6.1, and 14.39)

    the patch, link, unlink methods were defined but not commonly
    implemented in previous versions of this specification. see rfc 2068
    [33].

    the alternates, content-version, derived-from, link, uri, public and
    content-base header fields were defined in previous versions of this
    specification, but not commonly implemented. see rfc 2068 [33].

    20 index

    please see the postscript version of this rfc for the index.

    fielding, et al. standards track [page 175]

    rfc 2616 http/1.1 june 1999

    21. full copyright statement

    copyright (c) the internet society (1999). all rights reserved.

    this document and translations of it may be copied and furnished to
    others, and derivative works that comment on or otherwise explain it
    or assist in its implementation may be prepared, copied, published
    and distributed, in whole or in part, without restriction of any
    kind, provided that the above copyright notice and this paragraph are
    included on all such copies and derivative works. however, this
    document itself may not be modified in any way, such as by removing
    the copyright notice or references to the internet society or other
    internet organizations, except as needed for the purpose of
    developing internet standards in which case the procedures for
    copyrights defined in the internet standards process must be
    followed, or as required to translate it into languages other than
    english.

    the limited permissions granted above are perpetual and will not be
    revoked by the internet society or its successors or assigns.

    this document and the information contained herein is provided on an
    "as is" basis and the internet society and the internet engineering
    task force disclaims all warranties, express or implied, including
    but not limited to any warranty that the use of the information
    herein will not infringe any rights or any implied warranties of
    merchantability or fitness for a particular purpose.

    acknowledgement

    funding for the rfc editor function is currently provided by the
    internet society.

    fielding, et al. standards track [page 176]