Ignore:
Timestamp:
08/07/12 18:15:03 (8 years ago)
Author:
julian.reschke@…
Message:

Work-in-progress: hyperlink header field definitions, plus minor editorial improvements (P2)

File:
1 edited

Legend:

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

    r1739 r1740  
    305305   impact on security. This is because different uses of the protocol require
    306306   different error handling strategies; for example, a Web browser might wish to
    307    transparently recover from a response where the Location header field
    308    doesn't parse according to the ABNF, whereby in a systems control protocol
    309    using HTTP, this type of error recovery could lead to dangerous consequences.
     307   transparently recover from a response where the <x:ref>Location</x:ref>
     308   header field doesn't parse according to the ABNF, whereby in a systems
     309   control protocol using HTTP, this type of error recovery could lead to
     310   dangerous consequences.
    310311</t>
    311312</section>
     
    388389<t>
    389390   The list of methods allowed by a resource can be specified in an
    390    Allow header field (<xref target="header.allow"/>). The status code of the response
    391    always notifies the client whether a method is currently allowed on a
    392    resource, since the set of allowed methods can change dynamically. An
    393    origin server &SHOULD; respond with the status code <x:ref>405 (Method Not Allowed)</x:ref>
    394    if the method is known by the origin server but not allowed for the
    395    resource, and <x:ref>501 (Not Implemented)</x:ref> if the method is
    396    unrecognized or not implemented by the origin server. The methods GET
    397    and HEAD &MUST; be supported by all general-purpose servers. All other
    398    methods are &OPTIONAL;; however, if the above methods are implemented,
    399    they &MUST; be implemented with the same semantics as those specified
    400    in <xref target="method.definitions"/>.
     391   <x:ref>Allow</x:ref> header field (<xref target="header.allow"/>). The
     392   status code of the response always notifies the client whether a method is
     393   currently allowed on a resource, since the set of allowed methods can change
     394   dynamically. An origin server &SHOULD; respond with the status code
     395   <x:ref>405 (Method Not Allowed)</x:ref> if the method is known by the origin
     396   server but not allowed for the resource, and <x:ref>501 (Not
     397   Implemented)</x:ref> if the method is unrecognized or not implemented by the
     398   origin server. The methods GET and HEAD &MUST; be supported by all
     399   general-purpose servers. All other methods are &OPTIONAL;; however, if the
     400   above methods are implemented, they &MUST; be implemented with the same
     401   semantics as those specified in <xref target="method.definitions"/>.
    401402</t>
    402403
     
    520521<t>
    521522   If the OPTIONS request includes a message body (as indicated by the
    522    presence of Content-Length or Transfer-Encoding), then the media type
    523    &MUST; be indicated by a Content-Type field. Although this
    524    specification does not define any use for such a body, future
    525    extensions to HTTP might use the OPTIONS body to make more detailed
     523   presence of <x:ref>Content-Length</x:ref> or <x:ref>Transfer-Encoding</x:ref>),
     524   then the media type &MUST; be indicated by a <x:ref>Content-Type</x:ref>
     525   field. Although this specification does not define any use for such a body,
     526   future extensions to HTTP might use the OPTIONS body to make more detailed
    526527   queries on the server.
    527528</t>
     
    544545   A <x:ref>200 (OK)</x:ref> response &SHOULD; include any header fields that
    545546   indicate optional features implemented by the server and applicable to that
    546    resource (e.g., Allow), possibly including extensions not defined by
    547    this specification. The response body, if any, &SHOULD; also include
    548    information about the communication options. The format for such a
     547   resource (e.g., <x:ref>Allow</x:ref>), possibly including extensions not
     548   defined by this specification. The response body, if any, &SHOULD; also
     549   include information about the communication options. The format for such a
    549550   body is not defined by this specification, but might be defined by
    550551   future extensions to HTTP. Content negotiation &MAY; be used to select
     
    554555</t>
    555556<t>
    556    The Max-Forwards header field &MAY; be used to target a
     557   The <x:ref>Max-Forwards</x:ref> header field &MAY; be used to target a
    557558   specific proxy in the request chain (see <xref target="header.max-forwards"/>).
    558559   If no Max-Forwards field is present in the request, then the forwarded
     
    681682   &SHOULD; be <x:ref>201 (Created)</x:ref> and contain a representation which
    682683   describes the status of the request and refers to the new resource, and a
    683    Location header field (see <xref target="header.location"/>).
     684   <x:ref>Location</x:ref> header field (see <xref target="header.location"/>).
    684685</t>
    685686<t>
    686687   Responses to POST requests are only cacheable when they
    687688   include explicit freshness information (see &p6-explicit;). A
    688    cached POST response with a Content-Location header field
     689   cached POST response with a <x:ref>Content-Location</x:ref> header field
    689690   (see &header-content-location;) whose value is the effective
    690691   Request URI &MAY; be used to satisfy subsequent GET and HEAD requests.
     
    740741   representation or changing the resource configuration, or respond
    741742   with an appropriate error message containing sufficient information
    742    to explain why the representation is unsuitable.  The <x:ref>409 (Conflict)</x:ref>
    743    or <x:ref>415 (Unsupported Media Type)</x:ref> status codes are suggested, with the
    744    latter being specific to constraints on Content-Type values.
     743   to explain why the representation is unsuitable.  The
     744   <x:ref>409 (Conflict)</x:ref> or <x:ref>415 (Unsupported Media Type)</x:ref>
     745   status codes are suggested, with the latter being specific to constraints on
     746   <x:ref>Content-Type</x:ref> values.
    745747</t>
    746748<t>
    747749   For example, if the target resource is configured to always have a
    748    Content-Type of "text/html" and the representation being PUT has a
    749    Content-Type of "image/jpeg", then the origin server &SHOULD; do one of:
    750    (a) reconfigure the target resource to reflect the new media type;
    751    (b) transform the PUT representation to a format consistent with that
    752    of the resource before saving it as the new resource state; or,
    753    (c) reject the request with a 415 response indicating that the target
    754    resource is limited to "text/html", perhaps including a link to a
    755    different resource that would be a suitable target for the new
    756    representation.
     750   <x:ref>Content-Type</x:ref> of "text/html" and the representation being PUT
     751   has a Content-Type of "image/jpeg", then the origin server &SHOULD; do one of:
     752   <list style="letters">
     753      <t>reconfigure the target resource to reflect the new media type;</t>
     754      <t>transform the PUT representation to a format consistent with that
     755         of the resource before saving it as the new resource state; or,</t>
     756      <t>reject the request with a <x:ref>415 (Unsupported Media Type)</x:ref>
     757         response indicating that the target resource is limited to "text/html",
     758         perhaps including a link to a different resource that would be a
     759         suitable target for the new representation.</t>
     760   </list>
    757761</t>
    758762<t>
     
    870874   &SHOULD; reflect the message received back to the client as the message body
    871875   of a <x:ref>200 (OK)</x:ref> response. The final recipient is either the
    872    origin server or the first proxy to receive a Max-Forwards
     876   origin server or the first proxy to receive a <x:ref>Max-Forwards</x:ref>
    873877   value of zero (0) in the request (see <xref target="header.max-forwards"/>).
    874878   A TRACE request &MUST-NOT; include a message body.
     
    879883   information. The value of the Via header field (&header-via;) is of
    880884   particular interest, since it acts as a trace of the request chain.
    881    Use of the Max-Forwards header field allows the client to limit the
    882    length of the request chain, which is useful for testing a chain of
     885   Use of the <x:ref>Max-Forwards</x:ref> header field allows the client to
     886   limit the length of the request chain, which is useful for testing a chain of
    883887   proxies forwarding messages in an infinite loop.
    884888</t>
    885889<t>
    886    If the request is valid, the response &SHOULD; have a Content-Type of
    887    "message/http" (see &media-type-message-http;) and contain a message body
    888    that encloses a copy of the entire request message.
     890   If the request is valid, the response &SHOULD; have a
     891   <x:ref>Content-Type</x:ref> of "message/http" (see &media-type-message-http;)
     892   and contain a message body that encloses a copy of the entire request message.
    889893   Responses to the TRACE method are not cacheable.
    890894</t>
     
    10231027<t>
    10241028   Many header fields use a format including (case-insensitively) named
    1025    parameters (for instance, Content-Type, defined in &header-content-type;).
    1026    Allowing both unquoted (token) and quoted (quoted-string) syntax for the
    1027    parameter value enables recipients to use existing parser components. When
    1028    allowing both forms, the meaning of a parameter value ought to be
    1029    independent of the syntax used for it (for an example, see the notes on
    1030    parameter handling for media types in &media-types;).
     1029   parameters (for instance, <x:ref>Content-Type</x:ref>, defined in
     1030   &header-content-type;). Allowing both unquoted (token) and quoted
     1031   (quoted-string) syntax for the parameter value enables recipients to use
     1032   existing parser components. When allowing both forms, the meaning of a
     1033   parameter value ought to be independent of the syntax used for it (for an
     1034   example, see the notes on parameter handling for media types in
     1035   &media-types;).
    10311036</t>
    10321037<t>
     
    11731178<t>
    11741179   For most status codes the response can carry a payload, in which case a
    1175    Content-Type header field indicates the payload's media type
     1180   <x:ref>Content-Type</x:ref> header field indicates the payload's media type
    11761181   (&header-content-type;).
    11771182</t>
     
    14081413<t>
    14091414   Newly created resources are typically linked to from the response payload,
    1410    with the most relevant URI also being carried in the Location header field.
    1411    If the newly created resource's URI is the same as the Effective Request URI,
    1412    this information can be omitted (e.g., in the case of a response to a PUT
    1413    request). 
     1415   with the most relevant URI also being carried in the <x:ref>Location</x:ref>
     1416   header field. If the newly created resource's URI is the same as the
     1417   Effective Request URI, this information can be omitted (e.g., in the case of
     1418   a response to a PUT request). 
    14141419</t>
    14151420<t>
     
    14211426   A 201 response &MAY; contain an <x:ref>ETag</x:ref> response header field
    14221427   indicating the current value of the entity-tag for the representation of the
    1423    resource identified by the Location header field or, in case the Location
    1424    header field was omitted, by the Effective Request URI (see &header-etag;).
     1428   resource identified by the <x:ref>Location</x:ref> header field or, in case
     1429   the Location header field was omitted, by the Effective Request URI (see
     1430   &header-etag;).
    14251431</t>
    14261432</section>
     
    15471553        <t>
    15481554          Redirects of the request to another URI, either temporarily or
    1549           permanently. The new URI is specified in the Location header field.
    1550           In this specification, the status codes <x:ref>301 (Moved Permanently)</x:ref>,
    1551           <x:ref>302 (Found)</x:ref>, and <x:ref>307 (Temporary Redirect)</x:ref>
    1552           fall under this category.
     1555          permanently. The new URI is specified in the <x:ref>Location</x:ref>
     1556          header field. In this specification, the status codes <x:ref>301
     1557          (Moved Permanently)</x:ref>, <x:ref>302 (Found)</x:ref>, and
     1558          <x:ref>307 (Temporary Redirect)</x:ref> fall under this category.
    15531559        </t>
    15541560      </x:lt>
     
    15951601</x:note>
    15961602<t>
    1597    A Location header field on a 3xx response indicates that a client &MAY;
    1598    automatically redirect to the URI provided; see <xref target="header.location"/>.
     1603   A <x:ref>Location</x:ref> header field on a 3xx response indicates that a
     1604   client &MAY; automatically redirect to the URI provided; see
     1605   <xref target="header.location"/>.
    15991606</t>
    16001607<t>
     
    16381645<t>
    16391646   If the server has a preferred choice of representation, it &SHOULD;
    1640    include the specific URI for that representation in the Location
     1647   include the specific URI for that representation in the <x:ref>Location</x:ref>
    16411648   field; user agents &MAY; use the Location field value for automatic
    16421649   redirection.
     
    16661673</t>
    16671674<t>
    1668    The new permanent URI &SHOULD; be given by the Location field in the
    1669    response. A response payload can contain a short hypertext note with a
     1675   The new permanent URI &SHOULD; be given by the <x:ref>Location</x:ref> field
     1676   in the response. A response payload can contain a short hypertext note with a
    16701677   hyperlink to the new URI(s).
    16711678</t>
     
    16911698</t>
    16921699<t>
    1693    The temporary URI &SHOULD; be given by the Location field in the
    1694    response. A response payload can contain a short hypertext note with a
     1700   The temporary URI &SHOULD; be given by the <x:ref>Location</x:ref> field in
     1701   the response. A response payload can contain a short hypertext note with a
    16951702   hyperlink to the new URI(s).
    16961703</t>
     
    17121719   The 303 status code indicates that the server is redirecting the
    17131720   user agent to a different resource, as indicated by a URI in the
    1714    Location header field, that is intended to provide an indirect
     1721   <x:ref>Location</x:ref> header field, that is intended to provide an indirect
    17151722   response to the original request.  In order to satisfy the original
    17161723   request, a user agent &SHOULD; perform a retrieval request using the
     
    17321739   A 303 response to a GET request indicates that the requested
    17331740   resource does not have a representation of its own that can be
    1734    transferred by the server over HTTP.  The Location URI indicates a
    1735    resource that is descriptive of the target resource, such that the
    1736    follow-on representation might be useful to recipients without
     1741   transferred by the server over HTTP.  The <x:ref>Location</x:ref> URI
     1742   indicates a resource that is descriptive of the target resource, such that
     1743   the follow-on representation might be useful to recipients without
    17371744   implying that it adequately represents the target resource.
    17381745   Note that answers to the questions of what can be represented, what
     
    17441751   Except for responses to a HEAD request, the representation of a 303
    17451752   response &SHOULD; contain a short hypertext note with a hyperlink
    1746    to the Location URI.
     1753   to the <x:ref>Location</x:ref> URI.
    17471754</t>
    17481755</section>
     
    17781785</t>
    17791786<t>
    1780    The temporary URI &SHOULD; be given by the Location field in the
    1781    response. A response payload can contain a short hypertext note with a
     1787   The temporary URI &SHOULD; be given by the <x:ref>Location</x:ref> field in
     1788   the response. A response payload can contain a short hypertext note with a
    17821789   hyperlink to the new URI(s).
    17831790</t>
     
    18671874<t>
    18681875   The method specified in the request-line is not allowed for the target
    1869    resource. The response &MUST; include an Allow header field containing a
    1870    list of valid methods for the requested resource.
     1876   resource. The response &MUST; include an <x:ref>Allow</x:ref> header field
     1877   containing a list of valid methods for the requested resource.
    18711878</t>
    18721879</section>
     
    18791886   The resource identified by the request is only capable of generating
    18801887   response representations which have content characteristics not acceptable
    1881    according to the Accept and Accept-* header fields sent in the request.
     1888   according to the <x:ref>Accept</x:ref> and Accept-* header fields sent in
     1889   the request.
    18821890</t>
    18831891<t>
     
    19932001</t>
    19942002<t>
    1995    If the condition is temporary, the server &SHOULD; include a Retry-After
    1996    header field to indicate that it is temporary and after what
    1997    time the client &MAY; try again.
     2003   If the condition is temporary, the server &SHOULD; include a
     2004   <x:ref>Retry-After</x:ref> header field to indicate that it is temporary and
     2005   after what time the client &MAY; try again.
    19982006</t>
    19992007</section>
     
    20322040  <x:anchor-alias value="417 (Expectation Failed)"/>
    20332041<t>
    2034    The expectation given in an Expect header field (see <xref target="header.expect"/>)
    2035    could not be met by this server, or, if the server is a proxy,
    2036    the server has unambiguous evidence that the request could not be met
    2037    by the next-hop server.
     2042   The expectation given in an <x:ref>Expect</x:ref> header field (see
     2043   <xref target="header.expect"/>) could not be met by this server, or, if the
     2044   server is a proxy, the server has unambiguous evidence that the request
     2045   could not be met by the next-hop server.
    20382046</t>
    20392047</section>
     
    21262134   The implication is that this is a temporary condition which will be
    21272135   alleviated after some delay. If known, the length of the delay &MAY; be
    2128    indicated in a Retry-After header field (<xref target="header.retry-after"/>).
    2129    If no Retry-After is given, the client &SHOULD; handle the response as it
    2130    would for a 500 response.
     2136   indicated in a <x:ref>Retry-After</x:ref> header field
     2137   (<xref target="header.retry-after"/>). If no Retry-After is given, the
     2138   client &SHOULD; handle the response as it would for a <x:ref>500 (Internal
     2139   Server Error)</x:ref> response.
    21312140</t>
    21322141<x:note>
     
    23752384</t>
    23762385<t>
    2377    HTTP uses charset in two contexts: within an Accept-Charset request
    2378    header field (in which the charset value is an unquoted token) and as the
    2379    value of a parameter in a Content-Type header field (within a request or
    2380    response), in which case the parameter value of the charset parameter
    2381    can be quoted.
     2386   HTTP uses charset in two contexts: within an <x:ref>Accept-Charset</x:ref>
     2387   request header field (in which the charset value is an unquoted token) and
     2388   as the value of a parameter in a <x:ref>Content-Type</x:ref> header field
     2389   (within a request or response), in which case the parameter value of the
     2390   charset parameter can be quoted.
    23822391</t>
    23832392<t>
     
    24022411<t>
    24032412   All content-coding values are case-insensitive. HTTP/1.1 uses
    2404    content-coding values in the Accept-Encoding (<xref target="header.accept-encoding"/>) and
    2405    Content-Encoding (<xref target="header.content-encoding"/>) header fields. Although the value
     2413   content-coding values in the <x:ref>Accept-Encoding</x:ref>
     2414   (<xref target="header.accept-encoding"/>) and <x:ref>Content-Encoding</x:ref>
     2415   (<xref target="header.content-encoding"/>) header fields. Although the value
    24062416   describes the content-coding, what is more important is that it
    24072417   indicates what decoding mechanism will be required to remove the
     
    24702480  <x:anchor-alias value="subtype"/>
    24712481<t>
    2472    HTTP uses Internet Media Types <xref target="RFC2046"/> in the Content-Type (<xref target="header.content-type"/>)
    2473    and Accept (<xref target="header.accept"/>) header fields in order to provide
    2474    open and extensible data typing and type negotiation.
     2482   HTTP uses Internet Media Types <xref target="RFC2046"/> in the
     2483   <x:ref>Content-Type</x:ref> (<xref target="header.content-type"/>)
     2484   and <x:ref>Accept</x:ref> (<xref target="header.accept"/>) header fields in
     2485   order to provide open and extensible data typing and type negotiation.
    24752486</t>
    24762487<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="media-type"/><iref primary="true" item="Grammar" subitem="type"/><iref primary="true" item="Grammar" subitem="subtype"/>
     
    25852596   natural language spoken, written, or otherwise conveyed by human beings for
    25862597   communication of information to other human beings. Computer languages are
    2587    explicitly excluded. HTTP uses language tags within the Accept-Language and
    2588    Content-Language fields.
     2598   explicitly excluded. HTTP uses language tags within the
     2599   <x:ref>Accept-Language</x:ref> and <x:ref>Content-Language</x:ref> fields.
    25892600</t>
    25902601<t>
     
    26752686   A 200 response to PUT, in contrast, contains either a representation
    26762687   that describes the successful action or a representation of the target
    2677    resource, with the latter indicated by a Content-Location header field
    2678    with the same value as the effective request URI.  Likewise, response
    2679    messages with an error status code usually contain a representation that
    2680    describes the error and what next steps are suggested for resolving it.
     2688   resource, with the latter indicated by a <x:ref>Content-Location</x:ref>
     2689   header field with the same value as the effective request URI.  Likewise,
     2690   response messages with an error status code usually contain a representation
     2691   that describes the error and what next steps are suggested for resolving it.
    26812692</t>
    26822693<t>
     
    27172728   and the request method was GET or HEAD, the response payload is a partial
    27182729   representation of the target resource.</t>
    2719    <t>If the response has a Content-Location header field, and that URI is the same
    2720    as the effective request URI, the response payload is a representation of the
    2721    target resource.</t>
    2722    <t>If the response has a Content-Location header field, and that URI is not the
    2723    same as the effective request URI, then the response asserts that its
    2724    payload is a representation of the resource identified by the
    2725    Content-Location URI. However, such an assertion cannot be trusted unless
     2730   <t>If the response has a <x:ref>Content-Location</x:ref> header field, and
     2731   that URI is the same as the effective request URI, the response payload is a
     2732   representation of the target resource.</t>
     2733   <t>If the response has a <x:ref>Content-Location</x:ref> header field, and
     2734   that URI is not the same as the effective request URI, then the response
     2735   asserts that its payload is a representation of the resource identified by
     2736   the Content-Location URI. However, such an assertion cannot be trusted unless
    27262737   it can be verified by other means (not defined by HTTP).</t>
    27272738   <t>Otherwise, the response is a representation of an anonymous (i.e.,
     
    27822793</t>
    27832794<t>
    2784    The data type of the representation data
    2785    is determined via the header fields Content-Type and Content-Encoding.
     2795   The data type of the representation data is determined via the header fields
     2796   <x:ref>Content-Type</x:ref> and <x:ref>Content-Encoding</x:ref>.
    27862797   These define a two-layer, ordered encoding model:
    27872798</t>
     
    27902801</artwork></figure>
    27912802<t>
    2792    Content-Type specifies the media type of the underlying data, which
    2793    defines both the data format and how that data &SHOULD; be processed
     2803   <x:ref>Content-Type</x:ref> specifies the media type of the underlying data,
     2804   which defines both the data format and how that data &SHOULD; be processed
    27942805   by the recipient (within the scope of the request method semantics).
    27952806   Any HTTP/1.1 message containing a payload body &SHOULD; include a
     
    28152826</t>
    28162827<t>
    2817    Content-Encoding is used to indicate any additional content
     2828   <x:ref>Content-Encoding</x:ref> is used to indicate any additional content
    28182829   codings applied to the data, usually for the purpose of data
    28192830   compression, that are a property of the representation.  If
    28202831   Content-Encoding is not present, then there is no additional
    2821    encoding beyond that defined by the Content-Type.
     2832   encoding beyond that defined by the <x:ref>Content-Type</x:ref> header field.
    28222833</t>
    28232834</section>
     
    28872898   avoid the round-trip delay of a subsequent request if the "best
    28882899   guess" is good enough for the user). In order to improve the server's
    2889    guess, the user agent &MAY; include request header fields (Accept,
    2890    Accept-Language, Accept-Encoding, etc.) which describe its
     2900   guess, the user agent &MAY; include request header fields (<x:ref>Accept</x:ref>,
     2901   <x:ref>Accept-Language</x:ref>, <x:ref>Accept-Encoding</x:ref>, etc.) which describe its
    28912902   preferences for such a response.
    28922903</t>
     
    29312942   HTTP/1.1 includes the following header fields for enabling
    29322943   server-driven negotiation through description of user agent
    2933    capabilities and user preferences: Accept (<xref target="header.accept"/>), Accept-Charset
    2934    (<xref target="header.accept-charset"/>), Accept-Encoding (<xref target="header.accept-encoding"/>), Accept-Language
    2935    (<xref target="header.accept-language"/>), and User-Agent (&header-user-agent;).
     2944   capabilities and user preferences: <x:ref>Accept</x:ref>
     2945   (<xref target="header.accept"/>), <x:ref>Accept-Charset</x:ref>
     2946   (<xref target="header.accept-charset"/>), <x:ref>Accept-Encoding</x:ref>
     2947   (<xref target="header.accept-encoding"/>), <x:ref>Accept-Language</x:ref>
     2948   (<xref target="header.accept-language"/>), and <x:ref>User-Agent</x:ref>
     2949   (&header-user-agent;).
    29362950   However, an origin server is not limited to these dimensions and &MAY; vary
    29372951   the response based on any aspect of the request, including aspects
     
    29412955<x:note>
    29422956  <t>
    2943     &Note; In practice, User-Agent based negotiation is fragile,
     2957    &Note; In practice, <x:ref>User-Agent</x:ref> based negotiation is fragile,
    29442958    because new clients might not be recognized.
    29452959  </t>
     
    33493363   have been applied to the representation beyond those inherent in the media
    33503364   type, and thus what decoding mechanisms have to be applied in order to obtain
    3351    the media-type referenced by the Content-Type header field.
     3365   the media-type referenced by the <x:ref>Content-Type</x:ref> header field.
    33523366   Content-Encoding is primarily used to allow a representation to be
    33533367   compressed without losing the identity of its underlying media type.
     
    33783392   representation.  Likewise, an origin server might choose to publish the
    33793393   same payload data as multiple representations that differ only in whether
    3380    the coding is defined as part of Content-Type or Content-Encoding, since
    3381    some user agents will behave differently in their handling of each
    3382    response (e.g., open a "Save as ..." dialog instead of automatic
    3383    decompression and rendering of content).
     3394   the coding is defined as part of <x:ref>Content-Type</x:ref> or
     3395   Content-Encoding, since some user agents will behave differently in their
     3396   handling of each response (e.g., open a "Save as ..." dialog instead of
     3397   automatic decompression and rendering of content).
    33843398</t>
    33853399<t>
     
    37803794<x:note>
    37813795  <t>
    3782     &Note; The Content-Location header field (&header-content-location;) differs
    3783     from Location in that the Content-Location identifies the most specific
    3784     resource corresponding to the enclosed representation.
    3785     It is therefore possible for a response to contain header fields for
    3786     both Location and Content-Location.
     3796    &Note; The <x:ref>Content-Location</x:ref> header field
     3797    (&header-content-location;) differs from Location in that the
     3798    Content-Location identifies the most specific resource corresponding to the
     3799    enclosed representation. It is therefore possible for a response to contain
     3800    header fields for both Location and Content-Location.
    37873801  </t>
    37883802</x:note>
     
    44244438   </c>
    44254439   <c>identity</c>
    4426    <c>reserved (synonym for "no encoding" in Accept-Encoding header field)</c>
     4440   <c>reserved (synonym for "no encoding" in <x:ref>Accept-Encoding</x:ref>
     4441   header field)</c>
    44274442   <c>
    44284443      <xref target="header.accept-encoding"/>
     
    44504465   applications &SHOULD; supply as much control over this information as
    44514466   possible to the provider of that information. Four header fields are
    4452    worth special mention in this context: Server, Via, Referer and From.
     4467   worth special mention in this context: <x:ref>Server</x:ref>,
     4468   <x:ref>Via</x:ref>, <x:ref>Referer</x:ref> and <x:ref>From</x:ref>.
    44534469</t>
    44544470<t>
     
    44564472   server machine to become more vulnerable to attacks against software
    44574473   that is known to contain security holes. Implementors &SHOULD; make the
    4458    Server header field a configurable option.
     4474   <x:ref>Server</x:ref> header field a configurable option.
    44594475</t>
    44604476<t>
     
    44664482</t>
    44674483<t>
    4468    The Referer header field allows reading patterns to be studied and reverse
    4469    links drawn. Although it can be very useful, its power can be abused
    4470    if user details are not separated from the information contained in
    4471    the Referer. Even when the personal information has been removed, the
    4472    Referer header field might indicate a private document's URI whose
    4473    publication would be inappropriate.
    4474 </t>
    4475 <t>
    4476    The information sent in the From field might conflict with the user's
    4477    privacy interests or their site's security policy, and hence it
     4484   The <x:ref>Referer</x:ref> header field allows reading patterns to be
     4485   studied and reverse links drawn. Although it can be very useful, its power
     4486   can be abused if user details are not separated from the information
     4487   contained in the Referer. Even when the personal information has been
     4488   removed, the Referer header field might indicate a private document's URI
     4489   whose publication would be inappropriate.
     4490</t>
     4491<t>
     4492   The information sent in the <x:ref>From</x:ref> field might conflict with
     4493   the user's privacy interests or their site's security policy, and hence it
    44784494   &SHOULD-NOT;  be transmitted without the user being able to disable,
    44794495   enable, and modify the contents of the field. The user &MUST; be able
     
    44834499<t>
    44844500   We suggest, though do not require, that a convenient toggle interface
    4485    be provided for the user to enable or disable the sending of From and
    4486    Referer information.
    4487 </t>
    4488 <t>
    4489    The User-Agent (<xref target="header.user-agent"/>) or Server (<xref
    4490    target="header.server"/>) header fields can sometimes be used to determine
    4491    that a specific client or server has a particular security hole which might
    4492    be exploited. Unfortunately, this same information is often used for other
    4493    valuable purposes for which HTTP currently has no better mechanism.
    4494 </t>
    4495 <t>
    4496    Furthermore, the User-Agent header field might contain enough entropy to be
    4497    used, possibly in conjunction with other material, to uniquely identify the
    4498    user.
     4501   be provided for the user to enable or disable the sending of
     4502   <x:ref>From</x:ref> and <x:ref>Referer</x:ref> information.
     4503</t>
     4504<t>
     4505   The <x:ref>User-Agent</x:ref> (<xref target="header.user-agent"/>) or
     4506   <x:ref>Server</x:ref> (<xref target="header.server"/>) header fields can
     4507   sometimes be used to determine that a specific client or server has a
     4508   particular security hole which might be exploited. Unfortunately, this same
     4509   information is often used for other valuable purposes for which HTTP
     4510   currently has no better mechanism.
     4511</t>
     4512<t>
     4513   Furthermore, the <x:ref>User-Agent</x:ref> header field might contain enough
     4514   entropy to be used, possibly in conjunction with other material, to uniquely
     4515   identify the user.
    44994516</t>
    45004517<t>
     
    45124529   reveal an otherwise private information source, it is strongly
    45134530   recommended that the user be able to select whether or not the
    4514    Referer field is sent. For example, a browser client could have a
    4515    toggle switch for browsing openly/anonymously, which would
     4531   <x:ref>Referer</x:ref> field is sent. For example, a browser client could
     4532   have a toggle switch for browsing openly/anonymously, which would
    45164533   respectively enable/disable the sending of Referer and From
    45174534   information.
    45184535</t>
    45194536<t>
    4520    Clients &SHOULD-NOT; include a Referer header field in a (non-secure)
    4521    HTTP request if the referring page was transferred with a secure
     4537   Clients &SHOULD-NOT; include a <x:ref>Referer</x:ref> header field in a
     4538   (non-secure) HTTP request if the referring page was transferred with a secure
    45224539   protocol.
    45234540</t>
     
    45344551<t>
    45354552   If a single server supports multiple organizations that do not trust
    4536    one another, then it &MUST; check the values of Location and Content-Location
    4537    header fields in responses that are generated under control of
    4538    said organizations to make sure that they do not attempt to
    4539    invalidate resources over which they have no authority.
     4553   one another, then it &MUST; check the values of <x:ref>Location</x:ref> and
     4554   <x:ref>Content-Location</x:ref> header fields in responses that are
     4555   generated under control of said organizations to make sure that they do not
     4556   attempt to invalidate resources over which they have no authority.
    45404557</t>
    45414558<t>
    45424559   Furthermore, appending the fragment identifier from one URI to another
    4543    one obtained from a Location header field might leak confidential
    4544    information to the target server &mdash; although the fragment identifier is
    4545    not transmitted in the final request, it might be visible to the user agent
    4546    through other means, such as scripting.
     4560   one obtained from a <x:ref>Location</x:ref> header field might leak
     4561   confidential information to the target server &mdash; although the fragment
     4562   identifier is not transmitted in the final request, it might be visible to
     4563   the user agent through other means, such as scripting.
    45474564</t>
    45484565</section>
     
    45614578<t>
    45624579   Accept header fields can reveal information about the user to all
    4563    servers which are accessed. The Accept-Language header field in particular
    4564    can reveal information the user would consider to be of a private
    4565    nature, because the understanding of particular languages is often
     4580   servers which are accessed. The <x:ref>Accept-Language</x:ref> header field
     4581   in particular can reveal information the user would consider to be of a
     4582   private nature, because the understanding of particular languages is often
    45664583   strongly correlated to the membership of a particular ethnic group.
    45674584   User agents which offer the option to configure the contents of an
     
    46274644  </front>
    46284645  <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p1-messaging-&ID-VERSION;"/>
    4629   <x:source href="p1-messaging.xml" basename="p1-messaging"/>
     4646  <x:source href="p1-messaging.xml" basename="p1-messaging">
     4647    <x:defines>Content-Length</x:defines>
     4648    <x:defines>Transfer-Encoding</x:defines>
     4649    <x:defines>Via</x:defines>
     4650  </x:source>
    46304651</reference>
    46314652
     
    53615382   environment &SHOULD; translate all line breaks within the text media
    53625383   types described in <xref target="canonicalization.and.text.defaults"/>
    5363    of this document to the RFC 2049
    5364    canonical form of CRLF. Note, however, that this might be complicated
    5365    by the presence of a Content-Encoding and by the fact that HTTP
    5366    allows the use of some character encodings which do not use octets 13 and
    5367    10 to represent CR and LF, respectively, as is the case for some multi-byte
    5368    character encodings.
     5384   of this document to the RFC 2049 canonical form of CRLF. Note, however, that
     5385   this might be complicated by the presence of a <x:ref>Content-Encoding</x:ref>
     5386   and by the fact that HTTP allows the use of some character encodings which do
     5387   not use octets 13 and 10 to represent CR and LF, respectively, as is the case
     5388   for some multi-byte character encodings.
    53695389</t>
    53705390<t>
     
    53815401   HTTP/1.1 uses a restricted set of date formats (&http-date;) to
    53825402   simplify the process of date comparison. Proxies and gateways from
    5383    other protocols &SHOULD; ensure that any Date header field present in a
    5384    message conforms to one of the HTTP/1.1 formats and rewrite the date
    5385    if necessary.
     5403   other protocols &SHOULD; ensure that any <x:ref>Date</x:ref> header field
     5404   present in a message conforms to one of the HTTP/1.1 formats and rewrite
     5405   the date if necessary.
    53865406</t>
    53875407</section>
     
    53905410<t>
    53915411   MIME does not include any concept equivalent to HTTP/1.1's
    5392    Content-Encoding header field. Since this acts as a modifier on the
    5393    media type, proxies and gateways from HTTP to MIME-compliant
    5394    protocols &MUST; either change the value of the Content-Type header
    5395    field or decode the representation before forwarding the message. (Some
    5396    experimental applications of Content-Type for Internet mail have used
     5412   <x:ref>Content-Encoding</x:ref> header field. Since this acts as a modifier
     5413   on the media type, proxies and gateways from HTTP to MIME-compliant
     5414   protocols &MUST; either change the value of the <x:ref>Content-Type</x:ref>
     5415   header field or decode the representation before forwarding the message.
     5416   (Some experimental applications of Content-Type for Internet mail have used
    53975417   a media-type parameter of ";conversions=&lt;content-coding&gt;" to perform
    53985418   a function equivalent to Content-Encoding. However, this parameter is
     
    55035523  Deprecate <x:ref>305 (Use Proxy)</x:ref> status code, because user agents did
    55045524  not implement it. It used to indicate that the target resource needs to be
    5505   accessed through the proxy given by the Location field. The Location field
    5506   gave the URI of the proxy. The recipient was expected to repeat this single
    5507   request via the proxy.
     5525  accessed through the proxy given by the <x:ref>Location</x:ref> field. The
     5526  Location field gave the URI of the proxy. The recipient was expected to
     5527  repeat this single request via the proxy.
    55085528  (<xref target="status.305"/>)
    55095529</t>
     
    55185538</t>
    55195539<t>
    5520   Reclassify "Allow" as response header field, removing the option to
    5521   specify it in a PUT request.
     5540  Reclassify "<x:ref>Allow</x:ref>" as response header field, removing the
     5541  option to specify it in a PUT request.
    55225542  Relax the server requirement on the contents of the Allow header field and
    55235543  remove requirement on clients to always trust the header field value.
     
    55255545</t>
    55265546<t>
    5527   The ABNF for the Expect header field has been both fixed (allowing parameters
    5528   for value-less expectations as well) and simplified (allowing trailing
    5529   semicolons after "100-continue" when they were invalid before).
     5547  The ABNF for the <x:ref>Expect</x:ref> header field has been both fixed
     5548  (allowing parameters for value-less expectations as well) and simplified
     5549  (allowing trailing semicolons after "100-continue" when they were invalid
     5550  before).
    55305551  (<xref target="header.expect"/>)
    55315552</t>
    55325553<t>
    5533   Correct syntax of Location header field to allow URI references (including
    5534   relative references and fragments), as referred symbol "absoluteURI" wasn't
    5535   what was expected, and add some clarifications as to when use of fragments
    5536   would not be appropriate.
     5554  Correct syntax of <x:ref>Location</x:ref> header field to allow URI
     5555  references (including relative references and fragments), as referred symbol
     5556  "absoluteURI" wasn't what was expected, and add some clarifications as to
     5557  when use of fragments would not be appropriate.
    55375558  (<xref target="header.location"/>)
    55385559</t>
    55395560<t>
    5540   Restrict Max-Forwards header field to OPTIONS and TRACE (previously,
    5541   extension methods could have used it as well).
     5561  Restrict <x:ref>Max-Forwards</x:ref> header field to OPTIONS and TRACE
     5562  (previously, extension methods could have used it as well).
    55425563  (<xref target="header.max-forwards"/>)
    55435564</t>
    55445565<t>
    5545   Allow Referer field value of "about:blank" as alternative to not specifying it.
     5566  Allow <x:ref>Referer</x:ref> field value of "about:blank" as alternative to
     5567  not specifying it.
    55465568  (<xref target="header.referer"/>)
    55475569</t>
    55485570<t>
    5549   In the description of the Server header field, the Via field
    5550   was described as a SHOULD. The requirement was and is stated
    5551   correctly in the description of the Via header field in &header-via;.
     5571  In the description of the <x:ref>Server</x:ref> header field, the
     5572  <x:ref>Via</x:ref> field was described as a SHOULD. The requirement was and
     5573  is stated correctly in the description of the Via header field in
     5574  &header-via;.
    55525575  (<xref target="header.server"/>)
    55535576</t>
     
    55765599</t>
    55775600<t>
    5578   Remove ISO-8859-1 special-casing in Accept-Charset.
     5601  Remove ISO-8859-1 special-casing in <x:ref>Accept-Charset</x:ref>.
    55795602  (<xref target="header.accept-charset"/>)
    55805603</t>
    55815604<t>
    5582   Remove base URI setting semantics for Content-Location due to poor
    5583   implementation support, which was caused by too many broken servers emitting
     5605  Remove base URI setting semantics for <x:ref>Content-Location</x:ref> due to
     5606  poor implementation support, which was caused by too many broken servers emitting
    55845607  bogus Content-Location header fields, and also the potentially undesirable effect
    55855608  of potentially breaking relative links in content-negotiated resources.
Note: See TracChangeset for help on using the changeset viewer.