Changeset 2401

Timestamp:

15/09/13 01:06:52 (9 years ago)

Author:

fielding@…

Message:

uniform terminology for header section instead of header block; this and [2400] addresses #234

Location:

draft-ietf-httpbis/latest

Files:

• p1-messaging.html (modified) (7 diffs)
• p1-messaging.xml (modified) (7 diffs)
• p2-semantics.html (modified) (6 diffs)
• p2-semantics.xml (modified) (6 diffs)
• p5-range.html (modified) (6 diffs)
• p5-range.xml (modified) (1 diff)
• p6-cache.html (modified) (1 diff)
• p6-cache.xml (modified) (1 diff)

draft-ietf-httpbis/latest/p1-messaging.html

@@ -1167 +1167 @@
          and the first header field <em class="bcp14">MUST</em> either reject the message as invalid or consume each whitespace-preceded line without further processing of it (i.e., ignore
          the entire line, along with any subsequent lines preceded by whitespace, until a properly formed header field is received
-         or the header block is terminated).
+         or the header section is terminated).
       </p>
       <p id="rfc.section.3.p.7">The presence of such whitespace in a request might be an attempt to trick a server into ignoring that field or processing
@@ -1324 +1324 @@
       </p>
       <h3 id="rfc.section.3.2.5"><a href="#rfc.section.3.2.5">3.2.5</a>&nbsp;<a id="field.limits" href="#field.limits">Field Limits</a></h3>
-      <p id="rfc.section.3.2.5.p.1">HTTP does not place a pre-defined limit on the length of each header field or on the length of the header block as a whole,
+      <p id="rfc.section.3.2.5.p.1">HTTP does not place a pre-defined limit on the length of each header field or on the length of the header section as a whole,
          as described in <a href="#conformance" title="Conformance and Error Handling">Section&nbsp;2.5</a>. Various ad-hoc limitations on individual header field length are found in practice, often depending on the specific field
          semantics.
@@ -1452 +1452 @@
       <p id="rfc.section.3.3.2.p.9">A server <em class="bcp14">MUST NOT</em> send a Content-Length header field in any response with a status code of <a href="p2-semantics.html#status.1xx" class="smpl">1xx (Informational)</a> or <a href="p2-semantics.html#status.204" class="smpl">204 (No Content)</a>. A server <em class="bcp14">MUST NOT</em> send a Content-Length header field in any <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> response to a CONNECT request (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 4.3.6</a> of <a href="#Part2" id="rfc.xref.Part2.17"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>).
       </p>
-      <p id="rfc.section.3.3.2.p.10">Aside from the cases defined above, in the absence of Transfer-Encoding, an origin server <em class="bcp14">SHOULD</em> send a Content-Length header field when the payload body size is known prior to sending the complete header block. This will
-         allow downstream recipients to measure transfer progress, know when a received message is complete, and potentially reuse
+      <p id="rfc.section.3.3.2.p.10">Aside from the cases defined above, in the absence of Transfer-Encoding, an origin server <em class="bcp14">SHOULD</em> send a Content-Length header field when the payload body size is known prior to sending the complete header section. This
+         will allow downstream recipients to measure transfer progress, know when a received message is complete, and potentially reuse
          the connection for additional requests.
       </p>
@@ -1541 +1541 @@
          a supposedly chunked transfer coding fails, <em class="bcp14">MUST</em> record the message as incomplete. Cache requirements for incomplete responses are defined in <a href="p6-cache.html#response.cacheability" title="Storing Responses in Caches">Section 3</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>.
       </p>
-      <p id="rfc.section.3.4.p.3">If a response terminates in the middle of the header block (before the empty line is received) and the status code might rely
-         on header fields to convey the full meaning of the response, then the client cannot assume that meaning has been conveyed;
+      <p id="rfc.section.3.4.p.3">If a response terminates in the middle of the header section (before the empty line is received) and the status code might
+         rely on header fields to convey the full meaning of the response, then the client cannot assume that meaning has been conveyed;
          the client might need to repeat the request in order to determine what action to take next.
       </p>
