Ignore:
Timestamp:
03/09/12 21:12:46 (8 years ago)
Author:
fielding@…
Message:

(editorial) move header field definitions into categories

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p2-semantics.xml

    r1856 r1857  
    383383  <ttcol>Defined in...</ttcol>
    384384
     385  <c>Content-Type</c> <c><xref target="header.content-type"/></c>
    385386  <c>Content-Encoding</c> <c><xref target="header.content-encoding"/></c>
    386387  <c>Content-Language</c> <c><xref target="header.content-language"/></c>
    387388  <c>Content-Location</c> <c><xref target="header.content-location"/></c>
    388   <c>Content-Type</c> <c><xref target="header.content-type"/></c>
    389389  <c>Expires</c> <c>&header-expires;</c>
    390390</texttable>
     391
     392<section title="Content-Type" anchor="header.content-type">
     393  <iref primary="true" item="Content-Type header field" x:for-anchor=""/>
     394  <iref primary="true" item="Header Fields" subitem="Content-Type" x:for-anchor=""/>
     395  <x:anchor-alias value="Content-Type"/>
     396<t>
     397   The "Content-Type" header field indicates the media type of the
     398   representation. In the case of responses to the HEAD method, the media type is
     399   that which would have been sent had the request been a GET.
     400</t>
     401<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Type"/>
     402  <x:ref>Content-Type</x:ref> = <x:ref>media-type</x:ref>
     403</artwork></figure>
     404<t>
     405   Media types are defined in <xref target="media.types"/>. An example of the field is
     406</t>
     407<figure><artwork type="example">
     408  Content-Type: text/html; charset=ISO-8859-4
     409</artwork></figure>
     410<t>
     411   Further discussion of Content-Type is provided in <xref target="representation.data"/>.
     412</t>
     413</section>
     414
     415<section title="Content-Encoding" anchor="header.content-encoding">
     416  <iref primary="true" item="Content-Encoding header field" x:for-anchor=""/>
     417  <iref primary="true" item="Header Fields" subitem="Content-Encoding" x:for-anchor=""/>
     418  <x:anchor-alias value="Content-Encoding"/>
     419<t>
     420   The "Content-Encoding" header field indicates what content-codings
     421   have been applied to the representation beyond those inherent in the media
     422   type, and thus what decoding mechanisms have to be applied in order to obtain
     423   the media-type referenced by the <x:ref>Content-Type</x:ref> header field.
     424   Content-Encoding is primarily used to allow a representation to be
     425   compressed without losing the identity of its underlying media type.
     426</t>
     427<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Encoding"/>
     428  <x:ref>Content-Encoding</x:ref> = 1#<x:ref>content-coding</x:ref>
     429</artwork></figure>
     430<t>
     431   Content codings are defined in <xref target="content.codings"/>. An example of its use is
     432</t>
     433<figure><artwork type="example">
     434  Content-Encoding: gzip
     435</artwork></figure>
     436<t>
     437   The content-coding is a characteristic of the representation.
     438   Typically, the representation body is stored with this
     439   encoding and is only decoded before rendering or analogous usage.
     440   However, a transforming proxy &MAY; modify the content-coding if the
     441   new coding is known to be acceptable to the recipient, unless the
     442   "no-transform" cache-control directive is present in the message.
     443</t>
     444<t>
     445   If the media type includes an inherent encoding, such as a data format
     446   that is always compressed, then that encoding would not be restated as
     447   a Content-Encoding even if it happens to be the same algorithm as one
     448   of the content-codings.  Such a content-coding would only be listed if,
     449   for some bizarre reason, it is applied a second time to form the
     450   representation.  Likewise, an origin server might choose to publish the
     451   same payload data as multiple representations that differ only in whether
     452   the coding is defined as part of <x:ref>Content-Type</x:ref> or
     453   Content-Encoding, since some user agents will behave differently in their
     454   handling of each response (e.g., open a "Save as ..." dialog instead of
     455   automatic decompression and rendering of content).
     456</t>
     457<t>
     458   A representation that has a content-coding applied to it &MUST; include
     459   a Content-Encoding header field that lists the content-coding(s) applied.
     460</t>
     461<t>
     462   If multiple encodings have been applied to a representation, the content
     463   codings &MUST; be listed in the order in which they were applied.
     464   Additional information about the encoding parameters &MAY; be provided
     465   by other header fields not defined by this specification.
     466</t>
     467<t>
     468   If the content-coding of a representation in a request message is not
     469   acceptable to the origin server, the server &SHOULD; respond with a
     470   status code of 415 (Unsupported Media Type).
     471</t>
     472</section>
     473
     474<section title="Content-Language" anchor="header.content-language">
     475  <iref primary="true" item="Content-Language header field" x:for-anchor=""/>
     476  <iref primary="true" item="Header Fields" subitem="Content-Language" x:for-anchor=""/>
     477  <x:anchor-alias value="Content-Language"/>
     478<t>
     479   The "Content-Language" header field describes the natural
     480   language(s) of the intended audience for the representation. Note that this might
     481   not be equivalent to all the languages used within the representation.
     482</t>
     483<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Language"/>
     484  <x:ref>Content-Language</x:ref> = 1#<x:ref>language-tag</x:ref>
     485</artwork></figure>
     486<t>
     487   Language tags are defined in <xref target="language.tags"/>. The primary purpose of
     488   Content-Language is to allow a user to identify and differentiate
     489   representations according to the user's own preferred language. Thus, if the
     490   body content is intended only for a Danish-literate audience, the
     491   appropriate field is
     492</t>
     493<figure><artwork type="example">
     494  Content-Language: da
     495</artwork></figure>
     496<t>
     497   If no Content-Language is specified, the default is that the content
     498   is intended for all language audiences. This might mean that the
     499   sender does not consider it to be specific to any natural language,
     500   or that the sender does not know for which language it is intended.
     501</t>
     502<t>
     503   Multiple languages &MAY; be listed for content that is intended for
     504   multiple audiences. For example, a rendition of the "Treaty of
     505   Waitangi", presented simultaneously in the original Maori and English
     506   versions, would call for
     507</t>
     508<figure><artwork type="example">
     509  Content-Language: mi, en
     510</artwork></figure>
     511<t>
     512   However, just because multiple languages are present within a representation
     513   does not mean that it is intended for multiple linguistic audiences.
     514   An example would be a beginner's language primer, such as "A First
     515   Lesson in Latin", which is clearly intended to be used by an
     516   English-literate audience. In this case, the Content-Language would
     517   properly only include "en".
     518</t>
     519<t>
     520   Content-Language &MAY; be applied to any media type &mdash; it is not
     521   limited to textual documents.
     522</t>
     523</section>
     524
     525<section title="Content-Location" anchor="header.content-location">
     526  <iref primary="true" item="Content-Location header field" x:for-anchor=""/>
     527  <iref primary="true" item="Header Fields" subitem="Content-Location" x:for-anchor=""/>
     528  <x:anchor-alias value="Content-Location"/>
     529<t>
     530   The "Content-Location" header field supplies a URI that can be used
     531   as a specific identifier for the representation in this message.
     532   In other words, if one were to perform a GET on this URI at the time
     533   of this message's generation, then a <x:ref>200 (OK)</x:ref> response would
     534   contain the same representation that is enclosed as payload in this message.
     535</t>
     536<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Location"/>
     537  <x:ref>Content-Location</x:ref> = <x:ref>absolute-URI</x:ref> / <x:ref>partial-URI</x:ref>
     538</artwork></figure>
     539<t>
     540   The Content-Location value is not a replacement for the effective
     541   Request URI (&effective-request-uri;).  It is representation metadata.
     542   It has the same syntax and semantics as the header field of the same name
     543   defined for MIME body parts in <xref target="RFC2557" x:fmt="of" x:sec="4"/>.
     544   However, its appearance in an HTTP message has some special implications
     545   for HTTP recipients.
     546</t>
     547<t>
     548   If Content-Location is included in a response message and its value
     549   is the same as the effective request URI, then the response payload
     550   &SHOULD; be considered a current representation of that resource.
     551   For a GET or HEAD request, this is the same as the default semantics
     552   when no Content-Location is provided by the server.  For a state-changing
     553   request like PUT or POST, it implies that the server's response contains
     554   the new representation of that resource, thereby distinguishing it from
     555   representations that might only report about the action (e.g., "It worked!").
     556   This allows authoring applications to update their local copies without
     557   the need for a subsequent GET request.
     558</t>
     559<t>
     560   If Content-Location is included in a response message and its value
     561   differs from the effective request URI, then the origin server is
     562   informing recipients that this representation has its own, presumably
     563   more specific, identifier.  For a GET or HEAD request, this is an
     564   indication that the effective request URI identifies a resource that
     565   is subject to content negotiation and the selected representation for
     566   this response can also be found at the identified URI.  For other
     567   methods, such a Content-Location indicates that this representation
     568   contains a report on the action's status and the same report is
     569   available (for future access with GET) at the given URI.  For
     570   example, a purchase transaction made via a POST request might
     571   include a receipt document as the payload of the <x:ref>200 (OK)</x:ref>
     572   response; the Content-Location value provides an identifier for retrieving
     573   a copy of that same receipt in the future.
     574</t>
     575<t>
     576   If Content-Location is included in a request message, then it &MAY;
     577   be interpreted by the origin server as an indication of where the
     578   user agent originally obtained the content of the enclosed
     579   representation (prior to any subsequent modification of the content
     580   by that user agent).  In other words, the user agent is providing
     581   the same representation metadata that it received with the original
     582   representation.  However, such interpretation &MUST-NOT; be used to
     583   alter the semantics of the method requested by the client.  For
     584   example, if a client makes a PUT request on a negotiated resource
     585   and the origin server accepts that PUT (without redirection), then the
     586   new set of values for that resource is expected to be consistent with
     587   the one representation supplied in that PUT; the Content-Location
     588   cannot be used as a form of reverse content selection that
     589   identifies only one of the negotiated representations to be updated.
     590   If the user agent had wanted the latter semantics, it would have applied
     591   the PUT directly to the Content-Location URI.
     592</t>
     593<t>
     594   A Content-Location field received in a request message is transitory
     595   information that &SHOULD-NOT; be saved with other representation
     596   metadata for use in later responses.  The Content-Location's value
     597   might be saved for use in other contexts, such as within source links
     598   or other metadata.
     599</t>
     600<t>
     601   A cache cannot assume that a representation with a Content-Location
     602   different from the URI used to retrieve it can be used to respond to
     603   later requests on that Content-Location URI.
     604</t>
     605<t>
     606   If the Content-Location value is a partial URI, the partial URI is
     607   interpreted relative to the effective request URI.
     608</t>
     609</section>
     610</section>
     611
     612<section title="Selected Representation Header Fields" anchor="selected.representation">
    391613<t><iref primary="true" item="selected representation"/>
    392614   We use the term "<x:dfn>selected representation</x:dfn>" to refer to the
     
    620842   negotiation when the server is unwilling or unable to provide a varying
    621843   response using server-driven negotiation.
    622 </t>
    623 </section>
    624 
    625 <section title="Quality Values" anchor="quality.values">
    626   <x:anchor-alias value="weight"/>
    627   <x:anchor-alias value="qvalue"/>
    628 <t>
    629    Many of the request header fields for server-driven content negotiation
    630    use a common parameter, named "q", to assign a relative "weight" to the
    631    preference for that associated kind of content.
    632    This weight is referred to as a "quality value" (or "qvalue") because
    633    the same parameter name is often used within server configurations to
    634    assign a weight to the relative quality of the various representations
    635    that can be selected for a resource.
    636 </t>
    637 <t>
    638    The weight is normalized to a real number in the range 0 through 1,
    639    where 0.001 is the least preferred and 1 is the most preferred;
    640    a value of 0 means "not acceptable". If no "q" parameter is present,
    641    the default weight is 1.
    642 </t>
    643 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="weight"/><iref primary="true" item="Grammar" subitem="qvalue"/>
    644   <x:ref>weight</x:ref> = <x:ref>OWS</x:ref> ";" <x:ref>OWS</x:ref> "q=" <x:ref>qvalue</x:ref>
    645   <x:ref>qvalue</x:ref> = ( "0" [ "." 0*3<x:ref>DIGIT</x:ref> ] )
    646          / ( "1" [ "." 0*3("0") ] )
    647 </artwork></figure>
    648 <t>
    649    A sender of qvalue &MUST-NOT; generate more than three digits after the
    650    decimal point. User configuration of these values ought to be limited in
    651    the same fashion.
    652844</t>
    653845</section>
     
    13921584  <c>Range</c> <c>&header-range;</c>
    13931585</texttable>
     1586
     1587<section title="Max-Forwards" anchor="header.max-forwards">
     1588  <iref primary="true" item="Max-Forwards header field" x:for-anchor=""/>
     1589  <iref primary="true" item="Header Fields" subitem="Max-Forwards" x:for-anchor=""/>
     1590  <x:anchor-alias value="Max-Forwards"/>
     1591<t>
     1592   The "Max-Forwards" header field provides a mechanism with the
     1593   TRACE (<xref target="TRACE"/>) and OPTIONS (<xref target="OPTIONS"/>)
     1594   methods to limit the number of times that the request is forwarded by
     1595   proxies. This can be useful when the client is attempting to
     1596   trace a request which appears to be failing or looping mid-chain.
     1597</t>
     1598<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Max-Forwards"/>
     1599  <x:ref>Max-Forwards</x:ref> = 1*<x:ref>DIGIT</x:ref>
     1600</artwork></figure>
     1601<t>
     1602   The Max-Forwards value is a decimal integer indicating the remaining
     1603   number of times this request message can be forwarded.
     1604</t>
     1605<t>
     1606   Each recipient of a TRACE or OPTIONS request
     1607   containing a Max-Forwards header field &MUST; check and update its
     1608   value prior to forwarding the request. If the received value is zero
     1609   (0), the recipient &MUST-NOT; forward the request; instead, it &MUST;
     1610   respond as the final recipient. If the received Max-Forwards value is
     1611   greater than zero, then the forwarded message &MUST; contain an updated
     1612   Max-Forwards field with a value decremented by one (1).
     1613</t>
     1614<t>
     1615   The Max-Forwards header field &MAY; be ignored for all other request
     1616   methods.
     1617</t>
     1618</section>
     1619
     1620<section title="Expect" anchor="header.expect">
     1621  <iref primary="true" item="Expect header field" x:for-anchor=""/>
     1622  <iref primary="true" item="Header Fields" subitem="Expect" x:for-anchor=""/>
     1623  <x:anchor-alias value="Expect"/>
     1624  <x:anchor-alias value="expectation"/>
     1625  <x:anchor-alias value="expect-param"/>
     1626  <x:anchor-alias value="expect-name"/>
     1627  <x:anchor-alias value="expect-value"/>
     1628<t>
     1629   The "Expect" header field is used to indicate that particular
     1630   server behaviors are required by the client.
     1631</t>
     1632<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Expect"/><iref primary="true" item="Grammar" subitem="expectation"/><iref primary="true" item="Grammar" subitem="expect-param"/><iref primary="true" item="Grammar" subitem="expect-value"/><iref primary="true" item="Grammar" subitem="expect-name"/>
     1633  <x:ref>Expect</x:ref>       = 1#<x:ref>expectation</x:ref>
     1634 
     1635  <x:ref>expectation</x:ref>  = <x:ref>expect-name</x:ref> [ <x:ref>BWS</x:ref> "=" <x:ref>BWS</x:ref> <x:ref>expect-value</x:ref> ]
     1636                             *( <x:ref>OWS</x:ref> ";" [ <x:ref>OWS</x:ref> <x:ref>expect-param</x:ref> ] )
     1637  <x:ref>expect-param</x:ref> = <x:ref>expect-name</x:ref> [ <x:ref>BWS</x:ref> "=" <x:ref>BWS</x:ref> <x:ref>expect-value</x:ref> ]
     1638 
     1639  <x:ref>expect-name</x:ref>  = <x:ref>token</x:ref>
     1640  <x:ref>expect-value</x:ref> = <x:ref>token</x:ref> / <x:ref>quoted-string</x:ref>
     1641</artwork></figure>
     1642<t>
     1643   If all received Expect header field(s) are syntactically valid but contain
     1644   an expectation that the recipient does not understand or cannot comply with,
     1645   the recipient &MUST; respond with a <x:ref>417 (Expectation Failed)</x:ref> status code. A
     1646   recipient of a syntactically invalid Expectation header field &MUST; respond
     1647   with a <x:ref>4xx</x:ref> status code other than 417.
     1648</t>
     1649<t>
     1650   The only expectation defined by this specification is:
     1651</t>
     1652<t><iref primary="true" item="100-continue (expect value)"/><iref primary="true" item="Expect Values" subitem="100-continue"/>
     1653  100-continue
     1654   <list>
     1655      <t>
     1656        The "100-continue" expectation is defined &use100;. It does not support
     1657        any expect-params.
     1658      </t>
     1659   </list>
     1660</t>
     1661<t>
     1662   Comparison is case-insensitive for names (expect-name), and case-sensitive
     1663   for values (expect-value).
     1664</t>
     1665<t>
     1666   The Expect mechanism is hop-by-hop: the above requirements apply to any
     1667   server, including proxies. However, the Expect header field itself is
     1668   end-to-end; it &MUST; be forwarded if the request is forwarded.
     1669</t>
     1670<t>
     1671   Many older HTTP/1.0 and HTTP/1.1 applications do not understand the Expect
     1672   header field.
     1673</t>
     1674</section>
    13941675</section>
    13951676
     
    14241705  <c>Accept-Language</c> <c>&header-accept-language;</c>
    14251706</texttable>
     1707
     1708<section title="Quality Values" anchor="quality.values">
     1709  <x:anchor-alias value="weight"/>
     1710  <x:anchor-alias value="qvalue"/>
     1711<t>
     1712   Many of the request header fields for server-driven content negotiation
     1713   use a common parameter, named "q", to assign a relative "weight" to the
     1714   preference for that associated kind of content.
     1715   This weight is referred to as a "quality value" (or "qvalue") because
     1716   the same parameter name is often used within server configurations to
     1717   assign a weight to the relative quality of the various representations
     1718   that can be selected for a resource.
     1719</t>
     1720<t>
     1721   The weight is normalized to a real number in the range 0 through 1,
     1722   where 0.001 is the least preferred and 1 is the most preferred;
     1723   a value of 0 means "not acceptable". If no "q" parameter is present,
     1724   the default weight is 1.
     1725</t>
     1726<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="weight"/><iref primary="true" item="Grammar" subitem="qvalue"/>
     1727  <x:ref>weight</x:ref> = <x:ref>OWS</x:ref> ";" <x:ref>OWS</x:ref> "q=" <x:ref>qvalue</x:ref>
     1728  <x:ref>qvalue</x:ref> = ( "0" [ "." 0*3<x:ref>DIGIT</x:ref> ] )
     1729         / ( "1" [ "." 0*3("0") ] )
     1730</artwork></figure>
     1731<t>
     1732   A sender of qvalue &MUST-NOT; generate more than three digits after the
     1733   decimal point. User configuration of these values ought to be limited in
     1734   the same fashion.
     1735</t>
     1736</section>
     1737
     1738<section title="Accept" anchor="header.accept">
     1739  <iref primary="true" item="Accept header field" x:for-anchor=""/>
     1740  <iref primary="true" item="Header Fields" subitem="Accept" x:for-anchor=""/>
     1741  <x:anchor-alias value="Accept"/>
     1742  <x:anchor-alias value="accept-ext"/>
     1743  <x:anchor-alias value="accept-params"/>
     1744  <x:anchor-alias value="media-range"/>
     1745<t>
     1746   The "Accept" header field can be used by user agents to specify
     1747   response media types that are acceptable. Accept header fields can be used to
     1748   indicate that the request is specifically limited to a small set of desired
     1749   types, as in the case of a request for an in-line image.
     1750</t>
     1751<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Accept"/><iref primary="true" item="Grammar" subitem="media-range"/><iref primary="true" item="Grammar" subitem="accept-params"/><iref primary="true" item="Grammar" subitem="accept-ext"/>
     1752  <x:ref>Accept</x:ref> = #( <x:ref>media-range</x:ref> [ <x:ref>accept-params</x:ref> ] )
     1753 
     1754  <x:ref>media-range</x:ref>    = ( "*/*"
     1755                   / ( <x:ref>type</x:ref> "/" "*" )
     1756                   / ( <x:ref>type</x:ref> "/" <x:ref>subtype</x:ref> )
     1757                   ) *( <x:ref>OWS</x:ref> ";" <x:ref>OWS</x:ref> <x:ref>parameter</x:ref> )
     1758  <x:ref>accept-params</x:ref>  = <x:ref>weight</x:ref> *( <x:ref>accept-ext</x:ref> )
     1759  <x:ref>accept-ext</x:ref>     = <x:ref>OWS</x:ref> ";" <x:ref>OWS</x:ref> <x:ref>token</x:ref> [ "=" <x:ref>word</x:ref> ]
     1760</artwork></figure>
     1761<t>
     1762   The asterisk "*" character is used to group media types into ranges,
     1763   with "*/*" indicating all media types and "type/*" indicating all
     1764   subtypes of that type. The media-range &MAY; include media type
     1765   parameters that are applicable to that range.
     1766</t>
     1767<t>
     1768   Each media-range &MAY; be followed by one or more accept-params,
     1769   beginning with the "q" parameter for indicating a relative weight,
     1770   as defined in &qvalue;.
     1771   The first "q" parameter (if any) separates the media-range
     1772   parameter(s) from the accept-params.
     1773</t>
     1774<x:note>
     1775  <t>
     1776    &Note; Use of the "q" parameter name to separate media type
     1777    parameters from Accept extension parameters is due to historical
     1778    practice. Although this prevents any media type parameter named
     1779    "q" from being used with a media range, such an event is believed
     1780    to be unlikely given the lack of any "q" parameters in the IANA
     1781    media type registry and the rare usage of any media type
     1782    parameters in Accept. Future media types are discouraged from
     1783    registering any parameter named "q".
     1784  </t>
     1785</x:note>
     1786<t>
     1787   The example
     1788</t>
     1789<figure><artwork type="example">
     1790  Accept: audio/*; q=0.2, audio/basic
     1791</artwork></figure>
     1792<t>
     1793   &SHOULD; be interpreted as "I prefer audio/basic, but send me any audio
     1794   type if it is the best available after an 80% mark-down in quality".
     1795</t>
     1796<t>
     1797   A request without any Accept header field implies that the user agent
     1798   will accept any media type in response.
     1799   If an Accept header field is present in a request and none of the
     1800   available representations for the response have a media type that is
     1801   listed as acceptable, the origin server &MAY; either honor the Accept
     1802   header field by sending a <x:ref>406 (Not Acceptable)</x:ref> response
     1803   or disregard the Accept header field by treating the response as if
     1804   it is not subject to content negotiation.
     1805</t>
     1806<t>
     1807   A more elaborate example is
     1808</t>
     1809<figure><artwork type="example">
     1810  Accept: text/plain; q=0.5, text/html,
     1811          text/x-dvi; q=0.8, text/x-c
     1812</artwork></figure>
     1813<t>
     1814   Verbally, this would be interpreted as "text/html and text/x-c are
     1815   the preferred media types, but if they do not exist, then send the
     1816   text/x-dvi representation, and if that does not exist, send the text/plain
     1817   representation".
     1818</t>
     1819<t>
     1820   Media ranges can be overridden by more specific media ranges or
     1821   specific media types. If more than one media range applies to a given
     1822   type, the most specific reference has precedence. For example,
     1823</t>
     1824<figure><artwork type="example">
     1825  Accept: text/*, text/plain, text/plain;format=flowed, */*
     1826</artwork></figure>
     1827<t>
     1828   have the following precedence:
     1829   <list style="numbers">
     1830    <t>text/plain;format=flowed</t>
     1831    <t>text/plain</t>
     1832    <t>text/*</t>
     1833    <t>*/*</t>
     1834   </list>
     1835</t>
     1836<t>
     1837   The media type quality factor associated with a given type is
     1838   determined by finding the media range with the highest precedence
     1839   which matches that type. For example,
     1840</t>
     1841<figure><artwork type="example">
     1842  Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,
     1843          text/html;level=2;q=0.4, */*;q=0.5
     1844</artwork></figure>
     1845<t>
     1846   would cause the following values to be associated:
     1847</t>
     1848<texttable align="left">
     1849  <ttcol>Media Type</ttcol><ttcol>Quality Value</ttcol>
     1850  <c>text/html;level=1</c>    <c>1</c>
     1851  <c>text/html</c>            <c>0.7</c>
     1852  <c>text/plain</c>           <c>0.3</c>
     1853  <c>image/jpeg</c>           <c>0.5</c>
     1854  <c>text/html;level=2</c>    <c>0.4</c>
     1855  <c>text/html;level=3</c>    <c>0.7</c>
     1856</texttable>
     1857<t>
     1858   &Note; A user agent might be provided with a default set of quality
     1859   values for certain media ranges. However, unless the user agent is
     1860   a closed system which cannot interact with other rendering agents,
     1861   this default set ought to be configurable by the user.
     1862</t>
     1863</section>
     1864
     1865<section title="Accept-Charset" anchor="header.accept-charset">
     1866  <iref primary="true" item="Accept-Charset header field" x:for-anchor=""/>
     1867  <iref primary="true" item="Header Fields" subitem="Accept-Charset" x:for-anchor=""/>
     1868  <x:anchor-alias value="Accept-Charset"/>
     1869<t>
     1870   The "Accept-Charset" header field can be used by user agents to
     1871   indicate what character encodings are acceptable in a response
     1872   payload. This field allows
     1873   clients capable of understanding more comprehensive or special-purpose
     1874   character encodings to signal that capability to a server which is capable of
     1875   representing documents in those character encodings.
     1876</t>
     1877<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Accept-Charset"/>
     1878  <x:ref>Accept-Charset</x:ref> = 1#( ( <x:ref>charset</x:ref> / "*" ) [ <x:ref>weight</x:ref> ] )
     1879</artwork></figure>
     1880<t>
     1881   Character encoding values (a.k.a., charsets) are described in
     1882   <xref target="character.sets"/>. Each charset &MAY; be given an
     1883   associated quality value which represents the user's preference
     1884   for that charset, as defined in &qvalue;.
     1885   An example is
     1886</t>
     1887<figure><artwork type="example">
     1888  Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
     1889</artwork></figure>
     1890<t>
     1891   The special value "*", if present in the Accept-Charset field,
     1892   matches every character encoding which is not mentioned elsewhere in the
     1893   Accept-Charset field. If no "*" is present in an Accept-Charset field,
     1894   then any character encodings not explicitly mentioned in the field are
     1895   considered "not acceptable" to the client.
     1896</t>
     1897<t>
     1898   A request without any Accept-Charset header field implies that the user
     1899   agent will accept any character encoding in response.
     1900</t>
     1901<t>
     1902   If an Accept-Charset header field is present in a request and none of the
     1903   available representations for the response have a character encoding that
     1904   is listed as acceptable, the origin server &MAY; either honor the
     1905   Accept-Charset header field by sending a <x:ref>406 (Not Acceptable)</x:ref> response or
     1906   disregard the Accept-Charset header field by treating the response as if
     1907   it is not subject to content negotiation.
     1908</t>
     1909</section>
     1910
     1911<section title="Accept-Encoding" anchor="header.accept-encoding">
     1912  <iref primary="true" item="Accept-Encoding header field" x:for-anchor=""/>
     1913  <iref primary="true" item="Header Fields" subitem="Accept-Encoding" x:for-anchor=""/>
     1914  <x:anchor-alias value="Accept-Encoding"/>
     1915  <x:anchor-alias value="codings"/>
     1916<t>
     1917   The "Accept-Encoding" header field can be used by user agents to
     1918   indicate what response content-codings (<xref target="content.codings"/>)
     1919   are acceptable in the response.  An "identity" token is used as a synonym
     1920   for "no encoding" in order to communicate when no encoding is preferred.
     1921</t>
     1922<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Accept-Encoding"/><iref primary="true" item="Grammar" subitem="codings"/>
     1923  <x:ref>Accept-Encoding</x:ref>  = #( <x:ref>codings</x:ref> [ <x:ref>weight</x:ref> ] )
     1924  <x:ref>codings</x:ref>          = <x:ref>content-coding</x:ref> / "identity" / "*"
     1925</artwork></figure>
     1926<t>
     1927   Each codings value &MAY; be given an associated quality value which
     1928   represents the preference for that encoding, as defined in &qvalue;.
     1929</t>
     1930<t>
     1931   For example,
     1932</t>
     1933<figure><artwork type="example">
     1934  Accept-Encoding: compress, gzip
     1935  Accept-Encoding:
     1936  Accept-Encoding: *
     1937  Accept-Encoding: compress;q=0.5, gzip;q=1.0
     1938  Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0
     1939</artwork></figure>
     1940<t>
     1941   A server tests whether a content-coding for a given representation is
     1942   acceptable, according to an Accept-Encoding field, using these rules:
     1943  <list style="numbers">
     1944      <t>The special "*" symbol in an Accept-Encoding field matches any
     1945         available content-coding not explicitly listed in the header
     1946         field.</t>
     1947
     1948      <t>If the representation has no content-coding, then it is acceptable
     1949         by default unless specifically excluded by the Accept-Encoding field
     1950         stating either "identity;q=0" or "*;q=0" without a more specific
     1951         entry for "identity".</t>
     1952
     1953      <t>If the representation's content-coding is one of the content-codings
     1954         listed in the Accept-Encoding field, then it is acceptable unless
     1955         it is accompanied by a qvalue of 0. (As defined in &qvalue;, a
     1956         qvalue of 0 means "not acceptable".)</t>
     1957
     1958      <t>If multiple content-codings are acceptable, then the acceptable
     1959         content-coding with the highest non-zero qvalue is preferred.</t>
     1960  </list>
     1961</t>
     1962<t>
     1963   An Accept-Encoding header field with a combined field-value that is empty
     1964   implies that the user agent does not want any content-coding in response.
     1965   If an Accept-Encoding header field is present in a request and none of the
     1966   available representations for the response have a content-coding that
     1967   is listed as acceptable, the origin server &SHOULD; send a response
     1968   without any content-coding.
     1969</t>
     1970<t>
     1971   A request without an Accept-Encoding header field implies that the user
     1972   agent will accept any content-coding in response.
     1973</t>
     1974<x:note>
     1975  <t>
     1976    &Note; Most HTTP/1.0 applications do not recognize or obey qvalues
     1977    associated with content-codings. This means that qvalues will not
     1978    work and are not permitted with x-gzip or x-compress.
     1979  </t>
     1980</x:note>
     1981</section>
     1982
     1983<section title="Accept-Language" anchor="header.accept-language">
     1984  <iref primary="true" item="Accept-Language header field" x:for-anchor=""/>
     1985  <iref primary="true" item="Header Fields" subitem="Accept-Language" x:for-anchor=""/>
     1986  <x:anchor-alias value="Accept-Language"/>
     1987  <x:anchor-alias value="language-range"/>
     1988<t>
     1989   The "Accept-Language" header field can be used by user agents to
     1990   indicate the set of natural languages that are preferred in the response.
     1991   Language tags are defined in <xref target="language.tags"/>.
     1992</t>
     1993<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Accept-Language"/><iref primary="true" item="Grammar" subitem="language-range"/>
     1994  <x:ref>Accept-Language</x:ref> = 1#( <x:ref>language-range</x:ref> [ <x:ref>weight</x:ref> ] )
     1995  <x:ref>language-range</x:ref>  =
     1996            &lt;language-range, defined in <xref target="RFC4647" x:fmt="," x:sec="2.1"/>&gt;
     1997</artwork></figure>
     1998<t>
     1999   Each language-range can be given an associated quality value which
     2000   represents an estimate of the user's preference for the languages
     2001   specified by that range, as defined in &qvalue;. For example,
     2002</t>
     2003<figure><artwork type="example">
     2004  Accept-Language: da, en-gb;q=0.8, en;q=0.7
     2005</artwork></figure>
     2006<t>
     2007   would mean: "I prefer Danish, but will accept British English and
     2008   other types of English".
     2009   (see also <xref target="RFC4647" x:sec="2.3" x:fmt="of"/>)
     2010</t>
     2011<t>
     2012   For matching, <xref target="RFC4647" x:sec="3" x:fmt="of"/> defines
     2013   several matching schemes. Implementations can offer the most appropriate
     2014   matching scheme for their requirements.
     2015</t>
     2016<x:note>
     2017  <t>
     2018    &Note; The "Basic Filtering" scheme (<xref target="RFC4647"
     2019    x:fmt="," x:sec="3.3.1"/>) is identical to the matching scheme that was
     2020    previously defined in <xref target="RFC2616" x:fmt="of" x:sec="14.4"/>.
     2021  </t>
     2022</x:note>
     2023<t>
     2024   It might be contrary to the privacy expectations of the user to send
     2025   an Accept-Language header field with the complete linguistic preferences of
     2026   the user in every request. For a discussion of this issue, see
     2027   <xref target="privacy.issues.connected.to.accept.header.fields"/>.
     2028</t>
     2029<t>
     2030   As intelligibility is highly dependent on the individual user, it is
     2031   recommended that client applications make the choice of linguistic
     2032   preference available to the user. If the choice is not made
     2033   available, then the Accept-Language header field &MUST-NOT; be given in
     2034   the request.
     2035</t>
     2036<x:note>
     2037  <t>
     2038    &Note; When making the choice of linguistic preference available to
     2039    the user, we remind implementers of  the fact that users are not
     2040    familiar with the details of language matching as described above,
     2041    and ought to be provided appropriate guidance. As an example, users
     2042    might assume that on selecting "en-gb", they will be served any
     2043    kind of English document if British English is not available. A
     2044    user agent might suggest in such a case to add "en" to get the
     2045    best matching behavior.
     2046  </t>
     2047</x:note>
     2048</section>
    14262049</section>
    14272050
     
    14462069  <c>User-Agent</c> <c><xref target="header.user-agent"/></c>
    14472070</texttable>
     2071
     2072<section title="From" anchor="header.from">
     2073  <iref primary="true" item="From header field" x:for-anchor=""/>
     2074  <iref primary="true" item="Header Fields" subitem="From" x:for-anchor=""/>
     2075  <x:anchor-alias value="From"/>
     2076  <x:anchor-alias value="mailbox"/>
     2077<t>
     2078   The "From" header field, if given, &SHOULD; contain an Internet
     2079   e-mail address for the human user who controls the requesting user
     2080   agent. The address &SHOULD; be machine-usable, as defined by "mailbox"
     2081   in <xref x:sec="3.4" x:fmt="of" target="RFC5322"/>:
     2082</t>
     2083<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="From"/>
     2084  <x:ref>From</x:ref>    = <x:ref>mailbox</x:ref>
     2085 
     2086  <x:ref>mailbox</x:ref> = &lt;mailbox, defined in <xref x:sec="3.4" x:fmt="," target="RFC5322"/>&gt;
     2087</artwork></figure>
     2088<t>
     2089   An example is:
     2090</t>
     2091<figure><artwork type="example">
     2092  From: webmaster@example.org
     2093</artwork></figure>
     2094<t>
     2095   This header field &MAY; be used for logging purposes and as a means for
     2096   identifying the source of invalid or unwanted requests. It &SHOULD-NOT;
     2097   be used as an insecure form of access protection. The interpretation
     2098   of this field is that the request is being performed on behalf of the
     2099   person given, who accepts responsibility for the method performed. In
     2100   particular, robot agents &SHOULD; include this header field so that the
     2101   person responsible for running the robot can be contacted if problems
     2102   occur on the receiving end.
     2103</t>
     2104<t>
     2105   The Internet e-mail address in this field &MAY; be separate from the
     2106   Internet host which issued the request. For example, when a request
     2107   is passed through a proxy the original issuer's address &SHOULD; be
     2108   used.
     2109</t>
     2110<t>
     2111   The client &SHOULD-NOT;  send the From header field without the user's
     2112   approval, as it might conflict with the user's privacy interests or
     2113   their site's security policy. It is strongly recommended that the
     2114   user be able to disable, enable, and modify the value of this field
     2115   at any time prior to a request.
     2116</t>
     2117</section>
     2118
     2119<section title="Referer" anchor="header.referer">
     2120  <iref primary="true" item="Referer header field" x:for-anchor=""/>
     2121  <iref primary="true" item="Header Fields" subitem="Referer" x:for-anchor=""/>
     2122  <x:anchor-alias value="Referer"/>
     2123<t>
     2124   The "Referer" [sic] header field allows the client to specify the
     2125   URI of the resource from which the target URI was obtained (the
     2126   "referrer", although the header field is misspelled.).
     2127</t>
     2128<t>
     2129   The Referer header field allows servers to generate lists of back-links to
     2130   resources for interest, logging, optimized caching, etc. It also allows
     2131   obsolete or mistyped links to be traced for maintenance. Some servers use
     2132   Referer as a means of controlling where they allow links from (so-called
     2133   "deep linking"), but legitimate requests do not always
     2134   contain a Referer header field.
     2135</t>
     2136<t>
     2137   If the target URI was obtained from a source that does not have its own
     2138   URI (e.g., input from the user keyboard), the Referer field &MUST; either be
     2139   sent with the value "about:blank", or not be sent at all. Note that this
     2140   requirement does not apply to sources with non-HTTP URIs (e.g., FTP).
     2141</t>
     2142<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Referer"/>
     2143  <x:ref>Referer</x:ref> = <x:ref>absolute-URI</x:ref> / <x:ref>partial-URI</x:ref>
     2144</artwork></figure>
     2145<t>
     2146   Example:
     2147</t>
     2148<figure><artwork type="example">
     2149  Referer: http://www.example.org/hypertext/Overview.html
     2150</artwork></figure>
     2151<t>
     2152   If the field value is a relative URI, it &SHOULD; be interpreted
     2153   relative to the effective request URI. The URI &MUST-NOT; include a fragment. See
     2154   <xref target="encoding.sensitive.information.in.uris"/> for security considerations.
     2155</t>
     2156</section>
     2157
     2158<section title="User-Agent" anchor="header.user-agent">
     2159  <iref primary="true" item="User-Agent header field" x:for-anchor=""/>
     2160  <iref primary="true" item="Header Fields" subitem="User-Agent" x:for-anchor=""/>
     2161  <x:anchor-alias value="User-Agent"/>
     2162<t>
     2163   The "User-Agent" header field contains information about the user
     2164   agent originating the request. User agents &SHOULD; include this field with
     2165   requests.
     2166</t>
     2167<t>
     2168   Typically, it is used for statistical purposes, the tracing of protocol
     2169   violations, and tailoring responses to avoid particular user agent
     2170   limitations.
     2171</t>
     2172<t>
     2173   The field can contain multiple
     2174   product tokens (<xref target="product.tokens"/>)
     2175   and comments (&header-fields;) identifying the agent and its
     2176   significant subproducts. By convention, the product tokens are listed in
     2177   order of their significance for identifying the application.
     2178</t>
     2179<t>
     2180   Because this field is usually sent on every request a user agent makes,
     2181   implementations are encouraged not to include needlessly fine-grained
     2182   detail, and to limit (or even prohibit) the addition of subproducts by third
     2183   parties. Overly long and detailed User-Agent field values make requests
     2184   larger and can also be used to identify ("fingerprint") the user against
     2185   their wishes.
     2186</t>
     2187<t>
     2188   Likewise, implementations are encouraged not to use the product tokens of
     2189   other implementations in order to declare compatibility with them, as this
     2190   circumvents the purpose of the field. Finally, they are encouraged not to
     2191   use comments to identify products; doing so makes the field value more
     2192   difficult to parse.
     2193</t>
     2194<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="User-Agent"/>
     2195  <x:ref>User-Agent</x:ref> = <x:ref>product</x:ref> *( <x:ref>RWS</x:ref> ( <x:ref>product</x:ref> / <x:ref>comment</x:ref> ) )
     2196</artwork></figure>
     2197<t>
     2198   Example:
     2199</t>
     2200<figure><artwork type="example">
     2201  User-Agent: CERN-LineMode/2.15 libwww/2.17b3
     2202</artwork></figure>
     2203</section>
    14482204</section>
    14492205</section>
     
    24713227  <c>Retry-After</c> <c><xref target="header.retry-after"/></c>
    24723228</texttable>
     3229
     3230<section title="Location" anchor="header.location">
     3231  <iref primary="true" item="Location header field" x:for-anchor=""/>
     3232  <iref primary="true" item="Header Fields" subitem="Location" x:for-anchor=""/>
     3233  <x:anchor-alias value="Location"/>
     3234<t>
     3235   The "Location" header field &MAY; be sent in responses to refer to
     3236   a specific resource in accordance with the semantics of the status
     3237   code.
     3238</t>
     3239<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Location"/>
     3240  <x:ref>Location</x:ref> = <x:ref>URI-reference</x:ref>
     3241</artwork></figure>
     3242<t>
     3243   For <x:ref>201 (Created)</x:ref> responses, the Location is the URI of the
     3244   new resource which was created by the request. For <x:ref>3xx (Redirection)</x:ref>
     3245   responses, the location &SHOULD; indicate the server's preferred URI for
     3246   automatic redirection to the resource.
     3247</t>
     3248<t>
     3249   The field value consists of a single URI-reference. When it has the form
     3250   of a relative reference (<xref target="RFC3986" x:fmt="," x:sec="4.2"/>),
     3251   the final value is computed by resolving it against the effective request
     3252   URI (<xref target="RFC3986" x:fmt="," x:sec="5"/>). If the original URI, as
     3253   navigated to by the user agent, did contain a fragment identifier, and the
     3254   final value does not, then the original URI's fragment identifier is added
     3255   to the final value.
     3256</t>
     3257<figure>
     3258<preamble>For example, the original URI "http://www.example.org/~tim", combined with a field value given as:</preamble><!--DO NOT DARE changing the vertical spacing below, it's necessary this way for xml2rfc-->
     3259<artwork type="example">
     3260  Location: /pub/WWW/People.html#tim
     3261</artwork>
     3262<postamble>would result in a final value of "http://www.example.org/pub/WWW/People.html#tim"</postamble>
     3263</figure>
     3264<figure>
     3265<preamble>An original URI "http://www.example.org/index.html#larry", combined with a field value given as:</preamble><!--DO NOT DARE changing the vertical spacing below, it's necessary this way for xml2rfc-->
     3266<artwork type="example">
     3267  Location: http://www.example.net/index.html
     3268</artwork>
     3269<postamble>would result in a final value of "http://www.example.net/index.html#larry", preserving the original fragment identifier.</postamble>
     3270</figure>
     3271<x:note>
     3272  <t>
     3273    &Note; Some recipients attempt to recover from Location fields
     3274    that are not valid URI references. This specification does not mandate or
     3275    define such processing, but does allow it.
     3276  </t>
     3277</x:note>
     3278<t>
     3279   There are circumstances in which a fragment identifier in a Location URI
     3280   would not be appropriate. For instance, when it appears in a <x:ref>201
     3281   (Created)</x:ref> response, where the Location header field specifies the
     3282   URI for the entire created resource.
     3283</t>
     3284<x:note>
     3285  <t>
     3286    &Note; The <x:ref>Content-Location</x:ref> header field
     3287    (&header-content-location;) differs from Location in that the
     3288    Content-Location identifies the most specific resource corresponding to the
     3289    enclosed representation. It is therefore possible for a response to contain
     3290    header fields for both Location and Content-Location.
     3291  </t>
     3292</x:note>
     3293</section>
     3294
     3295<section title="Retry-After" anchor="header.retry-after">
     3296  <iref primary="true" item="Retry-After header field" x:for-anchor=""/>
     3297  <iref primary="true" item="Header Fields" subitem="Retry-After" x:for-anchor=""/>
     3298  <x:anchor-alias value="Retry-After"/>
     3299<t>
     3300   The header "Retry-After" field can be used with a <x:ref>503 (Service
     3301   Unavailable)</x:ref> response to indicate how long the service is expected to
     3302   be unavailable to the requesting client. This field &MAY; also be used
     3303   with any <x:ref>3xx (Redirection)</x:ref> response to indicate the minimum time the
     3304   user-agent is asked to wait before issuing the redirected request.
     3305</t>
     3306<t>
     3307   The value of this field can be either an HTTP-date or an integer number
     3308   of seconds (in decimal) after the time of the response.
     3309</t>
     3310<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Retry-After"/>
     3311  <x:ref>Retry-After</x:ref> = <x:ref>HTTP-date</x:ref> / <x:ref>delta-seconds</x:ref>
     3312</artwork></figure>
     3313<t anchor="rule.delta-seconds">
     3314  <x:anchor-alias value="delta-seconds"/>
     3315   Time spans are non-negative decimal integers, representing time in
     3316   seconds.
     3317</t>
     3318<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="delta-seconds"/>
     3319  <x:ref>delta-seconds</x:ref>  = 1*<x:ref>DIGIT</x:ref>
     3320</artwork></figure>
     3321<t>
     3322   Two examples of its use are
     3323</t>
     3324<figure><artwork type="example">
     3325  Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
     3326  Retry-After: 120
     3327</artwork></figure>
     3328<t>
     3329   In the latter example, the delay is 2 minutes.
     3330</t>
     3331</section>
    24733332</section>
    24743333
     
    24853344  <c>Vary</c> <c>&header-vary;</c>
    24863345</texttable>
     3346
     3347<section title="Date" anchor="header.date">
     3348  <iref primary="true" item="Date header field" x:for-anchor=""/>
     3349  <iref primary="true" item="Header Fields" subitem="Date" x:for-anchor=""/>
     3350  <x:anchor-alias value="Date"/>
     3351<t>
     3352   The "Date" header field represents the date and time at which
     3353   the message was originated, having the same semantics as the Origination
     3354   Date Field (orig-date) defined in <xref target="RFC5322" x:fmt="of" x:sec="3.6.1"/>.
     3355   The field value is an HTTP-date, as defined in <xref target="http.date"/>;
     3356   it &MUST; be sent in rfc1123-date format.
     3357</t>
     3358<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Date"/>
     3359  <x:ref>Date</x:ref> = <x:ref>HTTP-date</x:ref>
     3360</artwork></figure>
     3361<t>
     3362   An example is
     3363</t>
     3364<figure><artwork type="example">
     3365  Date: Tue, 15 Nov 1994 08:12:31 GMT
     3366</artwork></figure>
     3367<t>
     3368   Origin servers &MUST; include a Date header field in all responses,
     3369   except in these cases:
     3370  <list style="numbers">
     3371      <t>If the response status code is <x:ref>100 (Continue)</x:ref> or
     3372         <x:ref>101 (Switching Protocols)</x:ref>, the response &MAY; include a
     3373         Date header field, at the server's option.</t>
     3374
     3375      <t>If the response status code conveys a server error, e.g., <x:ref>500
     3376         (Internal Server Error)</x:ref> or <x:ref>503 (Service Unavailable)</x:ref>,
     3377         and it is inconvenient or impossible to generate a valid Date.</t>
     3378
     3379      <t>If the server does not have a clock that can provide a
     3380         reasonable approximation of the current time, its responses
     3381         &MUST-NOT; include a Date header field.</t>
     3382  </list>
     3383</t>
     3384<t>
     3385   A received message that does not have a Date header field &MUST; be
     3386   assigned one by the recipient if the message will be cached by that
     3387   recipient.
     3388</t>
     3389<t>
     3390   Clients can use the Date header field as well; in order to keep request
     3391   messages small, they are advised not to include it when it doesn't convey
     3392   any useful information (as is usually the case for requests that do not
     3393   contain a payload).
     3394</t>
     3395<t>
     3396   The HTTP-date sent in a Date header field &SHOULD-NOT; represent a date and
     3397   time subsequent to the generation of the message. It &SHOULD; represent
     3398   the best available approximation of the date and time of message
     3399   generation, unless the implementation has no means of generating a
     3400   reasonably accurate date and time. In theory, the date ought to
     3401   represent the moment just before the payload is generated. In
     3402   practice, the date can be generated at any time during the message
     3403   origination without affecting its semantic value.
     3404</t>
     3405</section>
    24873406</section>
    24883407
     
    24903409<t>
    24913410   Authentication challenges indicate what mechanisms are available for the
    2492    user or client to provide authentication credentials in future requests.
     3411   client to provide authentication credentials in future requests.
    24933412</t>
    24943413<texttable align="left">
     
    25123431  <c>Server</c> <c><xref target="header.server"/></c>
    25133432</texttable>
     3433
     3434<section title="Allow" anchor="header.allow">
     3435  <iref primary="true" item="Allow header field" x:for-anchor=""/>
     3436  <iref primary="true" item="Header Fields" subitem="Allow" x:for-anchor=""/>
     3437  <x:anchor-alias value="Allow"/>
     3438<t>
     3439   The "Allow" header field lists the set of methods advertised as
     3440   supported by the target resource. The purpose of this field is strictly to
     3441   inform the recipient of valid request methods associated with the resource.
     3442</t>
     3443<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Allow"/>
     3444  <x:ref>Allow</x:ref> = #<x:ref>method</x:ref>
     3445</artwork></figure>
     3446<t>
     3447   Example of use:
     3448</t>
     3449<figure><artwork type="example">
     3450  Allow: GET, HEAD, PUT
     3451</artwork></figure>
     3452<t>
     3453   The actual set of allowed methods is defined by the origin server at the
     3454   time of each request.
     3455</t>
     3456<t>
     3457   A proxy &MUST-NOT; modify the Allow header field &mdash; it does not need to
     3458   understand all the methods specified in order to handle them according to
     3459   the generic message handling rules.
     3460</t>
     3461</section>
     3462
     3463<section title="Server" anchor="header.server">
     3464  <iref primary="true" item="Server header field" x:for-anchor=""/>
     3465  <iref primary="true" item="Header Fields" subitem="Server" x:for-anchor=""/>
     3466  <x:anchor-alias value="Server"/>
     3467<t>
     3468   The "Server" header field contains information about the
     3469   software used by the origin server to handle the request.
     3470</t>
     3471<t>
     3472   The field can contain multiple
     3473   product tokens (<xref target="product.tokens"/>) and
     3474   comments (&header-fields;) identifying the server and any significant
     3475   subproducts. The product tokens are listed in order of their significance
     3476   for identifying the application.
     3477</t>
     3478<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Server"/>
     3479  <x:ref>Server</x:ref> = <x:ref>product</x:ref> *( <x:ref>RWS</x:ref> ( <x:ref>product</x:ref> / <x:ref>comment</x:ref> ) )
     3480</artwork></figure>
     3481<t>
     3482   Example:
     3483</t>
     3484<figure><artwork type="example">
     3485  Server: CERN/3.0 libwww/2.17
     3486</artwork></figure>
     3487<t>
     3488   If the response is being forwarded through a proxy, the proxy application
     3489   &MUST-NOT; modify the <x:ref>Server</x:ref> header field. Instead, it
     3490   &MUST; include a <x:ref>Via</x:ref> field (as described in &header-via;).
     3491</t>
     3492<x:note>
     3493  <t>
     3494    &Note; Revealing the specific software version of the server might
     3495    allow the server machine to become more vulnerable to attacks
     3496    against software that is known to contain security holes. Server
     3497    implementers are encouraged to make this field a configurable
     3498    option.
     3499  </t>
     3500</x:note>
     3501</section>
    25143502</section>
    25153503</section>
     
    29203908   See <xref target="RFC5646"/> for further information.
    29213909</t>
    2922 </section>
    2923 </section>
    2924 
    2925 <section title="Header Field Definitions" anchor="header.field.definitions">
    2926 <t>
    2927    This section defines the syntax and semantics of HTTP/1.1 header fields
    2928    related to request and response semantics and to the payload of messages.
    2929 </t>
    2930 
    2931 
    2932 <section title="Accept" anchor="header.accept">
    2933   <iref primary="true" item="Accept header field" x:for-anchor=""/>
    2934   <iref primary="true" item="Header Fields" subitem="Accept" x:for-anchor=""/>
    2935   <x:anchor-alias value="Accept"/>
    2936   <x:anchor-alias value="accept-ext"/>
    2937   <x:anchor-alias value="accept-params"/>
    2938   <x:anchor-alias value="media-range"/>
    2939 <t>
    2940    The "Accept" header field can be used by user agents to specify
    2941    response media types that are acceptable. Accept header fields can be used to
    2942    indicate that the request is specifically limited to a small set of desired
    2943    types, as in the case of a request for an in-line image.
    2944 </t>
    2945 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Accept"/><iref primary="true" item="Grammar" subitem="media-range"/><iref primary="true" item="Grammar" subitem="accept-params"/><iref primary="true" item="Grammar" subitem="accept-ext"/>
    2946   <x:ref>Accept</x:ref> = #( <x:ref>media-range</x:ref> [ <x:ref>accept-params</x:ref> ] )
    2947  
    2948   <x:ref>media-range</x:ref>    = ( "*/*"
    2949                    / ( <x:ref>type</x:ref> "/" "*" )
    2950                    / ( <x:ref>type</x:ref> "/" <x:ref>subtype</x:ref> )
    2951                    ) *( <x:ref>OWS</x:ref> ";" <x:ref>OWS</x:ref> <x:ref>parameter</x:ref> )
    2952   <x:ref>accept-params</x:ref>  = <x:ref>weight</x:ref> *( <x:ref>accept-ext</x:ref> )
    2953   <x:ref>accept-ext</x:ref>     = <x:ref>OWS</x:ref> ";" <x:ref>OWS</x:ref> <x:ref>token</x:ref> [ "=" <x:ref>word</x:ref> ]
    2954 </artwork></figure>
    2955 <t>
    2956    The asterisk "*" character is used to group media types into ranges,
    2957    with "*/*" indicating all media types and "type/*" indicating all
    2958    subtypes of that type. The media-range &MAY; include media type
    2959    parameters that are applicable to that range.
    2960 </t>
    2961 <t>
    2962    Each media-range &MAY; be followed by one or more accept-params,
    2963    beginning with the "q" parameter for indicating a relative weight,
    2964    as defined in &qvalue;.
    2965    The first "q" parameter (if any) separates the media-range
    2966    parameter(s) from the accept-params.
    2967 </t>
    2968 <x:note>
    2969   <t>
    2970     &Note; Use of the "q" parameter name to separate media type
    2971     parameters from Accept extension parameters is due to historical
    2972     practice. Although this prevents any media type parameter named
    2973     "q" from being used with a media range, such an event is believed
    2974     to be unlikely given the lack of any "q" parameters in the IANA
    2975     media type registry and the rare usage of any media type
    2976     parameters in Accept. Future media types are discouraged from
    2977     registering any parameter named "q".
    2978   </t>
    2979 </x:note>
    2980 <t>
    2981    The example
    2982 </t>
    2983 <figure><artwork type="example">
    2984   Accept: audio/*; q=0.2, audio/basic
    2985 </artwork></figure>
    2986 <t>
    2987    &SHOULD; be interpreted as "I prefer audio/basic, but send me any audio
    2988    type if it is the best available after an 80% mark-down in quality".
    2989 </t>
    2990 <t>
    2991    A request without any Accept header field implies that the user agent
    2992    will accept any media type in response.
    2993    If an Accept header field is present in a request and none of the
    2994    available representations for the response have a media type that is
    2995    listed as acceptable, the origin server &MAY; either honor the Accept
    2996    header field by sending a <x:ref>406 (Not Acceptable)</x:ref> response
    2997    or disregard the Accept header field by treating the response as if
    2998    it is not subject to content negotiation.
    2999 </t>
    3000 <t>
    3001    A more elaborate example is
    3002 </t>
    3003 <figure><artwork type="example">
    3004   Accept: text/plain; q=0.5, text/html,
    3005           text/x-dvi; q=0.8, text/x-c
    3006 </artwork></figure>
    3007 <t>
    3008    Verbally, this would be interpreted as "text/html and text/x-c are
    3009    the preferred media types, but if they do not exist, then send the
    3010    text/x-dvi representation, and if that does not exist, send the text/plain
    3011    representation".
    3012 </t>
    3013 <t>
    3014    Media ranges can be overridden by more specific media ranges or
    3015    specific media types. If more than one media range applies to a given
    3016    type, the most specific reference has precedence. For example,
    3017 </t>
    3018 <figure><artwork type="example">
    3019   Accept: text/*, text/plain, text/plain;format=flowed, */*
    3020 </artwork></figure>
    3021 <t>
    3022    have the following precedence:
    3023    <list style="numbers">
    3024     <t>text/plain;format=flowed</t>
    3025     <t>text/plain</t>
    3026     <t>text/*</t>
    3027     <t>*/*</t>
    3028    </list>
    3029 </t>
    3030 <t>
    3031    The media type quality factor associated with a given type is
    3032    determined by finding the media range with the highest precedence
    3033    which matches that type. For example,
    3034 </t>
    3035 <figure><artwork type="example">
    3036   Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,
    3037           text/html;level=2;q=0.4, */*;q=0.5
    3038 </artwork></figure>
    3039 <t>
    3040    would cause the following values to be associated:
    3041 </t>
    3042 <texttable align="left">
    3043   <ttcol>Media Type</ttcol><ttcol>Quality Value</ttcol>
    3044   <c>text/html;level=1</c>    <c>1</c>
    3045   <c>text/html</c>            <c>0.7</c>
    3046   <c>text/plain</c>           <c>0.3</c>
    3047   <c>image/jpeg</c>           <c>0.5</c>
    3048   <c>text/html;level=2</c>    <c>0.4</c>
    3049   <c>text/html;level=3</c>    <c>0.7</c>
    3050 </texttable>
    3051 <t>
    3052    &Note; A user agent might be provided with a default set of quality
    3053    values for certain media ranges. However, unless the user agent is
    3054    a closed system which cannot interact with other rendering agents,
    3055    this default set ought to be configurable by the user.
    3056 </t>
    3057 </section>
    3058 
    3059 <section title="Accept-Charset" anchor="header.accept-charset">
    3060   <iref primary="true" item="Accept-Charset header field" x:for-anchor=""/>
    3061   <iref primary="true" item="Header Fields" subitem="Accept-Charset" x:for-anchor=""/>
    3062   <x:anchor-alias value="Accept-Charset"/>
    3063 <t>
    3064    The "Accept-Charset" header field can be used by user agents to
    3065    indicate what character encodings are acceptable in a response
    3066    payload. This field allows
    3067    clients capable of understanding more comprehensive or special-purpose
    3068    character encodings to signal that capability to a server which is capable of
    3069    representing documents in those character encodings.
    3070 </t>
    3071 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Accept-Charset"/>
    3072   <x:ref>Accept-Charset</x:ref> = 1#( ( <x:ref>charset</x:ref> / "*" ) [ <x:ref>weight</x:ref> ] )
    3073 </artwork></figure>
    3074 <t>
    3075    Character encoding values (a.k.a., charsets) are described in
    3076    <xref target="character.sets"/>. Each charset &MAY; be given an
    3077    associated quality value which represents the user's preference
    3078    for that charset, as defined in &qvalue;.
    3079    An example is
    3080 </t>
    3081 <figure><artwork type="example">
    3082   Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
    3083 </artwork></figure>
    3084 <t>
    3085    The special value "*", if present in the Accept-Charset field,
    3086    matches every character encoding which is not mentioned elsewhere in the
    3087    Accept-Charset field. If no "*" is present in an Accept-Charset field,
    3088    then any character encodings not explicitly mentioned in the field are
    3089    considered "not acceptable" to the client.
    3090 </t>
    3091 <t>
    3092    A request without any Accept-Charset header field implies that the user
    3093    agent will accept any character encoding in response.
    3094 </t>
    3095 <t>
    3096    If an Accept-Charset header field is present in a request and none of the
    3097    available representations for the response have a character encoding that
    3098    is listed as acceptable, the origin server &MAY; either honor the
    3099    Accept-Charset header field by sending a <x:ref>406 (Not Acceptable)</x:ref> response or
    3100    disregard the Accept-Charset header field by treating the response as if
    3101    it is not subject to content negotiation.
    3102 </t>
    3103 </section>
    3104 
    3105 <section title="Accept-Encoding" anchor="header.accept-encoding">
    3106   <iref primary="true" item="Accept-Encoding header field" x:for-anchor=""/>
    3107   <iref primary="true" item="Header Fields" subitem="Accept-Encoding" x:for-anchor=""/>
    3108   <x:anchor-alias value="Accept-Encoding"/>
    3109   <x:anchor-alias value="codings"/>
    3110 <t>
    3111    The "Accept-Encoding" header field can be used by user agents to
    3112    indicate what response content-codings (<xref target="content.codings"/>)
    3113    are acceptable in the response.  An "identity" token is used as a synonym
    3114    for "no encoding" in order to communicate when no encoding is preferred.
    3115 </t>
    3116 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Accept-Encoding"/><iref primary="true" item="Grammar" subitem="codings"/>
    3117   <x:ref>Accept-Encoding</x:ref>  = #( <x:ref>codings</x:ref> [ <x:ref>weight</x:ref> ] )
    3118   <x:ref>codings</x:ref>          = <x:ref>content-coding</x:ref> / "identity" / "*"
    3119 </artwork></figure>
    3120 <t>
    3121    Each codings value &MAY; be given an associated quality value which
    3122    represents the preference for that encoding, as defined in &qvalue;.
    3123 </t>
    3124 <t>
    3125    For example,
    3126 </t>
    3127 <figure><artwork type="example">
    3128   Accept-Encoding: compress, gzip
    3129   Accept-Encoding:
    3130   Accept-Encoding: *
    3131   Accept-Encoding: compress;q=0.5, gzip;q=1.0
    3132   Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0
    3133 </artwork></figure>
    3134 <t>
    3135    A server tests whether a content-coding for a given representation is
    3136    acceptable, according to an Accept-Encoding field, using these rules:
    3137   <list style="numbers">
    3138       <t>The special "*" symbol in an Accept-Encoding field matches any
    3139          available content-coding not explicitly listed in the header
    3140          field.</t>
    3141 
    3142       <t>If the representation has no content-coding, then it is acceptable
    3143          by default unless specifically excluded by the Accept-Encoding field
    3144          stating either "identity;q=0" or "*;q=0" without a more specific
    3145          entry for "identity".</t>
    3146 
    3147       <t>If the representation's content-coding is one of the content-codings
    3148          listed in the Accept-Encoding field, then it is acceptable unless
    3149          it is accompanied by a qvalue of 0. (As defined in &qvalue;, a
    3150          qvalue of 0 means "not acceptable".)</t>
    3151 
    3152       <t>If multiple content-codings are acceptable, then the acceptable
    3153          content-coding with the highest non-zero qvalue is preferred.</t>
    3154   </list>
    3155 </t>
    3156 <t>
    3157    An Accept-Encoding header field with a combined field-value that is empty
    3158    implies that the user agent does not want any content-coding in response.
    3159    If an Accept-Encoding header field is present in a request and none of the
    3160    available representations for the response have a content-coding that
    3161    is listed as acceptable, the origin server &SHOULD; send a response
    3162    without any content-coding.
    3163 </t>
    3164 <t>
    3165    A request without an Accept-Encoding header field implies that the user
    3166    agent will accept any content-coding in response.
    3167 </t>
    3168 <x:note>
    3169   <t>
    3170     &Note; Most HTTP/1.0 applications do not recognize or obey qvalues
    3171     associated with content-codings. This means that qvalues will not
    3172     work and are not permitted with x-gzip or x-compress.
    3173   </t>
    3174 </x:note>
    3175 </section>
    3176 
    3177 <section title="Accept-Language" anchor="header.accept-language">
    3178   <iref primary="true" item="Accept-Language header field" x:for-anchor=""/>
    3179   <iref primary="true" item="Header Fields" subitem="Accept-Language" x:for-anchor=""/>
    3180   <x:anchor-alias value="Accept-Language"/>
    3181   <x:anchor-alias value="language-range"/>
    3182 <t>
    3183    The "Accept-Language" header field can be used by user agents to
    3184    indicate the set of natural languages that are preferred in the response.
    3185    Language tags are defined in <xref target="language.tags"/>.
    3186 </t>
    3187 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Accept-Language"/><iref primary="true" item="Grammar" subitem="language-range"/>
    3188   <x:ref>Accept-Language</x:ref> = 1#( <x:ref>language-range</x:ref> [ <x:ref>weight</x:ref> ] )
    3189   <x:ref>language-range</x:ref>  =
    3190             &lt;language-range, defined in <xref target="RFC4647" x:fmt="," x:sec="2.1"/>&gt;
    3191 </artwork></figure>
    3192 <t>
    3193    Each language-range can be given an associated quality value which
    3194    represents an estimate of the user's preference for the languages
    3195    specified by that range, as defined in &qvalue;. For example,
    3196 </t>
    3197 <figure><artwork type="example">
    3198   Accept-Language: da, en-gb;q=0.8, en;q=0.7
    3199 </artwork></figure>
    3200 <t>
    3201    would mean: "I prefer Danish, but will accept British English and
    3202    other types of English".
    3203    (see also <xref target="RFC4647" x:sec="2.3" x:fmt="of"/>)
    3204 </t>
    3205 <t>
    3206    For matching, <xref target="RFC4647" x:sec="3" x:fmt="of"/> defines
    3207    several matching schemes. Implementations can offer the most appropriate
    3208    matching scheme for their requirements.
    3209 </t>
    3210 <x:note>
    3211   <t>
    3212     &Note; The "Basic Filtering" scheme (<xref target="RFC4647"
    3213     x:fmt="," x:sec="3.3.1"/>) is identical to the matching scheme that was
    3214     previously defined in <xref target="RFC2616" x:fmt="of" x:sec="14.4"/>.
    3215   </t>
    3216 </x:note>
    3217 <t>
    3218    It might be contrary to the privacy expectations of the user to send
    3219    an Accept-Language header field with the complete linguistic preferences of
    3220    the user in every request. For a discussion of this issue, see
    3221    <xref target="privacy.issues.connected.to.accept.header.fields"/>.
    3222 </t>
    3223 <t>
    3224    As intelligibility is highly dependent on the individual user, it is
    3225    recommended that client applications make the choice of linguistic
    3226    preference available to the user. If the choice is not made
    3227    available, then the Accept-Language header field &MUST-NOT; be given in
    3228    the request.
    3229 </t>
    3230 <x:note>
    3231   <t>
    3232     &Note; When making the choice of linguistic preference available to
    3233     the user, we remind implementers of  the fact that users are not
    3234     familiar with the details of language matching as described above,
    3235     and ought to be provided appropriate guidance. As an example, users
    3236     might assume that on selecting "en-gb", they will be served any
    3237     kind of English document if British English is not available. A
    3238     user agent might suggest in such a case to add "en" to get the
    3239     best matching behavior.
    3240   </t>
    3241 </x:note>
    3242 </section>
    3243 
    3244 <section title="Allow" anchor="header.allow">
    3245   <iref primary="true" item="Allow header field" x:for-anchor=""/>
    3246   <iref primary="true" item="Header Fields" subitem="Allow" x:for-anchor=""/>
    3247   <x:anchor-alias value="Allow"/>
    3248 <t>
    3249    The "Allow" header field lists the set of methods advertised as
    3250    supported by the target resource. The purpose of this field is strictly to
    3251    inform the recipient of valid request methods associated with the resource.
    3252 </t>
    3253 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Allow"/>
    3254   <x:ref>Allow</x:ref> = #<x:ref>method</x:ref>
    3255 </artwork></figure>
    3256 <t>
    3257    Example of use:
    3258 </t>
    3259 <figure><artwork type="example">
    3260   Allow: GET, HEAD, PUT
    3261 </artwork></figure>
    3262 <t>
    3263    The actual set of allowed methods is defined by the origin server at the
    3264    time of each request.
    3265 </t>
    3266 <t>
    3267    A proxy &MUST-NOT; modify the Allow header field &mdash; it does not need to
    3268    understand all the methods specified in order to handle them according to
    3269    the generic message handling rules.
    3270 </t>
    3271 </section>
    3272 
    3273 
    3274 <section title="Content-Encoding" anchor="header.content-encoding">
    3275   <iref primary="true" item="Content-Encoding header field" x:for-anchor=""/>
    3276   <iref primary="true" item="Header Fields" subitem="Content-Encoding" x:for-anchor=""/>
    3277   <x:anchor-alias value="Content-Encoding"/>
    3278 <t>
    3279    The "Content-Encoding" header field indicates what content-codings
    3280    have been applied to the representation beyond those inherent in the media
    3281    type, and thus what decoding mechanisms have to be applied in order to obtain
    3282    the media-type referenced by the <x:ref>Content-Type</x:ref> header field.
    3283    Content-Encoding is primarily used to allow a representation to be
    3284    compressed without losing the identity of its underlying media type.
    3285 </t>
    3286 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Encoding"/>
    3287   <x:ref>Content-Encoding</x:ref> = 1#<x:ref>content-coding</x:ref>
    3288 </artwork></figure>
    3289 <t>
    3290    Content codings are defined in <xref target="content.codings"/>. An example of its use is
    3291 </t>
    3292 <figure><artwork type="example">
    3293   Content-Encoding: gzip
    3294 </artwork></figure>
    3295 <t>
    3296    The content-coding is a characteristic of the representation.
    3297    Typically, the representation body is stored with this
    3298    encoding and is only decoded before rendering or analogous usage.
    3299    However, a transforming proxy &MAY; modify the content-coding if the
    3300    new coding is known to be acceptable to the recipient, unless the
    3301    "no-transform" cache-control directive is present in the message.
    3302 </t>
    3303 <t>
    3304    If the media type includes an inherent encoding, such as a data format
    3305    that is always compressed, then that encoding would not be restated as
    3306    a Content-Encoding even if it happens to be the same algorithm as one
    3307    of the content-codings.  Such a content-coding would only be listed if,
    3308    for some bizarre reason, it is applied a second time to form the
    3309    representation.  Likewise, an origin server might choose to publish the
    3310    same payload data as multiple representations that differ only in whether
    3311    the coding is defined as part of <x:ref>Content-Type</x:ref> or
    3312    Content-Encoding, since some user agents will behave differently in their
    3313    handling of each response (e.g., open a "Save as ..." dialog instead of
    3314    automatic decompression and rendering of content).
    3315 </t>
    3316 <t>
    3317    A representation that has a content-coding applied to it &MUST; include
    3318    a Content-Encoding header field that lists the content-coding(s) applied.
    3319 </t>
    3320 <t>
    3321    If multiple encodings have been applied to a representation, the content
    3322    codings &MUST; be listed in the order in which they were applied.
    3323    Additional information about the encoding parameters &MAY; be provided
    3324    by other header fields not defined by this specification.
    3325 </t>
    3326 <t>
    3327    If the content-coding of a representation in a request message is not
    3328    acceptable to the origin server, the server &SHOULD; respond with a
    3329    status code of 415 (Unsupported Media Type).
    3330 </t>
    3331 </section>
    3332 
    3333 <section title="Content-Language" anchor="header.content-language">
    3334   <iref primary="true" item="Content-Language header field" x:for-anchor=""/>
    3335   <iref primary="true" item="Header Fields" subitem="Content-Language" x:for-anchor=""/>
    3336   <x:anchor-alias value="Content-Language"/>
    3337 <t>
    3338    The "Content-Language" header field describes the natural
    3339    language(s) of the intended audience for the representation. Note that this might
    3340    not be equivalent to all the languages used within the representation.
    3341 </t>
    3342 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Language"/>
    3343   <x:ref>Content-Language</x:ref> = 1#<x:ref>language-tag</x:ref>
    3344 </artwork></figure>
    3345 <t>
    3346    Language tags are defined in <xref target="language.tags"/>. The primary purpose of
    3347    Content-Language is to allow a user to identify and differentiate
    3348    representations according to the user's own preferred language. Thus, if the
    3349    body content is intended only for a Danish-literate audience, the
    3350    appropriate field is
    3351 </t>
    3352 <figure><artwork type="example">
    3353   Content-Language: da
    3354 </artwork></figure>
    3355 <t>
    3356    If no Content-Language is specified, the default is that the content
    3357    is intended for all language audiences. This might mean that the
    3358    sender does not consider it to be specific to any natural language,
    3359    or that the sender does not know for which language it is intended.
    3360 </t>
    3361 <t>
    3362    Multiple languages &MAY; be listed for content that is intended for
    3363    multiple audiences. For example, a rendition of the "Treaty of
    3364    Waitangi", presented simultaneously in the original Maori and English
    3365    versions, would call for
    3366 </t>
    3367 <figure><artwork type="example">
    3368   Content-Language: mi, en
    3369 </artwork></figure>
    3370 <t>
    3371    However, just because multiple languages are present within a representation
    3372    does not mean that it is intended for multiple linguistic audiences.
    3373    An example would be a beginner's language primer, such as "A First
    3374    Lesson in Latin", which is clearly intended to be used by an
    3375    English-literate audience. In this case, the Content-Language would
    3376    properly only include "en".
    3377 </t>
    3378 <t>
    3379    Content-Language &MAY; be applied to any media type &mdash; it is not
    3380    limited to textual documents.
    3381 </t>
    3382 </section>
    3383 
    3384 <section title="Content-Location" anchor="header.content-location">
    3385   <iref primary="true" item="Content-Location header field" x:for-anchor=""/>
    3386   <iref primary="true" item="Header Fields" subitem="Content-Location" x:for-anchor=""/>
    3387   <x:anchor-alias value="Content-Location"/>
    3388 <t>
    3389    The "Content-Location" header field supplies a URI that can be used
    3390    as a specific identifier for the representation in this message.
    3391    In other words, if one were to perform a GET on this URI at the time
    3392    of this message's generation, then a <x:ref>200 (OK)</x:ref> response would
    3393    contain the same representation that is enclosed as payload in this message.
    3394 </t>
    3395 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Location"/>
    3396   <x:ref>Content-Location</x:ref> = <x:ref>absolute-URI</x:ref> / <x:ref>partial-URI</x:ref>
    3397 </artwork></figure>
    3398 <t>
    3399    The Content-Location value is not a replacement for the effective
    3400    Request URI (&effective-request-uri;).  It is representation metadata.
    3401    It has the same syntax and semantics as the header field of the same name
    3402    defined for MIME body parts in <xref target="RFC2557" x:fmt="of" x:sec="4"/>.
    3403    However, its appearance in an HTTP message has some special implications
    3404    for HTTP recipients.
    3405 </t>
    3406 <t>
    3407    If Content-Location is included in a response message and its value
    3408    is the same as the effective request URI, then the response payload
    3409    &SHOULD; be considered a current representation of that resource.
    3410    For a GET or HEAD request, this is the same as the default semantics
    3411    when no Content-Location is provided by the server.  For a state-changing
    3412    request like PUT or POST, it implies that the server's response contains
    3413    the new representation of that resource, thereby distinguishing it from
    3414    representations that might only report about the action (e.g., "It worked!").
    3415    This allows authoring applications to update their local copies without
    3416    the need for a subsequent GET request.
    3417 </t>
    3418 <t>
    3419    If Content-Location is included in a response message and its value
    3420    differs from the effective request URI, then the origin server is
    3421    informing recipients that this representation has its own, presumably
    3422    more specific, identifier.  For a GET or HEAD request, this is an
    3423    indication that the effective request URI identifies a resource that
    3424    is subject to content negotiation and the selected representation for
    3425    this response can also be found at the identified URI.  For other
    3426    methods, such a Content-Location indicates that this representation
    3427    contains a report on the action's status and the same report is
    3428    available (for future access with GET) at the given URI.  For
    3429    example, a purchase transaction made via a POST request might
    3430    include a receipt document as the payload of the <x:ref>200 (OK)</x:ref>
    3431    response; the Content-Location value provides an identifier for retrieving
    3432    a copy of that same receipt in the future.
    3433 </t>
    3434 <t>
    3435    If Content-Location is included in a request message, then it &MAY;
    3436    be interpreted by the origin server as an indication of where the
    3437    user agent originally obtained the content of the enclosed
    3438    representation (prior to any subsequent modification of the content
    3439    by that user agent).  In other words, the user agent is providing
    3440    the same representation metadata that it received with the original
    3441    representation.  However, such interpretation &MUST-NOT; be used to
    3442    alter the semantics of the method requested by the client.  For
    3443    example, if a client makes a PUT request on a negotiated resource
    3444    and the origin server accepts that PUT (without redirection), then the
    3445    new set of values for that resource is expected to be consistent with
    3446    the one representation supplied in that PUT; the Content-Location
    3447    cannot be used as a form of reverse content selection that
    3448    identifies only one of the negotiated representations to be updated.
    3449    If the user agent had wanted the latter semantics, it would have applied
    3450    the PUT directly to the Content-Location URI.
    3451 </t>
    3452 <t>
    3453    A Content-Location field received in a request message is transitory
    3454    information that &SHOULD-NOT; be saved with other representation
    3455    metadata for use in later responses.  The Content-Location's value
    3456    might be saved for use in other contexts, such as within source links
    3457    or other metadata.
    3458 </t>
    3459 <t>
    3460    A cache cannot assume that a representation with a Content-Location
    3461    different from the URI used to retrieve it can be used to respond to
    3462    later requests on that Content-Location URI.
    3463 </t>
    3464 <t>
    3465    If the Content-Location value is a partial URI, the partial URI is
    3466    interpreted relative to the effective request URI.
    3467 </t>
    3468 </section>
    3469 
    3470 <section title="Content-Type" anchor="header.content-type">
    3471   <iref primary="true" item="Content-Type header field" x:for-anchor=""/>
    3472   <iref primary="true" item="Header Fields" subitem="Content-Type" x:for-anchor=""/>
    3473   <x:anchor-alias value="Content-Type"/>
    3474 <t>
    3475    The "Content-Type" header field indicates the media type of the
    3476    representation. In the case of responses to the HEAD method, the media type is
    3477    that which would have been sent had the request been a GET.
    3478 </t>
    3479 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Type"/>
    3480   <x:ref>Content-Type</x:ref> = <x:ref>media-type</x:ref>
    3481 </artwork></figure>
    3482 <t>
    3483    Media types are defined in <xref target="media.types"/>. An example of the field is
    3484 </t>
    3485 <figure><artwork type="example">
    3486   Content-Type: text/html; charset=ISO-8859-4
    3487 </artwork></figure>
    3488 <t>
    3489    Further discussion of Content-Type is provided in <xref target="representation.data"/>.
    3490 </t>
    3491 </section>
    3492 
    3493 <section title="Date" anchor="header.date">
    3494   <iref primary="true" item="Date header field" x:for-anchor=""/>
    3495   <iref primary="true" item="Header Fields" subitem="Date" x:for-anchor=""/>
    3496   <x:anchor-alias value="Date"/>
    3497 <t>
    3498    The "Date" header field represents the date and time at which
    3499    the message was originated, having the same semantics as the Origination
    3500    Date Field (orig-date) defined in <xref target="RFC5322" x:fmt="of" x:sec="3.6.1"/>.
    3501    The field value is an HTTP-date, as defined in <xref target="http.date"/>;
    3502    it &MUST; be sent in rfc1123-date format.
    3503 </t>
    3504 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Date"/>
    3505   <x:ref>Date</x:ref> = <x:ref>HTTP-date</x:ref>
    3506 </artwork></figure>
    3507 <t>
    3508    An example is
    3509 </t>
    3510 <figure><artwork type="example">
    3511   Date: Tue, 15 Nov 1994 08:12:31 GMT
    3512 </artwork></figure>
    3513 <t>
    3514    Origin servers &MUST; include a Date header field in all responses,
    3515    except in these cases:
    3516   <list style="numbers">
    3517       <t>If the response status code is <x:ref>100 (Continue)</x:ref> or
    3518          <x:ref>101 (Switching Protocols)</x:ref>, the response &MAY; include a
    3519          Date header field, at the server's option.</t>
    3520 
    3521       <t>If the response status code conveys a server error, e.g., <x:ref>500
    3522          (Internal Server Error)</x:ref> or <x:ref>503 (Service Unavailable)</x:ref>,
    3523          and it is inconvenient or impossible to generate a valid Date.</t>
    3524 
    3525       <t>If the server does not have a clock that can provide a
    3526          reasonable approximation of the current time, its responses
    3527          &MUST-NOT; include a Date header field.</t>
    3528   </list>
    3529 </t>
    3530 <t>
    3531    A received message that does not have a Date header field &MUST; be
    3532    assigned one by the recipient if the message will be cached by that
    3533    recipient.
    3534 </t>
    3535 <t>
    3536    Clients can use the Date header field as well; in order to keep request
    3537    messages small, they are advised not to include it when it doesn't convey
    3538    any useful information (as is usually the case for requests that do not
    3539    contain a payload).
    3540 </t>
    3541 <t>
    3542    The HTTP-date sent in a Date header field &SHOULD-NOT; represent a date and
    3543    time subsequent to the generation of the message. It &SHOULD; represent
    3544    the best available approximation of the date and time of message
    3545    generation, unless the implementation has no means of generating a
    3546    reasonably accurate date and time. In theory, the date ought to
    3547    represent the moment just before the payload is generated. In
    3548    practice, the date can be generated at any time during the message
    3549    origination without affecting its semantic value.
    3550 </t>
    3551 </section>
    3552 
    3553 <section title="Expect" anchor="header.expect">
    3554   <iref primary="true" item="Expect header field" x:for-anchor=""/>
    3555   <iref primary="true" item="Header Fields" subitem="Expect" x:for-anchor=""/>
    3556   <x:anchor-alias value="Expect"/>
    3557   <x:anchor-alias value="expectation"/>
    3558   <x:anchor-alias value="expect-param"/>
    3559   <x:anchor-alias value="expect-name"/>
    3560   <x:anchor-alias value="expect-value"/>
    3561 <t>
    3562    The "Expect" header field is used to indicate that particular
    3563    server behaviors are required by the client.
    3564 </t>
    3565 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Expect"/><iref primary="true" item="Grammar" subitem="expectation"/><iref primary="true" item="Grammar" subitem="expect-param"/><iref primary="true" item="Grammar" subitem="expect-value"/><iref primary="true" item="Grammar" subitem="expect-name"/>
    3566   <x:ref>Expect</x:ref>       = 1#<x:ref>expectation</x:ref>
    3567  
    3568   <x:ref>expectation</x:ref>  = <x:ref>expect-name</x:ref> [ <x:ref>BWS</x:ref> "=" <x:ref>BWS</x:ref> <x:ref>expect-value</x:ref> ]
    3569                              *( <x:ref>OWS</x:ref> ";" [ <x:ref>OWS</x:ref> <x:ref>expect-param</x:ref> ] )
    3570   <x:ref>expect-param</x:ref> = <x:ref>expect-name</x:ref> [ <x:ref>BWS</x:ref> "=" <x:ref>BWS</x:ref> <x:ref>expect-value</x:ref> ]
    3571  
    3572   <x:ref>expect-name</x:ref>  = <x:ref>token</x:ref>
    3573   <x:ref>expect-value</x:ref> = <x:ref>token</x:ref> / <x:ref>quoted-string</x:ref>
    3574 </artwork></figure>
    3575 <t>
    3576    If all received Expect header field(s) are syntactically valid but contain
    3577    an expectation that the recipient does not understand or cannot comply with,
    3578    the recipient &MUST; respond with a <x:ref>417 (Expectation Failed)</x:ref> status code. A
    3579    recipient of a syntactically invalid Expectation header field &MUST; respond
    3580    with a <x:ref>4xx</x:ref> status code other than 417.
    3581 </t>
    3582 <t>
    3583    The only expectation defined by this specification is:
    3584 </t>
    3585 <t><iref primary="true" item="100-continue (expect value)"/><iref primary="true" item="Expect Values" subitem="100-continue"/>
    3586   100-continue
    3587    <list>
    3588       <t>
    3589         The "100-continue" expectation is defined &use100;. It does not support
    3590         any expect-params.
    3591       </t>
    3592    </list>
    3593 </t>
    3594 <t>
    3595    Comparison is case-insensitive for names (expect-name), and case-sensitive
    3596    for values (expect-value).
    3597 </t>
    3598 <t>
    3599    The Expect mechanism is hop-by-hop: the above requirements apply to any
    3600    server, including proxies. However, the Expect header field itself is
    3601    end-to-end; it &MUST; be forwarded if the request is forwarded.
    3602 </t>
    3603 <t>
    3604    Many older HTTP/1.0 and HTTP/1.1 applications do not understand the Expect
    3605    header field.
    3606 </t>
    3607 </section>
    3608 
    3609 <section title="From" anchor="header.from">
    3610   <iref primary="true" item="From header field" x:for-anchor=""/>
    3611   <iref primary="true" item="Header Fields" subitem="From" x:for-anchor=""/>
    3612   <x:anchor-alias value="From"/>
    3613   <x:anchor-alias value="mailbox"/>
    3614 <t>
    3615    The "From" header field, if given, &SHOULD; contain an Internet
    3616    e-mail address for the human user who controls the requesting user
    3617    agent. The address &SHOULD; be machine-usable, as defined by "mailbox"
    3618    in <xref x:sec="3.4" x:fmt="of" target="RFC5322"/>:
    3619 </t>
    3620 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="From"/>
    3621   <x:ref>From</x:ref>    = <x:ref>mailbox</x:ref>
    3622  
    3623   <x:ref>mailbox</x:ref> = &lt;mailbox, defined in <xref x:sec="3.4" x:fmt="," target="RFC5322"/>&gt;
    3624 </artwork></figure>
    3625 <t>
    3626    An example is:
    3627 </t>
    3628 <figure><artwork type="example">
    3629   From: webmaster@example.org
    3630 </artwork></figure>
    3631 <t>
    3632    This header field &MAY; be used for logging purposes and as a means for
    3633    identifying the source of invalid or unwanted requests. It &SHOULD-NOT;
    3634    be used as an insecure form of access protection. The interpretation
    3635    of this field is that the request is being performed on behalf of the
    3636    person given, who accepts responsibility for the method performed. In
    3637    particular, robot agents &SHOULD; include this header field so that the
    3638    person responsible for running the robot can be contacted if problems
    3639    occur on the receiving end.
    3640 </t>
    3641 <t>
    3642    The Internet e-mail address in this field &MAY; be separate from the
    3643    Internet host which issued the request. For example, when a request
    3644    is passed through a proxy the original issuer's address &SHOULD; be
    3645    used.
    3646 </t>
    3647 <t>
    3648    The client &SHOULD-NOT;  send the From header field without the user's
    3649    approval, as it might conflict with the user's privacy interests or
    3650    their site's security policy. It is strongly recommended that the
    3651    user be able to disable, enable, and modify the value of this field
    3652    at any time prior to a request.
    3653 </t>
    3654 </section>
    3655 
    3656 <section title="Location" anchor="header.location">
    3657   <iref primary="true" item="Location header field" x:for-anchor=""/>
    3658   <iref primary="true" item="Header Fields" subitem="Location" x:for-anchor=""/>
    3659   <x:anchor-alias value="Location"/>
    3660 <t>
    3661    The "Location" header field &MAY; be sent in responses to refer to
    3662    a specific resource in accordance with the semantics of the status
    3663    code.
    3664 </t>
    3665 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Location"/>
    3666   <x:ref>Location</x:ref> = <x:ref>URI-reference</x:ref>
    3667 </artwork></figure>
    3668 <t>
    3669    For <x:ref>201 (Created)</x:ref> responses, the Location is the URI of the
    3670    new resource which was created by the request. For <x:ref>3xx (Redirection)</x:ref>
    3671    responses, the location &SHOULD; indicate the server's preferred URI for
    3672    automatic redirection to the resource.
    3673 </t>
    3674 <t>
    3675    The field value consists of a single URI-reference. When it has the form
    3676    of a relative reference (<xref target="RFC3986" x:fmt="," x:sec="4.2"/>),
    3677    the final value is computed by resolving it against the effective request
    3678    URI (<xref target="RFC3986" x:fmt="," x:sec="5"/>). If the original URI, as
    3679    navigated to by the user agent, did contain a fragment identifier, and the
    3680    final value does not, then the original URI's fragment identifier is added
    3681    to the final value.
    3682 </t>
    3683 <figure>
    3684 <preamble>For example, the original URI "http://www.example.org/~tim", combined with a field value given as:</preamble><!--DO NOT DARE changing the vertical spacing below, it's necessary this way for xml2rfc-->
    3685 <artwork type="example">
    3686   Location: /pub/WWW/People.html#tim
    3687 </artwork>
    3688 <postamble>would result in a final value of "http://www.example.org/pub/WWW/People.html#tim"</postamble>
    3689 </figure>
    3690 <figure>
    3691 <preamble>An original URI "http://www.example.org/index.html#larry", combined with a field value given as:</preamble><!--DO NOT DARE changing the vertical spacing below, it's necessary this way for xml2rfc-->
    3692 <artwork type="example">
    3693   Location: http://www.example.net/index.html
    3694 </artwork>
    3695 <postamble>would result in a final value of "http://www.example.net/index.html#larry", preserving the original fragment identifier.</postamble>
    3696 </figure>
    3697 <x:note>
    3698   <t>
    3699     &Note; Some recipients attempt to recover from Location fields
    3700     that are not valid URI references. This specification does not mandate or
    3701     define such processing, but does allow it.
    3702   </t>
    3703 </x:note>
    3704 <t>
    3705    There are circumstances in which a fragment identifier in a Location URI
    3706    would not be appropriate. For instance, when it appears in a <x:ref>201
    3707    (Created)</x:ref> response, where the Location header field specifies the
    3708    URI for the entire created resource.
    3709 </t>
    3710 <x:note>
    3711   <t>
    3712     &Note; The <x:ref>Content-Location</x:ref> header field
    3713     (&header-content-location;) differs from Location in that the
    3714     Content-Location identifies the most specific resource corresponding to the
    3715     enclosed representation. It is therefore possible for a response to contain
    3716     header fields for both Location and Content-Location.
    3717   </t>
    3718 </x:note>
    3719 </section>
    3720 
    3721 <section title="Max-Forwards" anchor="header.max-forwards">
    3722   <iref primary="true" item="Max-Forwards header field" x:for-anchor=""/>
    3723   <iref primary="true" item="Header Fields" subitem="Max-Forwards" x:for-anchor=""/>
    3724   <x:anchor-alias value="Max-Forwards"/>
    3725 <t>
    3726    The "Max-Forwards" header field provides a mechanism with the
    3727    TRACE (<xref target="TRACE"/>) and OPTIONS (<xref target="OPTIONS"/>)
    3728    methods to limit the number of times that the request is forwarded by
    3729    proxies. This can be useful when the client is attempting to
    3730    trace a request which appears to be failing or looping mid-chain.
    3731 </t>
    3732 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Max-Forwards"/>
    3733   <x:ref>Max-Forwards</x:ref> = 1*<x:ref>DIGIT</x:ref>
    3734 </artwork></figure>
    3735 <t>
    3736    The Max-Forwards value is a decimal integer indicating the remaining
    3737    number of times this request message can be forwarded.
    3738 </t>
    3739 <t>
    3740    Each recipient of a TRACE or OPTIONS request
    3741    containing a Max-Forwards header field &MUST; check and update its
    3742    value prior to forwarding the request. If the received value is zero
    3743    (0), the recipient &MUST-NOT; forward the request; instead, it &MUST;
    3744    respond as the final recipient. If the received Max-Forwards value is
    3745    greater than zero, then the forwarded message &MUST; contain an updated
    3746    Max-Forwards field with a value decremented by one (1).
    3747 </t>
    3748 <t>
    3749    The Max-Forwards header field &MAY; be ignored for all other request
    3750    methods.
    3751 </t>
    3752 </section>
    3753 
    3754 <section title="Referer" anchor="header.referer">
    3755   <iref primary="true" item="Referer header field" x:for-anchor=""/>
    3756   <iref primary="true" item="Header Fields" subitem="Referer" x:for-anchor=""/>
    3757   <x:anchor-alias value="Referer"/>
    3758 <t>
    3759    The "Referer" [sic] header field allows the client to specify the
    3760    URI of the resource from which the target URI was obtained (the
    3761    "referrer", although the header field is misspelled.).
    3762 </t>
    3763 <t>
    3764    The Referer header field allows servers to generate lists of back-links to
    3765    resources for interest, logging, optimized caching, etc. It also allows
    3766    obsolete or mistyped links to be traced for maintenance. Some servers use
    3767    Referer as a means of controlling where they allow links from (so-called
    3768    "deep linking"), but legitimate requests do not always
    3769    contain a Referer header field.
    3770 </t>
    3771 <t>
    3772    If the target URI was obtained from a source that does not have its own
    3773    URI (e.g., input from the user keyboard), the Referer field &MUST; either be
    3774    sent with the value "about:blank", or not be sent at all. Note that this
    3775    requirement does not apply to sources with non-HTTP URIs (e.g., FTP).
    3776 </t>
    3777 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Referer"/>
    3778   <x:ref>Referer</x:ref> = <x:ref>absolute-URI</x:ref> / <x:ref>partial-URI</x:ref>
    3779 </artwork></figure>
    3780 <t>
    3781    Example:
    3782 </t>
    3783 <figure><artwork type="example">
    3784   Referer: http://www.example.org/hypertext/Overview.html
    3785 </artwork></figure>
    3786 <t>
    3787    If the field value is a relative URI, it &SHOULD; be interpreted
    3788    relative to the effective request URI. The URI &MUST-NOT; include a fragment. See
    3789    <xref target="encoding.sensitive.information.in.uris"/> for security considerations.
    3790 </t>
    3791 </section>
    3792 
    3793 <section title="Retry-After" anchor="header.retry-after">
    3794   <iref primary="true" item="Retry-After header field" x:for-anchor=""/>
    3795   <iref primary="true" item="Header Fields" subitem="Retry-After" x:for-anchor=""/>
    3796   <x:anchor-alias value="Retry-After"/>
    3797 <t>
    3798    The header "Retry-After" field can be used with a <x:ref>503 (Service
    3799    Unavailable)</x:ref> response to indicate how long the service is expected to
    3800    be unavailable to the requesting client. This field &MAY; also be used
    3801    with any <x:ref>3xx (Redirection)</x:ref> response to indicate the minimum time the
    3802    user-agent is asked to wait before issuing the redirected request.
    3803 </t>
    3804 <t>
    3805    The value of this field can be either an HTTP-date or an integer number
    3806    of seconds (in decimal) after the time of the response.
    3807 </t>
    3808 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Retry-After"/>
    3809   <x:ref>Retry-After</x:ref> = <x:ref>HTTP-date</x:ref> / <x:ref>delta-seconds</x:ref>
    3810 </artwork></figure>
    3811 <t anchor="rule.delta-seconds">
    3812   <x:anchor-alias value="delta-seconds"/>
    3813    Time spans are non-negative decimal integers, representing time in
    3814    seconds.
    3815 </t>
    3816 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="delta-seconds"/>
    3817   <x:ref>delta-seconds</x:ref>  = 1*<x:ref>DIGIT</x:ref>
    3818 </artwork></figure>
    3819 <t>
    3820    Two examples of its use are
    3821 </t>
    3822 <figure><artwork type="example">
    3823   Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
    3824   Retry-After: 120
    3825 </artwork></figure>
    3826 <t>
    3827    In the latter example, the delay is 2 minutes.
    3828 </t>
    3829 </section>
    3830 
    3831 <section title="Server" anchor="header.server">
    3832   <iref primary="true" item="Server header field" x:for-anchor=""/>
    3833   <iref primary="true" item="Header Fields" subitem="Server" x:for-anchor=""/>
    3834   <x:anchor-alias value="Server"/>
    3835 <t>
    3836    The "Server" header field contains information about the
    3837    software used by the origin server to handle the request.
    3838 </t>
    3839 <t>
    3840    The field can contain multiple
    3841    product tokens (<xref target="product.tokens"/>) and
    3842    comments (&header-fields;) identifying the server and any significant
    3843    subproducts. The product tokens are listed in order of their significance
    3844    for identifying the application.
    3845 </t>
    3846 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Server"/>
    3847   <x:ref>Server</x:ref> = <x:ref>product</x:ref> *( <x:ref>RWS</x:ref> ( <x:ref>product</x:ref> / <x:ref>comment</x:ref> ) )
    3848 </artwork></figure>
    3849 <t>
    3850    Example:
    3851 </t>
    3852 <figure><artwork type="example">
    3853   Server: CERN/3.0 libwww/2.17
    3854 </artwork></figure>
    3855 <t>
    3856    If the response is being forwarded through a proxy, the proxy application
    3857    &MUST-NOT; modify the <x:ref>Server</x:ref> header field. Instead, it
    3858    &MUST; include a <x:ref>Via</x:ref> field (as described in &header-via;).
    3859 </t>
    3860 <x:note>
    3861   <t>
    3862     &Note; Revealing the specific software version of the server might
    3863     allow the server machine to become more vulnerable to attacks
    3864     against software that is known to contain security holes. Server
    3865     implementers are encouraged to make this field a configurable
    3866     option.
    3867   </t>
    3868 </x:note>
    3869 </section>
    3870 
    3871 <section title="User-Agent" anchor="header.user-agent">
    3872   <iref primary="true" item="User-Agent header field" x:for-anchor=""/>
    3873   <iref primary="true" item="Header Fields" subitem="User-Agent" x:for-anchor=""/>
    3874   <x:anchor-alias value="User-Agent"/>
    3875 <t>
    3876    The "User-Agent" header field contains information about the user
    3877    agent originating the request. User agents &SHOULD; include this field with
    3878    requests.
    3879 </t>
    3880 <t>
    3881    Typically, it is used for statistical purposes, the tracing of protocol
    3882    violations, and tailoring responses to avoid particular user agent
    3883    limitations.
    3884 </t>
    3885 <t>
    3886    The field can contain multiple
    3887    product tokens (<xref target="product.tokens"/>)
    3888    and comments (&header-fields;) identifying the agent and its
    3889    significant subproducts. By convention, the product tokens are listed in
    3890    order of their significance for identifying the application.
    3891 </t>
    3892 <t>
    3893    Because this field is usually sent on every request a user agent makes,
    3894    implementations are encouraged not to include needlessly fine-grained
    3895    detail, and to limit (or even prohibit) the addition of subproducts by third
    3896    parties. Overly long and detailed User-Agent field values make requests
    3897    larger and can also be used to identify ("fingerprint") the user against
    3898    their wishes.
    3899 </t>
    3900 <t>
    3901    Likewise, implementations are encouraged not to use the product tokens of
    3902    other implementations in order to declare compatibility with them, as this
    3903    circumvents the purpose of the field. Finally, they are encouraged not to
    3904    use comments to identify products; doing so makes the field value more
    3905    difficult to parse.
    3906 </t>
    3907 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="User-Agent"/>
    3908   <x:ref>User-Agent</x:ref> = <x:ref>product</x:ref> *( <x:ref>RWS</x:ref> ( <x:ref>product</x:ref> / <x:ref>comment</x:ref> ) )
    3909 </artwork></figure>
    3910 <t>
    3911    Example:
    3912 </t>
    3913 <figure><artwork type="example">
    3914   User-Agent: CERN-LineMode/2.15 libwww/2.17b3
    3915 </artwork></figure>
    39163910</section>
    39173911</section>
     
    56805674<t>
    56815675  Change ABNF productions for header fields to only define the field value.
    5682   (<xref target="header.field.definitions"/>)
    56835676</t>
    56845677<t>
     
    57355728<t>
    57365729  Change ABNF productions for header fields to only define the field value.
    5737   (<xref target="header.field.definitions"/>)
    57385730</t>
    57395731<t>
     
    57415733  implemented with respect to partial responses, and also because of known
    57425734  deficiencies in the hash algorithm itself (see <xref target="RFC6151"/> for details).
    5743   (<xref target="header.field.definitions"/>)
    57445735</t>
    57455736<t>
Note: See TracChangeset for help on using the changeset viewer.