Ignore:
Timestamp:
07/09/10 11:46:12 (10 years ago)
Author:
julian.reschke@…
Message:

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

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p1-messaging.xml

    r992 r994  
    11991199<x:note>
    12001200  <t>
    1201    <x:h>Note:</x:h> The "Set-Cookie" header as implemented in
     1201   <x:h>Note:</x:h> The "Set-Cookie" header field as implemented in
    12021202   practice (as opposed to how it is specified in <xref target="RFC2109"/>)
    12031203   can occur multiple times, but does not use the list syntax, and thus cannot
    12041204   be combined into a single line. (See Appendix A.2.3 of <xref target="Kri2001"/>
    1205    for details.) Also note that the Set-Cookie2 header specified in
     1205   for details.) Also note that the Set-Cookie2 header field specified in
    12061206   <xref target="RFC2965"/> does not share this problem.
    12071207  </t>
     
    22632263  <x:anchor-alias value="qvalue"/>
    22642264<t>
    2265    Both transfer codings (TE request header, <xref target="header.te"/>)
     2265   Both transfer codings (TE request header field, <xref target="header.te"/>)
    22662266   and content negotiation (&content.negotiation;) use short "floating point"
    22672267   numbers to indicate the relative importance ("weight") of various
     
    23622362<t>
    23632363   An HTTP/1.1 server &MAY; assume that a HTTP/1.1 client intends to
    2364    maintain a persistent connection unless a Connection header including
     2364   maintain a persistent connection unless a Connection header field including
    23652365   the connection-token "close" was sent in the request. If the server
    23662366   chooses to close the connection immediately after sending the
    2367    response, it &SHOULD; send a Connection header including the
     2367   response, it &SHOULD; send a Connection header field including the
    23682368   connection-token "close".
    23692369</t>
     
    23712371   An HTTP/1.1 client &MAY; expect a connection to remain open, but would
    23722372   decide to keep it open based on whether the response from a server
    2373    contains a Connection header with the connection-token close. In case
     2373   contains a Connection header field with the connection-token close. In case
    23742374   the client does not want to maintain a connection for more than that
    2375    request, it &SHOULD; send a Connection header including the
     2375   request, it &SHOULD; send a Connection header field including the
    23762376   connection-token close.
    23772377</t>
    23782378<t>
    23792379   If either the client or the server sends the close token in the
    2380    Connection header, that request becomes the last one for the
     2380   Connection header field, that request becomes the last one for the
    23812381   connection.
    23822382</t>
     
    24352435   A proxy server &MUST-NOT; establish a HTTP/1.1 persistent connection
    24362436   with an HTTP/1.0 client (but see <xref x:sec="19.7.1" x:fmt="of" target="RFC2068"/>
    2437    for information and discussion of the problems with the Keep-Alive header
     2437   for information and discussion of the problems with the Keep-Alive header field
    24382438   implemented by many HTTP/1.0 clients).
    24392439</t>
    24402440
    2441 <section title="End-to-end and Hop-by-hop Headers" anchor="end-to-end.and.hop-by-hop.headers">
     2441<section title="End-to-end and Hop-by-hop Header Fields" anchor="end-to-end.and.hop-by-hop.header-fields">
    24422442<!--<t>
    24432443  <cref anchor="TODO-end-to-end" source="jre">
     
    24482448<t>
    24492449   For the purpose of defining the behavior of caches and non-caching
    2450    proxies, we divide HTTP headers into two categories:
     2450   proxies, we divide HTTP header fields into two categories:
    24512451  <list style="symbols">
    2452       <t>End-to-end headers, which are  transmitted to the ultimate
    2453         recipient of a request or response. End-to-end headers in
     2452      <t>End-to-end header fields, which are  transmitted to the ultimate
     2453        recipient of a request or response. End-to-end header fields in
    24542454        responses MUST be stored as part of a cache entry and &MUST; be
    24552455        transmitted in any response formed from a cache entry.</t>
    24562456
    2457       <t>Hop-by-hop headers, which are meaningful only for a single
     2457      <t>Hop-by-hop header fields, which are meaningful only for a single
    24582458        transport-level connection, and are not stored by caches or
    24592459        forwarded by proxies.</t>
     
    24612461</t>
    24622462<t>
    2463    The following HTTP/1.1 headers are hop-by-hop headers:
     2463   The following HTTP/1.1 header fields are hop-by-hop header fields:
    24642464  <list style="symbols">
    24652465      <t>Connection</t>
     
    24742474</t>
    24752475<t>
    2476    All other headers defined by HTTP/1.1 are end-to-end headers.
    2477 </t>
    2478 <t>
    2479    Other hop-by-hop headers &MUST; be listed in a Connection header
     2476   All other header fields defined by HTTP/1.1 are end-to-end header fields.
     2477</t>
     2478<t>
     2479   Other hop-by-hop header fields &MUST; be listed in a Connection header field
    24802480   (<xref target="header.connection"/>).
    24812481</t>
    24822482</section>
    24832483
    2484 <section title="Non-modifiable Headers" anchor="non-modifiable.headers">
     2484<section title="Non-modifiable Header Fields" anchor="non-modifiable.header-fields">
    24852485<!--<t>
    24862486  <cref anchor="TODO-non-mod-headers" source="jre">
     
    24912491<t>
    24922492   Some features of HTTP/1.1, such as Digest Authentication, depend on the
    2493    value of certain end-to-end headers. A transparent proxy &SHOULD-NOT;
    2494    modify an end-to-end header unless the definition of that header requires
     2493   value of certain end-to-end header fields. A transparent proxy &SHOULD-NOT;
     2494   modify an end-to-end header field unless the definition of that header field requires
    24952495   or specifically allows that.
    24962496</t>
     
    25152515<t>
    25162516   but it &MAY; add any of these fields if not already present. If an
    2517    Expires header is added, it &MUST; be given a field-value identical to
    2518    that of the Date header in that response.
     2517   Expires header field is added, it &MUST; be given a field-value identical to
     2518   that of the Date header field in that response.
    25192519</t>
    25202520<t>
     
    25362536<x:note>
    25372537  <t>
    2538     <x:h>Warning:</x:h> Unnecessary modification of end-to-end headers might
     2538    <x:h>Warning:</x:h> Unnecessary modification of end-to-end header fields might
    25392539    cause authentication failures if stronger authentication
    25402540    mechanisms are introduced in later versions of HTTP. Such
     
    26402640   using a "chunked" encoding (<xref target="transfer.codings"/>), a zero length chunk and
    26412641   empty trailer &MAY; be used to prematurely mark the end of the message.
    2642    If the body was preceded by a Content-Length header, the client &MUST;
     2642   If the body was preceded by a Content-Length header field, the client &MUST;
    26432643   close the connection.
    26442644</t>
     
    26502650   allow a client that is sending a request message with a request body
    26512651   to determine if the origin server is willing to accept the request
    2652    (based on the request headers) before the client sends the request
     2652   (based on the request header fields) before the client sends the request
    26532653   body. In some cases, it might either be inappropriate or highly
    26542654   inefficient for the client to send the body if the server will reject
     
    27712771    </t>
    27722772    <t>
    2773       Transmit the request-headers
     2773      Transmit the request-header fields
    27742774    </t>
    27752775    <t>
     
    28642864</t>
    28652865<t>
    2866    The Connection header's value has the following grammar:
     2866   The Connection header field's value has the following grammar:
    28672867</t>
    28682868<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Connection"/><iref primary="true" item="Grammar" subitem="Connection-v"/><iref primary="true" item="Grammar" subitem="connection-token"/>
     
    28822882</t>
    28832883<t>
    2884    Message headers listed in the Connection header &MUST-NOT; include
    2885    end-to-end headers, such as Cache-Control.
     2884   Message header fields listed in the Connection header field &MUST-NOT; include
     2885   end-to-end header fields, such as Cache-Control.
    28862886</t>
    28872887<t>
     
    29092909<t>
    29102910   A system receiving an HTTP/1.0 (or lower-version) message that
    2911    includes a Connection header &MUST;, for each connection-token in this
     2911   includes a Connection header field &MUST;, for each connection-token in this
    29122912   field, remove and ignore any header field(s) from the message with
    29132913   the same name as the connection-token. This protects against mistaken
     
    30153015</t>
    30163016<t>
    3017    The HTTP-date sent in a Date header &SHOULD-NOT;  represent a date and
     3017   The HTTP-date sent in a Date header field &SHOULD-NOT;  represent a date and
    30183018   time subsequent to the generation of the message. It &SHOULD; represent
    30193019   the best available approximation of the date and time of message
     
    32393239<t>
    32403240   Many older HTTP/1.0 applications do not understand the Transfer-Encoding
    3241    header.
     3241   header field.
    32423242</t>
    32433243</section>
     
    46864686<t>
    46874687   The line terminator for header fields is the sequence CRLF.
    4688    However, we recommend that applications, when parsing such headers,
     4688   However, we recommend that applications, when parsing such headers fields,
    46894689   recognize a single LF as a line terminator and ignore the leading CR.
    46904690</t>
     
    47184718        of an age or expiration time.</t>
    47194719
    4720      <t>If an HTTP header incorrectly carries a date value with a time
     4720     <t>If an HTTP header field incorrectly carries a date value with a time
    47214721        zone other than GMT, it &MUST; be converted into GMT using the
    47224722        most conservative possible conversion.</t>
     
    47844784<section title="Changes to Simplify Multi-homed Web Servers and Conserve IP Addresses" anchor="changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses">
    47854785<t>
    4786    The requirements that clients and servers support the Host request-header,
    4787    report an error if the Host request-header (<xref target="header.host"/>) is
     4786   The requirements that clients and servers support the Host request-header
     4787   field (<xref target="header.host"/>), report an error if it is
    47884788   missing from an HTTP/1.1 request, and accept absolute URIs (<xref target="request-target"/>)
    47894789   are among the most important changes defined by this
     
    48074807   requirements:
    48084808  <list style="symbols">
    4809      <t>Both clients and servers &MUST; support the Host request-header.</t>
    4810 
    4811      <t>A client that sends an HTTP/1.1 request &MUST; send a Host header.</t>
     4809     <t>Both clients and servers &MUST; support the Host request-header field.</t>
     4810
     4811     <t>A client that sends an HTTP/1.1 request &MUST; send a Host header field.</t>
    48124812
    48134813     <t>Servers &MUST; report a 400 (Bad Request) error if an HTTP/1.1
    4814         request does not include a Host request-header.</t>
     4814        request does not include a Host request-header field.</t>
    48154815
    48164816     <t>Servers &MUST; accept absolute URIs.</t>
     
    48474847<t>
    48484848   The original HTTP/1.0 form of persistent connections (the Connection:
    4849    Keep-Alive and Keep-Alive header) is documented in <xref x:sec="19.7.1" x:fmt="of" target="RFC2068"/>.
     4849   Keep-Alive and Keep-Alive header field) is documented in <xref x:sec="19.7.1" x:fmt="of" target="RFC2068"/>.
    48504850</t>
    48514851</section>
     
    52735273    <t>
    52745274      Move "Product Tokens" section (back) into Part 1, as "token" is used
    5275       in the definition of the Upgrade header.
     5275      in the definition of the Upgrade header field.
    52765276    </t>
    52775277    <t>
     
    53005300</t>
    53015301<t>
    5302   Ongoing work on IANA Message Header Registration (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/40"/>):
     5302  Ongoing work on IANA Message Header Field Registration (<eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/40"/>):
    53035303  <list style="symbols">
    53045304    <t>
    5305       Reference RFC 3984, and update header registrations for headers defined
     5305      Reference RFC 3984, and update header field registrations for headers defined
    53065306      in this document.
    53075307    </t>
     
    53935393    <t>
    53945394      Rewrite ABNFs to spell out whitespace rules, factor out
    5395       header value format definitions.
     5395      header field value format definitions.
    53965396    </t>
    53975397  </list>
     
    54645464    <t>
    54655465      Move definition of quality values from Part 3 into Part 1;
    5466       make TE request header grammar independent of accept-params (defined in Part 3).
     5466      make TE request header field grammar independent of accept-params (defined in Part 3).
    54675467    </t>
    54685468  </list>
Note: See TracChangeset for help on using the changeset viewer.