Changeset 2401 for draft-ietf-httpbis


Ignore:
Timestamp:
15/09/13 01:06:52 (7 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:
8 edited

Legend:

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

    r2400 r2401  
    11671167         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
    11681168         the entire line, along with any subsequent lines preceded by whitespace, until a properly formed header field is received
    1169          or the header block is terminated).
     1169         or the header section is terminated).
    11701170      </p>
    11711171      <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
     
    13241324      </p>
    13251325      <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>
    1326       <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,
     1326      <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,
    13271327         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
    13281328         semantics.
     
    14521452      <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>).
    14531453      </p>
    1454       <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
    1455          allow downstream recipients to measure transfer progress, know when a received message is complete, and potentially reuse
     1454      <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
     1455         will allow downstream recipients to measure transfer progress, know when a received message is complete, and potentially reuse
    14561456         the connection for additional requests.
    14571457      </p>
     
    15411541         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>.
    15421542      </p>
    1543       <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
    1544          on header fields to convey the full meaning of the response, then the client cannot assume that meaning has been conveyed;
     1543      <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
     1544         rely on header fields to convey the full meaning of the response, then the client cannot assume that meaning has been conveyed;
    15451545         the client might need to repeat the request in order to determine what action to take next.
    15461546      </p>
     
    15481548         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
    15491549         that has neither chunked transfer coding nor Content-Length is terminated by closure of the connection, and thus is considered
    1550          complete regardless of the number of message body octets received, provided that the header block was received intact.
     1550         complete regardless of the number of message body octets received, provided that the header section was received intact.
    15511551      </p>
    15521552      <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>
     
    16211621      <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
    16221622         might be dynamically generated while the message body is sent, such as a message integrity check, digital signature, or post-processing
    1623          status. The trailer fields are identical to header fields, except they are sent in a chunked trailer instead of the message
    1624          header block.
     1623         status. The trailer fields are identical to header fields, except they are sent in a chunked trailer instead of the message's
     1624         header section.
    16251625      </p>
    16261626      <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> )
     
    26382638         a Denial of Service against implementations that accept fields with unlimited lengths.
    26392639      </p>
    2640       <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
     2640      <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
    26412641         that most implementations will choose substantially higher limits.
    26422642      </p>
  • draft-ietf-httpbis/latest/p1-messaging.xml

    r2400 r2401  
    10721072   (i.e., ignore the entire line, along with any subsequent lines preceded
    10731073   by whitespace, until a properly formed header field is received or the
    1074    header block is terminated).
     1074   header section is terminated).
    10751075</t>
    10761076<t>
     
    14141414<t>
    14151415   HTTP does not place a pre-defined limit on the length of each header field
    1416    or on the length of the header block as a whole, as described in
     1416   or on the length of the header section as a whole, as described in
    14171417   <xref target="conformance"/>. Various ad-hoc limitations on individual
    14181418   header field length are found in practice, often depending on the specific
     
    17011701   Aside from the cases defined above, in the absence of Transfer-Encoding,
    17021702   an origin server &SHOULD; send a Content-Length header field when the
    1703    payload body size is known prior to sending the complete header block.
     1703   payload body size is known prior to sending the complete header section.
    17041704   This will allow downstream recipients to measure transfer progress,
    17051705   know when a received message is complete, and potentially reuse the
     
    18741874</t>
    18751875<t>
    1876    If a response terminates in the middle of the header block (before the
     1876   If a response terminates in the middle of the header section (before the
    18771877   empty line is received) and the status code might rely on header fields to
    18781878   convey the full meaning of the response, then the client cannot assume
     
    18881888   transfer coding nor Content-Length is terminated by closure of the
    18891889   connection, and thus is considered complete regardless of the number of
    1890    message body octets received, provided that the header block was received
     1890   message body octets received, provided that the header section was received
    18911891   intact.
    18921892</t>
     
    20322032   check, digital signature, or post-processing status. The trailer fields are
    20332033   identical to header fields, except they are sent in a chunked trailer
    2034    instead of the message header block.
     2034   instead of the message's header section.
    20352035</t>
    20362036<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="trailer-part"/>
     
    38223822   recommendations for minimum size limits on request-line
    38233823   (<xref target="request.line"/>)
    3824    and blocks of header fields (<xref target="header.fields"/>). These are
     3824   and header fields (<xref target="header.fields"/>). These are
    38253825   minimum recommendations, chosen to be supportable even by implementations
    38263826   with limited resources; it is expected that most implementations will
  • draft-ietf-httpbis/latest/p2-semantics.html

    r2400 r2401  
    12971297               <tr>
    12981298                  <td class="left">HEAD</td>
    1299                   <td class="left">Same as GET, but only transfer the status line and header block.</td>
     1299                  <td class="left">Same as GET, but only transfer the status line and header section.</td>
    13001300                  <td class="left"><a href="#HEAD" id="rfc.xref.HEAD.1" title="HEAD">4.3.2</a></td>
    13011301               </tr>
     
    14161416      <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>
    14171417      <div id="rfc.iref.h.1"></div>
    1418       <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
     1418      <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
    14191419         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
    14201420         data and is often used for testing hypertext links for validity, accessibility, and recent modification.
     
    15611561</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
    15621562         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
    1563          concludes the successful response's header block; data received after that blank line is from the server identified by the
     1563         concludes the successful response's header section; data received after that blank line is from the server identified by the
    15641564         request-target. Any response other than a successful response indicates that the tunnel has not yet been formed and that the
    15651565         connection remains governed by HTTP.
     
    24172417      <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
    24182418         the requested action and sending a final response. All 1xx responses consist of only the status-line and optional header fields,
    2419          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,
     2419         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,
    24202420         servers <em class="bcp14">MUST NOT</em> send a 1xx response to an HTTP/1.0 client except under experimental conditions.
    24212421      </p>
     
    24702470      </dl>
    24712471      <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
    2472          200 response header block.
     2472         200 response header section.
    24732473      </p>
    24742474      <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>).
     
    29872987         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.
    29882988      </p>
    2989       <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
     2989      <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
    29902990         or forwarded downstream.
    29912991      </p>
  • draft-ietf-httpbis/latest/p2-semantics.xml

    r2400 r2401  
    11311131   <c><xref target="GET" format="counter"/></c>
    11321132   <c>HEAD</c>
    1133    <c>Same as GET, but only transfer the status line and header block.</c>
     1133   <c>Same as GET, but only transfer the status line and header section.</c>
    11341134   <c><xref target="HEAD" format="counter"/></c>
    11351135   <c>POST</c>
     
    13351335   The HEAD method is identical to GET except that the server &MUST-NOT;
    13361336   send a message body in the response (i.e., the response terminates at the
    1337    end of the header block). The server &SHOULD; send the same header fields
     1337   end of the header section). The server &SHOULD; send the same header fields
    13381338   in response to a HEAD request as it would have sent if the request had been
    13391339   a GET, except that the payload header fields (<xref target="payload"/>)
     
    16391639   that the sender (and all inbound proxies) will switch to tunnel mode
    16401640   immediately after the blank line that concludes the successful response's
    1641    header block; data received after that blank line is from the server
     1641   header section; data received after that blank line is from the server
    16421642   identified by the request-target.
    16431643   Any response other than a successful response indicates that the tunnel
     
    27242724   All 1xx responses consist of only the status-line and optional header
    27252725   fields, and thus are terminated by the empty line at the end of the header
    2726    block.
     2726   section.
    27272727   Since HTTP/1.0 did not define any 1xx status codes, servers &MUST-NOT; send
    27282728   a 1xx response to an HTTP/1.0 client except under experimental conditions.
     
    28322832   <x:dfn>204 (No Content)</x:dfn> instead.
    28332833   For CONNECT, no payload is allowed because the successful result is a
    2834    tunnel, which begins immediately after the 200 response header block.
     2834   tunnel, which begins immediately after the 200 response header section.
    28352835</t>
    28362836<t>
     
    38583858   A recipient with a clock that receives a response message without a Date
    38593859   header field &MUST; record the time it was received and append a
    3860    corresponding Date header field to the message's header block if it is
     3860   corresponding Date header field to the message's header section if it is
    38613861   cached or forwarded downstream.
    38623862</t>
  • draft-ietf-httpbis/latest/p5-range.html

    r2378 r2401  
    446446  }
    447447  @bottom-center {
    448        content: "Expires March 17, 2014";
     448       content: "Expires March 18, 2014";
    449449  }
    450450  @bottom-right {
     
    489489      <meta name="dct.creator" content="Reschke, J. F.">
    490490      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p5-range-latest">
    491       <meta name="dct.issued" scheme="ISO8601" content="2013-09-13">
     491      <meta name="dct.issued" scheme="ISO8601" content="2013-09-14">
    492492      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    493493      <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.">
     
    515515            </tr>
    516516            <tr>
    517                <td class="left">Expires: March 17, 2014</td>
     517               <td class="left">Expires: March 18, 2014</td>
    518518               <td class="right">J. Reschke, Editor</td>
    519519            </tr>
     
    524524            <tr>
    525525               <td class="left"></td>
    526                <td class="right">September 13, 2013</td>
     526               <td class="right">September 14, 2013</td>
    527527            </tr>
    528528         </tbody>
     
    549549         in progress”.
    550550      </p>
    551       <p>This Internet-Draft will expire on March 17, 2014.</p>
     551      <p>This Internet-Draft will expire on March 18, 2014.</p>
    552552      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    553553      <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    801801... 26012 bytes of partial image data ...
    802802</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
    803          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).
     803         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).
    804804      </p>
    805805      <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

    r2378 r2401  
    536536   multipart/byteranges media type and its required boundary parameter.
    537537   To avoid confusion with single part responses, a server &MUST-NOT; generate
    538    a <x:ref>Content-Range</x:ref> header field in the HTTP header block of a
     538   a <x:ref>Content-Range</x:ref> header field in the HTTP header section of a
    539539   multiple part response (this field will be sent in each part instead).
    540540</t>
  • draft-ietf-httpbis/latest/p6-cache.html

    r2400 r2401  
    779779      </p>
    780780      <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>
    781       <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
     781      <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
    782782            (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.
    783783      </p>
  • draft-ietf-httpbis/latest/p6-cache.xml

    r2400 r2401  
    323323   by the message framing (&messaging;) are received prior to the connection
    324324   being closed. If the request method is GET, the response status code is
    325    <x:ref>200 (OK)</x:ref>, and the entire response header block has been received, a
     325   <x:ref>200 (OK)</x:ref>, and the entire response header section has been received, a
    326326   cache &MAY; store an incomplete response message body if the cache entry is
    327327   recorded as incomplete. Likewise, a <x:ref>206 (Partial Content)</x:ref>
Note: See TracChangeset for help on using the changeset viewer.