@@ -1548 +1548 @@
          not been received. A message that uses a valid <a href="#header.content-length" class="smpl">Content-Length</a> is incomplete if the size of the message body received (in octets) is less than the value given by Content-Length. A response
          that has neither chunked transfer coding nor Content-Length is terminated by closure of the connection, and thus is considered
-         complete regardless of the number of message body octets received, provided that the header block was received intact.
+         complete regardless of the number of message body octets received, provided that the header section was received intact.
       </p>
       <h2 id="rfc.section.3.5"><a href="#rfc.section.3.5">3.5</a>&nbsp;<a id="message.robustness" href="#message.robustness">Message Parsing Robustness</a></h2>
@@ -1621 +1621 @@
       <p id="rfc.section.4.1.1.p.1">A trailer allows the sender to include additional fields at the end of a chunked message in order to supply metadata that
          might be dynamically generated while the message body is sent, such as a message integrity check, digital signature, or post-processing
-         status. The trailer fields are identical to header fields, except they are sent in a chunked trailer instead of the message
-         header block.
+         status. The trailer fields are identical to header fields, except they are sent in a chunked trailer instead of the message's
+         header section.
       </p>
       <div id="rfc.figure.u.33"></div><pre class="inline"><span id="rfc.iref.g.75"></span>  <a href="#chunked.trailer.part" class="smpl">trailer-part</a>   = *( <a href="#header.fields" class="smpl">header-field</a> <a href="#core.rules" class="smpl">CRLF</a> )
@@ -2638 +2638 @@
          a Denial of Service against implementations that accept fields with unlimited lengths.
       </p>
-      <p id="rfc.section.9.3.p.2">To promote interoperability, this specification makes specific recommendations for minimum size limits on request-line (<a href="#request.line" title="Request Line">Section&nbsp;3.1.1</a>) and blocks of header fields (<a href="#header.fields" title="Header Fields">Section&nbsp;3.2</a>). These are minimum recommendations, chosen to be supportable even by implementations with limited resources; it is expected
+      <p id="rfc.section.9.3.p.2">To promote interoperability, this specification makes specific recommendations for minimum size limits on request-line (<a href="#request.line" title="Request Line">Section&nbsp;3.1.1</a>) and header fields (<a href="#header.fields" title="Header Fields">Section&nbsp;3.2</a>). These are minimum recommendations, chosen to be supportable even by implementations with limited resources; it is expected
          that most implementations will choose substantially higher limits.
       </p>

draft-ietf-httpbis/latest/p1-messaging.xml

@@ -1072 +1072 @@
    (i.e., ignore the entire line, along with any subsequent lines preceded
    by whitespace, until a properly formed header field is received or the
-   header block is terminated).
+   header section is terminated).
 </t>
 <t>
@@ -1414 +1414 @@
 <t>
    HTTP does not place a pre-defined limit on the length of each header field
-   or on the length of the header block as a whole, as described in
+   or on the length of the header section as a whole, as described in
    <xref target="conformance"/>. Various ad-hoc limitations on individual
    header field length are found in practice, often depending on the specific
@@ -1701 +1701 @@
    Aside from the cases defined above, in the absence of Transfer-Encoding,
    an origin server &SHOULD; send a Content-Length header field when the
-   payload body size is known prior to sending the complete header block.
+   payload body size is known prior to sending the complete header section.
    This will allow downstream recipients to measure transfer progress,
    know when a received message is complete, and potentially reuse the
@@ -1874 +1874 @@
 </t>
 <t>
