Ignore:
Timestamp:
Sep 7, 2010, 4:46:12 AM (9 years ago)
Author:
julian.reschke@…
Message:

Uniform use of 'header field' (see #234)

File:
1 edited

Legend:

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

    r981 r994  
    2222  <!ENTITY caching                    "<xref target='Part6' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2323  <!ENTITY auth                       "<xref target='Part7' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    24   <!ENTITY caching-combining-headers  "<xref target='Part6' x:rel='#combining.headers' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     24  <!ENTITY combining-responses        "<xref target='Part6' x:rel='#combining.responses' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2525  <!ENTITY content-negotiation        "<xref target='Part3' x:rel='#content.negotiation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2626  <!ENTITY notation-abnf              "<xref target='Part1' x:rel='#notation.abnf' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     
    7878  <!ENTITY p6-explicit               "<xref target='Part6' x:rel='#calculating.freshness.lifetime'
    7979xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    80   <!ENTITY p6-combine               "<xref target='Part6' x:rel='#combining.headers'
    81 xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    8280]>
    8381<?rfc toc="yes" ?>
     
    692690   <t>If the response status code is 204, 206, or 304 and the request method was GET
    693691   or HEAD, the response payload is a partial representation of the target
    694    (see &caching-combining-headers;).</t>
    695    <t>If the response has a Content-Location header, and that URI is the same
     692   (see &combining-responses;).</t>
     693   <t>If the response has a Content-Location header field, and that URI is the same
    696694   as the effective request URI, the response payload is a representation of the
    697695   target resource.</t>
    698    <t>If the response has a Content-Location header, and that URI is not the
     696   <t>If the response has a Content-Location header field, and that URI is not the
    699697   same as the effective request URI, then the response asserts that its
    700698   payload is a representation of the resource identified by the
     
    874872   The HEAD method is identical to GET except that the server &MUST-NOT;
    875873   return a message-body in the response. The metadata contained
    876    in the HTTP headers in response to a HEAD request &SHOULD; be identical
     874   in the HTTP header fields in response to a HEAD request &SHOULD; be identical
    877875   to the information sent in response to a GET request. This method can
    878876   be used for obtaining metadata about the representation implied by the
     
    932930   &SHOULD; be 201 (Created) and contain a representation which describes the
    933931   status of the request and refers to the new resource, and a Location
    934    header (see <xref target="header.location"/>).
     932   header field (see <xref target="header.location"/>).
    935933</t>
    936934<t>
    937935   Responses to POST requests are only cacheable when they
    938936   include explicit freshness information (see &p6-explicit;). A
    939    cached POST response with a Content-Location header
     937   cached POST response with a Content-Location header field
    940938   (see &header-content-location;) whose value is the effective
    941939   Request URI &MAY; be used to satisfy subsequent GET and HEAD requests.
     
    971969   error response &SHOULD; be given that reflects the nature of the problem.
    972970   The recipient of the representation &MUST-NOT; ignore any Content-*
    973    headers (headers starting with the prefix "Content-") that it does
     971   header fields (headers starting with the prefix "Content-") that it does
    974972   not understand or implement
    975973   and &MUST; return a 501 (Not Implemented) response in such cases.
     
    10951093<t>
    10961094   This class of status code indicates a provisional response,
    1097    consisting only of the Status-Line and optional headers, and is
    1098    terminated by an empty line. There are no required headers for this
     1095   consisting only of the Status-Line and optional header fields, and is
     1096   terminated by an empty line. There are no required header fields for this
    10991097   class of status code. Since HTTP/1.0 did not define any 1xx status
    11001098   codes, servers &MUST-NOT; send a 1xx response to an HTTP/1.0 client
     
    16191617   The method specified in the Request-Line is not allowed for the target
    16201618   resource. The response &MUST; include an
    1621    Allow header containing a list of valid methods for the requested
     1619   Allow header field containing a list of valid methods for the requested
    16221620   resource.
    16231621</t>
     
    16301628   The resource identified by the request is only capable of generating
    16311629   response representations which have content characteristics not acceptable
    1632    according to the accept headers sent in the request.
     1630   according to the accept header fields sent in the request.
    16331631</t>
    16341632<t>
     
    16451643  <t>
    16461644    <x:h>Note:</x:h> HTTP/1.1 servers are allowed to return responses which are
    1647     not acceptable according to the accept headers sent in the
     1645    not acceptable according to the accept header fields sent in the
    16481646    request. In some cases, this might even be preferable to sending a
    1649     406 response. User agents are encouraged to inspect the headers of
     1647    406 response. User agents are encouraged to inspect the header fields of
    16501648    an incoming response to determine if it is acceptable.
    16511649  </t>
     
    18721870   is that this is a temporary condition which will be alleviated after
    18731871   some delay. If known, the length of the delay &MAY; be indicated in a
    1874    Retry-After header. If no Retry-After is given, the client &SHOULD;
     1872   Retry-After header field. If no Retry-After is given, the client &SHOULD;
    18751873   handle the response as it would for a 500 response.
    18761874</t>
     
    20011999   return a 417 (Expectation Failed) status code if it receives a request
    20022000   with an expectation that it cannot meet. However, the Expect
    2003    request-header itself is end-to-end; it &MUST; be forwarded if the
     2001   request-header field itself is end-to-end; it &MUST; be forwarded if the
    20042002   request is forwarded.
    20052003</t>
    20062004<t>
    20072005   Many older HTTP/1.0 and HTTP/1.1 applications do not understand the
    2008    Expect header.
     2006   Expect header field.
    20092007</t>
    20102008<t>
     
    20432041   of this field is that the request is being performed on behalf of the
    20442042   person given, who accepts responsibility for the method performed. In
    2045    particular, robot agents &SHOULD; include this header so that the
     2043   particular, robot agents &SHOULD; include this header field so that the
    20462044   person responsible for running the robot can be contacted if problems
    20472045   occur on the receiving end.
     
    20992097   <list style="symbols">
    21002098      <t>With a 201 Created response, because in this usage the Location header
    2101       specifies the URI for the entire created resource.</t>
     2099      field specifies the URI for the entire created resource.</t>
    21022100      <t>With 305 Use Proxy.</t>
    21032101   </list>
     
    21692167</t>
    21702168<t>
    2171    The Referer header allows servers to generate lists of back-links to
     2169   The Referer header field allows servers to generate lists of back-links to
    21722170   resources for interest, logging, optimized caching, etc. It also allows
    21732171   obsolete or mistyped links to be traced for maintenance. Some servers use
     
    22672265<t>
    22682266   If the response is being forwarded through a proxy, the proxy
    2269    application &MUST-NOT; modify the Server response-header. Instead, it
     2267   application &MUST-NOT; modify the Server response-header field. Instead, it
    22702268   &MUST; include a Via field (as described in &header-via;).
    22712269</t>
     
    26862684</t>
    26872685<t>
    2688    The Referer header allows reading patterns to be studied and reverse
     2686   The Referer header field allows reading patterns to be studied and reverse
    26892687   links drawn. Although it can be very useful, its power can be abused
    26902688   if user details are not separated from the information contained in
    26912689   the Referer. Even when the personal information has been removed, the
    2692    Referer header might indicate a private document's URI whose
     2690   Referer header field might indicate a private document's URI whose
    26932691   publication would be inappropriate.
    26942692</t>
     
    27152713<t>
    27162714   Some methods, like TRACE (<xref target="TRACE"/>), expose information
    2717    that was sent in request headers within the body of their response.
     2715   that was sent in request header fields within the body of their response.
    27182716   Clients &SHOULD; be careful with sensitive information, like Cookies,
    2719    Authorization credentials and other headers that might be used to
     2717   Authorization credentials and other header fields that might be used to
    27202718   collect data from the client.
    27212719</t>
     
    27502748   If a single server supports multiple organizations that do not trust
    27512749   one another, then it &MUST; check the values of Location and Content-Location
    2752    headers in responses that are generated under control of
     2750   header fields in responses that are generated under control of
    27532751   said organizations to make sure that they do not attempt to
    27542752   invalidate resources over which they have no authority.
     
    32843282</t>
    32853283<t>
    3286   Reclassify Allow header as response header, removing the option to
     3284  Reclassify "Allow" as response header field, removing the option to
    32873285  specify it in a PUT request.
    3288   Relax the server requirement on the contents of the Allow header and
    3289   remove requirement on clients to always trust the header value.
     3286  Relax the server requirement on the contents of the Allow header field and
     3287  remove requirement on clients to always trust the header field value.
    32903288  (<xref target="header.allow"/>)
    32913289</t>
    32923290<t>
    3293   Correct syntax of Location header to allow URI references (including
     3291  Correct syntax of Location header field to allow URI references (including
    32943292  relative references and fragments), as referred symbol "absoluteURI" wasn't
    32953293  what was expected, and add some clarifications as to when use of fragments
     
    32983296</t>
    32993297<t>
    3300   Allow Referer value of "about:blank" as alternative to not specifying it.
     3298  Allow Referer field value of "about:blank" as alternative to not specifying it.
    33013299  (<xref target="header.referer"/>)
    33023300</t>
    33033301<t>
    3304   In the description of the Server header, the Via field
     3302  In the description of the Server header field, the Via field
    33053303  was described as a SHOULD. The requirement was and is stated
    3306   correctly in the description of the Via header in &header-via;.
     3304  correctly in the description of the Via header field in &header-via;.
    33073305  (<xref target="header.server"/>)
    33083306</t>
     
    35113509    <t>
    35123510      Move "Product Tokens" section (back) into Part 1, as "token" is used
    3513       in the definition of the Upgrade header.
     3511      in the definition of the Upgrade header field.
    35143512    </t>
    35153513    <t>
     
    35583556</t>
    35593557<t>
    3560   Ongoing work on IANA Message Header Registration (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/40"/>):
     3558  Ongoing work on IANA Message Header Field Registration (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/40"/>):
    35613559  <list style="symbols">
    35623560    <t>
    3563       Reference RFC 3984, and update header registrations for headers defined
     3561      Reference RFC 3984, and update header field registrations for headers defined
    35643562      in this document.
    35653563    </t>
     
    36313629    <t>
    36323630      Rewrite ABNFs to spell out whitespace rules, factor out
    3633       header value format definitions.
     3631      header field value format definitions.
    36343632    </t>
    36353633  </list>
Note: See TracChangeset for help on using the changeset viewer.