-   If a response terminates in the middle of the header block (before the
+   If a response terminates in the middle of the header section (before the
    empty line is received) and the status code might rely on header fields to
    convey the full meaning of the response, then the client cannot assume
@@ -1888 +1888 @@
    transfer coding nor Content-Length is terminated by closure of the
    connection, and thus is considered complete regardless of the number of
-   message body octets received, provided that the header block was received
+   message body octets received, provided that the header section was received
    intact.
 </t>
@@ -2032 +2032 @@
    check, digital signature, or post-processing status. The trailer fields are
    identical to header fields, except they are sent in a chunked trailer
-   instead of the message header block.
+   instead of the message's header section.
 </t>
 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="trailer-part"/>
@@ -3822 +3822 @@
    recommendations for minimum size limits on request-line
    (<xref target="request.line"/>)
-   and blocks of header fields (<xref target="header.fields"/>). These are
+   and header fields (<xref target="header.fields"/>). These are
    minimum recommendations, chosen to be supportable even by implementations
    with limited resources; it is expected that most implementations will

draft-ietf-httpbis/latest/p2-semantics.html

@@ -1297 +1297 @@
                <tr>
                   <td class="left">HEAD</td>
-                  <td class="left">Same as GET, but only transfer the status line and header block.</td>
+                  <td class="left">Same as GET, but only transfer the status line and header section.</td>
                   <td class="left"><a href="#HEAD" id="rfc.xref.HEAD.1" title="HEAD">4.3.2</a></td>
                </tr>
@@ -1416 +1416 @@
       <h3 id="rfc.section.4.3.2"><a href="#rfc.section.4.3.2">4.3.2</a>&nbsp;<a id="HEAD" href="#HEAD">HEAD</a></h3>
       <div id="rfc.iref.h.1"></div>
-      <p id="rfc.section.4.3.2.p.1">The HEAD method is identical to GET except that the server <em class="bcp14">MUST NOT</em> send a message body in the response (i.e., the response terminates at the end of the header block). The server <em class="bcp14">SHOULD</em> send the same header fields in response to a HEAD request as it would have sent if the request had been a GET, except that
+      <p id="rfc.section.4.3.2.p.1">The HEAD method is identical to GET except that the server <em class="bcp14">MUST NOT</em> send a message body in the response (i.e., the response terminates at the end of the header section). The server <em class="bcp14">SHOULD</em> send the same header fields in response to a HEAD request as it would have sent if the request had been a GET, except that
          the payload header fields (<a href="#payload" title="Payload Semantics">Section&nbsp;3.3</a>) <em class="bcp14">MAY</em> be omitted. This method can be used for obtaining metadata about the selected representation without transferring the representation
          data and is often used for testing hypertext links for validity, accessibility, and recent modification.
@@ -1561 +1561 @@
 </pre><p id="rfc.section.4.3.6.p.5">The recipient proxy can establish a tunnel either by directly connecting to the request-target or, if configured to use another
          proxy, by forwarding the CONNECT request to the next inbound proxy. Any <a href="#status.2xx" class="smpl">2xx (Successful)</a> response indicates that the sender (and all inbound proxies) will switch to tunnel mode immediately after the blank line that
-         concludes the successful response's header block; data received after that blank line is from the server identified by the
+         concludes the successful response's header section; data received after that blank line is from the server identified by the
          request-target. Any response other than a successful response indicates that the tunnel has not yet been formed and that the
          connection remains governed by HTTP.
@@ -2417 +2417 @@
       <p id="rfc.section.6.2.p.1">The <dfn>1xx (Informational)</dfn> class of status code indicates an interim response for communicating connection status or request progress prior to completing
          the requested action and sending a final response. All 1xx responses consist of only the status-line and optional header fields,
-         and thus are terminated by the empty line at the end of the header block. Since HTTP/1.0 did not define any 1xx status codes,
+         and thus are terminated by the empty line at the end of the header section. Since HTTP/1.0 did not define any 1xx status codes,
          servers <em class="bcp14">MUST NOT</em> send a 1xx response to an HTTP/1.0 client except under experimental conditions.
       </p>
@@ -2470 +2470 @@
       </dl>
       <p id="rfc.section.6.3.1.p.2">Aside from responses to CONNECT, a 200 response always has a payload, though an origin server <em class="bcp14">MAY</em> generate a payload body of zero length. If no payload is desired, an origin server ought to send <dfn>204 (No Content)</dfn> instead. For CONNECT, no payload is allowed because the successful result is a tunnel, which begins immediately after the
-         200 response header block.
+         200 response header section.
       </p>
       <p id="rfc.section.6.3.1.p.3">A 200 response is cacheable unless otherwise indicated by the method definition or explicit cache controls (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.2.2</a> of <a href="#Part6" id="rfc.xref.Part6.11"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).
@@ -2987 +2987 @@
          in Coordinated Universal Time. An origin server <em class="bcp14">MAY</em> send a Date header field if the response is in the <a href="#status.1xx" class="smpl">1xx (Informational)</a> or <a href="#status.5xx" class="smpl">5xx (Server Error)</a> class of status codes. An origin server <em class="bcp14">MUST</em> send a Date header field in all other cases.
       </p>
-      <p id="rfc.section.7.1.1.2.p.7">A recipient with a clock that receives a response message without a Date header field <em class="bcp14">MUST</em> record the time it was received and append a corresponding Date header field to the message's header block if it is cached
+      <p id="rfc.section.7.1.1.2.p.7">A recipient with a clock that receives a response message without a Date header field <em class="bcp14">MUST</em> record the time it was received and append a corresponding Date header field to the message's header section if it is cached
          or forwarded downstream.
       </p>

draft-ietf-httpbis/latest/p2-semantics.xml

@@ -1131 +1131 @@
    <c><xref target="GET" format="counter"/></c>
    <c>HEAD</c>
-   <c>Same as GET, but only transfer the status line and header block.</c>
+   <c>Same as GET, but only transfer the status line and header section.</c>
    <c><xref target="HEAD" format="counter"/></c>
    <c>POST</c>
@@ -1335 +1335 @@
    The HEAD method is identical to GET except that the server &MUST-NOT;
    send a message body in the response (i.e., the response terminates at the
-   end of the header block). The server &SHOULD; send the same header fields
+   end of the header section). The server &SHOULD; send the same header fields
    in response to a HEAD request as it would have sent if the request had been
    a GET, except that the payload header fields (<xref target="payload"/>)
@@ -1639 +1639 @@
    that the sender (and all inbound proxies) will switch to tunnel mode
    immediately after the blank line that concludes the successful response's
-   header block; data received after that blank line is from the server
+   header section; data received after that blank line is from the server
    identified by the request-target.
    Any response other than a successful response indicates that the tunnel
@@ -2724 +2724 @@
    All 1xx responses consist of only the status-line and optional header
    fields, and thus are terminated by the empty line at the end of the header
-   block.
+   section.
    Since HTTP/1.0 did not define any 1xx status codes, servers &MUST-NOT; send
    a 1xx response to an HTTP/1.0 client except under experimental conditions.
@@ -2832 +2832 @@
    <x:dfn>204 (No Content)</x:dfn> instead.
    For CONNECT, no payload is allowed because the successful result is a
-   tunnel, which begins immediately after the 200 response header block.
+   tunnel, which begins immediately after the 200 response header section.
 </t>
 <t>
@@ -3858 +3858 @@
    A recipient with a clock that receives a response message without a Date
    header field &MUST; record the time it was received and append a
-   corresponding Date header field to the message's header block if it is
+   corresponding Date header field to the message's header section if it is
    cached or forwarded downstream.
 </t>

draft-ietf-httpbis/latest/p5-range.html

@@ -446 +446 @@
   }
   @bottom-center {
-       content: "Expires March 17, 2014";
+       content: "Expires March 18, 2014";
   }
   @bottom-right {
@@ -489 +489 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p5-range-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2013-09-13">
+      <meta name="dct.issued" scheme="ISO8601" content="2013-09-14">
       <meta name="dct.replaces" content="urn:ietf:rfc:2616">
       <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines range requests and the rules for constructing and combining responses to those requests.">
@@ -515 +515 @@
             </tr>
             <tr>
-               <td class="left">Expires: March 17, 2014</td>
+               <td class="left">Expires: March 18, 2014</td>
                <td class="right">J. Reschke, Editor</td>
             </tr>
@@ -524 +524 @@
             <tr>
                <td class="left"></td>
-               <td class="right">September 13, 2013</td>
+               <td class="right">September 14, 2013</td>
             </tr>
          </tbody>
@@ -549 +549 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on March 17, 2014.</p>
+      <p>This Internet-Draft will expire on March 18, 2014.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -801 +801 @@
 ... 26012 bytes of partial image data ...
 </pre><p id="rfc.section.4.1.p.4">If multiple parts are being transferred, the server generating the 206 response <em class="bcp14">MUST</em> generate a "multipart/byteranges" payload, as defined in <a href="#internet.media.type.multipart.byteranges" title="Internet Media Type multipart/byteranges">Appendix&nbsp;A</a>, and a <a href="p2-semantics.html#header.content-type" class="smpl">Content-Type</a> header field containing the multipart/byteranges media type and its required boundary parameter. To avoid confusion with single
-         part responses, a server <em class="bcp14">MUST NOT</em> generate a <a href="#header.content-range" class="smpl">Content-Range</a> header field in the HTTP header block of a multiple part response (this field will be sent in each part instead).
+         part responses, a server <em class="bcp14">MUST NOT</em> generate a <a href="#header.content-range" class="smpl">Content-Range</a> header field in the HTTP header section of a multiple part response (this field will be sent in each part instead).
       </p>
       <p id="rfc.section.4.1.p.5">Within the header area of each body part in the multipart payload, the server <em class="bcp14">MUST</em> generate a <a href="#header.content-range" class="smpl">Content-Range</a> header field corresponding to the range being enclosed in that body part. If the selected representation would have had a <a href="p2-semantics.html#header.content-type" class="smpl">Content-Type</a> header field in a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response, the server <em class="bcp14">SHOULD</em> generate that same <a href="p2-semantics.html#header.content-type" class="smpl">Content-Type</a> field in the header area of each body part. For example:

draft-ietf-httpbis/latest/p5-range.xml

@@ -536 +536 @@
    multipart/byteranges media type and its required boundary parameter.
    To avoid confusion with single part responses, a server &MUST-NOT; generate
-   a <x:ref>Content-Range</x:ref> header field in the HTTP header block of a
+   a <x:ref>Content-Range</x:ref> header field in the HTTP header section of a
    multiple part response (this field will be sent in each part instead).
 </t>

draft-ietf-httpbis/latest/p6-cache.html

@@ -779 +779 @@
       </p>
       <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a>&nbsp;<a id="incomplete.responses" href="#incomplete.responses">Storing Incomplete Responses</a></h2>
-      <p id="rfc.section.3.1.p.1">A response message is considered complete when all of the octets indicated by the message framing (<a href="#Part1" id="rfc.xref.Part1.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) are received prior to the connection being closed. If the request method is GET, the response status code is <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a>, and the entire response header block has been received, a cache <em class="bcp14">MAY</em> store an incomplete response message body if the cache entry is recorded as incomplete. Likewise, a <a href="p5-range.html#status.206" class="smpl">206 (Partial Content)</a> response <em class="bcp14">MAY</em> be stored as if it were an incomplete <a href="p2-semantics.html#status.200" class="smpl">200
+      <p id="rfc.section.3.1.p.1">A response message is considered complete when all of the octets indicated by the message framing (<a href="#Part1" id="rfc.xref.Part1.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) are received prior to the connection being closed. If the request method is GET, the response status code is <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a>, and the entire response header section has been received, a cache <em class="bcp14">MAY</em> store an incomplete response message body if the cache entry is recorded as incomplete. Likewise, a <a href="p5-range.html#status.206" class="smpl">206 (Partial Content)</a> response <em class="bcp14">MAY</em> be stored as if it were an incomplete <a href="p2-semantics.html#status.200" class="smpl">200
             (OK)</a> cache entry. However, a cache <em class="bcp14">MUST NOT</em> store incomplete or partial content responses if it does not support the <a href="p5-range.html#header.range" class="smpl">Range</a> and <a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> header fields or if it does not understand the range units used in those fields.
       </p>

draft-ietf-httpbis/latest/p6-cache.xml

@@ -323 +323 @@
    by the message framing (&messaging;) are received prior to the connection
    being closed. If the request method is GET, the response status code is
-   <x:ref>200 (OK)</x:ref>, and the entire response header block has been received, a
+   <x:ref>200 (OK)</x:ref>, and the entire response header section has been received, a
    cache &MAY; store an incomplete response message body if the cache entry is
    recorded as incomplete. Likewise, a <x:ref>206 (Partial Content)</x:ref>