Changeset 1910


Ignore:
Timestamp:
Sep 21, 2012, 11:35:14 PM (7 years ago)
Author:
fielding@…
Message:

(editorial) be more consistent when referring to a "body", preferring the
defined terms for message (body), payload (body), and representation (data).

Location:
draft-ietf-httpbis/latest
Files:
8 edited

Legend:

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

    r1908 r1910  
    18821882         except as noted above to replace an empty path with "/" or "*".
    18831883      </p>
    1884       <p id="rfc.section.5.8.p.3">A non-transforming proxy <em class="bcp14">MUST</em> preserve the message payload (<a href="p2-semantics.html#payload" title="Message Payload">Section 3.1</a> of <a href="#Part2" id="rfc.xref.Part2.20"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>), though it <em class="bcp14">MAY</em> change the message body through application or removal of a transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;4</a>).
     1884      <p id="rfc.section.5.8.p.3">A non-transforming proxy <em class="bcp14">MUST</em> preserve the message payload (<a href="p2-semantics.html#payload" title="Message Payload">Section 3.4</a> of <a href="#Part2" id="rfc.xref.Part2.20"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>), though it <em class="bcp14">MAY</em> change the message body through application or removal of a transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section&nbsp;4</a>).
    18851885      </p>
    18861886      <p id="rfc.section.5.8.p.4">A non-transforming proxy <em class="bcp14">SHOULD NOT</em> modify header fields that provide information about the end points of the communication chain, the resource state, or the
     
    18921892         <li><a href="p2-semantics.html#header.allow" class="smpl">Allow</a> (<a href="p2-semantics.html#header.allow" title="Allow">Section 7.4.1</a> of <a href="#Part2" id="rfc.xref.Part2.21"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>)
    18931893         </li>
    1894          <li><a href="p2-semantics.html#header.content-location" class="smpl">Content-Location</a> (<a href="p2-semantics.html#header.content-location" title="Content-Location">Section 3.2.4</a> of <a href="#Part2" id="rfc.xref.Part2.22"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>)
     1894         <li><a href="p2-semantics.html#header.content-location" class="smpl">Content-Location</a> (<a href="p2-semantics.html#header.content-location" title="Content-Location">Section 3.1.4</a> of <a href="#Part2" id="rfc.xref.Part2.22"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>)
    18951895         </li>
    18961896         <li>Content-MD5 (<a href="http://tools.ietf.org/html/rfc2616#section-14.15">Section 14.15</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>)
     
    19081908      </p>
    19091909      <ul>
    1910          <li><a href="p2-semantics.html#header.content-encoding" class="smpl">Content-Encoding</a> (<a href="p2-semantics.html#header.content-encoding" title="Content-Encoding">Section 3.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.24"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>)
     1910         <li><a href="p2-semantics.html#header.content-encoding" class="smpl">Content-Encoding</a> (<a href="p2-semantics.html#header.content-encoding" title="Content-Encoding">Section 3.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.24"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>)
    19111911         </li>
    19121912         <li><a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> (<a href="p5-range.html#header.content-range" title="Content-Range">Section 5.2</a> of <a href="#Part5" id="rfc.xref.Part5.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a>)
    19131913         </li>
    1914          <li><a href="p2-semantics.html#header.content-type" class="smpl">Content-Type</a> (<a href="p2-semantics.html#header.content-type" title="Content-Type">Section 3.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.25"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>)
     1914         <li><a href="p2-semantics.html#header.content-type" class="smpl">Content-Type</a> (<a href="p2-semantics.html#header.content-type" title="Content-Type">Section 3.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.25"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>)
    19151915         </li>
    19161916      </ul>
     
    32253225      <p id="rfc.section.D.8.p.2">Partly resolved issues: </p>
    32263226      <ul>
    3227          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/88">http://tools.ietf.org/wg/httpbis/trac/ticket/88</a>&gt;: "205 Bodies" (took out language that implied that there might be methods for which a request body MUST NOT be included)
     3227         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/88">http://tools.ietf.org/wg/httpbis/trac/ticket/88</a>&gt;: "205 Bodies" (took out language that implied that there might be methods for which a payload body MUST NOT be included)
    32283228         </li>
    32293229         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/163">http://tools.ietf.org/wg/httpbis/trac/ticket/163</a>&gt;: "editorial improvements around HTTP-date"
     
    36383638                  <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">1</a>, <a href="#rfc.xref.Part2.2">2.1</a>, <a href="#rfc.xref.Part2.3">2.3</a>, <a href="#rfc.xref.Part2.4">2.7</a>, <a href="#rfc.xref.Part2.5">2.7.1</a>, <a href="#rfc.xref.Part2.6">3.1.1</a>, <a href="#rfc.xref.Part2.7">3.1.1</a>, <a href="#rfc.xref.Part2.8">3.1.2</a>, <a href="#rfc.xref.Part2.9">3.2</a>, <a href="#rfc.xref.Part2.10">3.2</a>, <a href="#rfc.xref.Part2.11">3.3</a>, <a href="#rfc.xref.Part2.12">3.3</a>, <a href="#rfc.xref.Part2.13">3.3.1</a>, <a href="#rfc.xref.Part2.14">3.3.2</a>, <a href="#rfc.xref.Part2.15">3.3.2</a>, <a href="#rfc.xref.Part2.16">4.3</a>, <a href="#rfc.xref.Part2.17">5.1</a>, <a href="#rfc.xref.Part2.18">5.3</a>, <a href="#rfc.xref.Part2.19">5.3</a>, <a href="#rfc.xref.Part2.20">5.8</a>, <a href="#rfc.xref.Part2.21">5.8</a>, <a href="#rfc.xref.Part2.22">5.8</a>, <a href="#rfc.xref.Part2.23">5.8</a>, <a href="#rfc.xref.Part2.24">5.8</a>, <a href="#rfc.xref.Part2.25">5.8</a>, <a href="#rfc.xref.Part2.26">5.9</a>, <a href="#rfc.xref.Part2.27">6.2.2.1</a>, <a href="#rfc.xref.Part2.28">6.2.2.2</a>, <a href="#rfc.xref.Part2.29">6.3</a>, <a href="#rfc.xref.Part2.30">7.4</a>, <a href="#rfc.xref.Part2.31">8.6</a>, <a href="#rfc.xref.Part2.32">8.6</a>, <a href="#Part2"><b>10.1</b></a><ul>
    36393639                        <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.4">2.7</a></li>
    3640                         <li><em>Section 3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.20">5.8</a></li>
    3641                         <li><em>Section 3.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.25">5.8</a></li>
    3642                         <li><em>Section 3.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.24">5.8</a></li>
    3643                         <li><em>Section 3.2.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.22">5.8</a></li>
     3640                        <li><em>Section 3.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.25">5.8</a></li>
     3641                        <li><em>Section 3.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.24">5.8</a></li>
     3642                        <li><em>Section 3.1.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.22">5.8</a></li>
     3643                        <li><em>Section 3.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.20">5.8</a></li>
    36443644                        <li><em>Section 4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.6">3.1.1</a></li>
    36453645                        <li><em>Section 4.2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.27">6.2.2.1</a>, <a href="#rfc.xref.Part2.28">6.2.2.2</a></li>
  • draft-ietf-httpbis/latest/p1-messaging.xml

    r1908 r1910  
    54135413      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/88"/>:
    54145414      "205 Bodies" (took out language that implied that there might be
    5415       methods for which a request body MUST NOT be included)
     5415      methods for which a payload body MUST NOT be included)
    54165416    </t>
    54175417    <t>
  • draft-ietf-httpbis/latest/p2-semantics.html

    r1909 r1910  
    880880      </p>
    881881      <p id="rfc.section.3.p.2">For the purposes of HTTP, a <dfn>representation</dfn> is information that reflects the current or desired state of a given resource, in a format that can be readily communicated
    882          via the protocol, consisting of a set of metadata (representation header fields) and a potentially unbounded stream of data
    883          (representation body).
     882         via the protocol, consisting of a set of metadata (representation header fields) and a potentially unbounded stream of octets
     883         (representation data).
    884884      </p>
    885885      <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a>&nbsp;<a id="representation.header.fields" href="#representation.header.fields">Representation Header Fields</a></h2>
     
    941941      </p>
    942942      <div id="rfc.figure.u.4"></div><pre class="text">  Content-Encoding: gzip
    943 </pre><p id="rfc.section.3.1.2.p.5">The content-coding is a characteristic of the representation. Typically, the representation body is stored with this encoding
     943</pre><p id="rfc.section.3.1.2.p.5">The content-coding is a characteristic of the representation. Typically, the representation data is stored with this encoding
    944944         and is only decoded before rendering or analogous usage. However, a transforming proxy <em class="bcp14">MAY</em> modify the content-coding if the new coding is known to be acceptable to the recipient, unless the "no-transform" cache-control
    945945         directive is present in the message.
     
    965965      <div id="rfc.figure.u.5"></div><pre class="inline"><span id="rfc.iref.g.3"></span>  <a href="#header.content-language" class="smpl">Content-Language</a> = 1#<a href="#language.tags" class="smpl">language-tag</a>
    966966</pre><p id="rfc.section.3.1.3.p.3">Language tags are defined in <a href="#language.tags" title="Language Tags">Section&nbsp;8.6</a>. The primary purpose of Content-Language is to allow a user to identify and differentiate representations according to the
    967          user's own preferred language. Thus, if the body content is intended only for a Danish-literate audience, the appropriate
    968          field is
     967         user's own preferred language. Thus, if the content is intended only for a Danish-literate audience, the appropriate field
     968         is
    969969      </p>
    970970      <div id="rfc.figure.u.6"></div><pre class="text">  Content-Language: da
     
    10511051      </div>
    10521052      <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a>&nbsp;<a id="representation.data" href="#representation.data">Representation Data</a></h2>
    1053       <p id="rfc.section.3.3.p.1">The representation body associated with an HTTP message is either provided as the payload body of the message or referred
     1053      <p id="rfc.section.3.3.p.1">The representation data associated with an HTTP message is either provided as the payload body of the message or referred
    10541054         to by the message semantics and the effective request URI. The representation data is in a format and encoding defined by
    10551055         the representation metadata header fields.
     
    10641064      </p>
    10651065      <p id="rfc.section.3.3.p.5">In practice, resource owners do not always properly configure their origin server to provide the correct Content-Type for
    1066          a given representation, with the result that some clients will examine a response body's content and override the specified
    1067          type. Clients that do so risk drawing incorrect conclusions, which might expose additional security risks (e.g., "privilege
    1068          escalation"). Furthermore, it is impossible to determine the sender's intent by examining the data format: many data formats
    1069          match multiple media types that differ only in processing semantics. Implementers are encouraged to provide a means of disabling
    1070          such "content sniffing" when it is used.
     1066         a given representation, with the result that some clients will examine a payload's content and override the specified type.
     1067         Clients that do so risk drawing incorrect conclusions, which might expose additional security risks (e.g., "privilege escalation").
     1068         Furthermore, it is impossible to determine the sender's intent by examining the data format: many data formats match multiple
     1069         media types that differ only in processing semantics. Implementers are encouraged to provide a means of disabling such "content
     1070         sniffing" when it is used.
    10711071      </p>
    10721072      <p id="rfc.section.3.3.p.6"> <a href="#header.content-encoding" class="smpl">Content-Encoding</a> is used to indicate any additional content codings applied to the data, usually for the purpose of data compression, that
     
    10771077      <h2 id="rfc.section.3.4"><a href="#rfc.section.3.4">3.4</a>&nbsp;<a id="payload" href="#payload">Message Payload</a></h2>
    10781078      <p id="rfc.section.3.4.p.1">Some HTTP messages transfer a complete or partial representation as the message "<dfn>payload</dfn>". In some cases, a payload might only contain the associated representation's header fields (e.g., responses to HEAD) or
    1079          only some part(s) of the representation body (e.g., the <a href="p5-range.html#status.206" class="smpl">206 (Partial Content)</a> status code).
     1079         only some part(s) of the representation data (e.g., the <a href="p5-range.html#status.206" class="smpl">206 (Partial Content)</a> status code).
    10801080      </p>
    10811081      <p id="rfc.section.3.4.p.2">The purpose of a payload in a request is defined by the method semantics. In a response, the payload's purpose is defined
     
    10871087      </p>
    10881088      <p id="rfc.section.3.4.p.4">Likewise, the payload of a <a href="#status.200" class="smpl">200 (OK)</a> response to GET (<a href="#GET" id="rfc.xref.GET.1" title="GET">Section&nbsp;4.3.1</a>) contains a representation of the target resource, as observed at the time of the message origination date (<a href="#header.date" id="rfc.xref.header.date.1" title="Date">Section&nbsp;7.2.1</a>), whereas the same status code in a response to POST might contain either a representation of the processing result or a
    1089          current representation of the target resource after applying the processing. Some responses only contain the representation's
    1090          header fields as the payload. Response messages with an error status code usually contain a representation that describes
    1091          the error and what next steps are suggested for resolving it.
     1089         current representation of the target resource after applying the processing. Response messages with an error status code usually
     1090         contain a representation that describes the error and what next steps are suggested for resolving it.
    10921091      </p>
    10931092      <h3 id="rfc.section.3.4.1"><a href="#rfc.section.3.4.1">3.4.1</a>&nbsp;<a id="payload.header.fields" href="#payload.header.fields">Payload Header Fields</a></h3>
     
    13761375         to be completed without transferring data already held by the client.
    13771376      </p>
    1378       <p id="rfc.section.4.3.1.p.5">Bodies on GET requests have no defined semantics. Note that sending a body on a GET request might cause some existing implementations
    1379          to reject the request.
     1377      <p id="rfc.section.4.3.1.p.5">A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some
     1378         existing implementations to reject the request.
    13801379      </p>
    13811380      <p id="rfc.section.4.3.1.p.6">The response to a GET request is cacheable and <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests (see <a href="#Part6" id="rfc.xref.Part6.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).
     
    13861385      <div id="rfc.iref.h.1"></div>
    13871386      <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> return a message body in the response. The metadata contained in the HTTP header fields in response to a HEAD request <em class="bcp14">SHOULD</em> be identical to the information sent in response to a GET request. This method can be used for obtaining metadata about the
    1388          representation implied by the request without transferring the representation body. This method is often used for testing
     1387         representation implied by the request without transferring the representation data. This method is often used for testing
    13891388         hypertext links for validity, accessibility, and recent modification.
    13901389      </p>
    13911390      <p id="rfc.section.4.3.2.p.2">The response to a HEAD request is cacheable and <em class="bcp14">MAY</em> be used to satisfy a subsequent HEAD request. It also has potential side effects on previously stored responses to GET; see <a href="p6-cache.html#head.effects" title="Updating Caches with HEAD Responses">Section 5</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>.
    13921391      </p>
    1393       <p id="rfc.section.4.3.2.p.3">Bodies on HEAD requests have no defined semantics. Note that sending a body on a HEAD request might cause some existing implementations
    1394          to reject the request.
     1392      <p id="rfc.section.4.3.2.p.3">A payload within a HEAD request message has no defined semantics; sending a payload body on a HEAD request might cause some
     1393         existing implementations to reject the request.
    13951394      </p>
    13961395      <div id="rfc.iref.p.2"></div>
     
    14891488      <p id="rfc.section.4.3.5.p.2">A successful response <em class="bcp14">SHOULD</em> be <a href="#status.200" class="smpl">200 (OK)</a> if the response includes a representation describing the status, <a href="#status.202" class="smpl">202 (Accepted)</a> if the action has not yet been enacted, or <a href="#status.204" class="smpl">204 (No Content)</a> if the action has been enacted but the response does not include a representation.
    14901489      </p>
    1491       <p id="rfc.section.4.3.5.p.3">Bodies on DELETE requests have no defined semantics. Note that sending a body on a DELETE request might cause some existing
    1492          implementations to reject the request.
     1490      <p id="rfc.section.4.3.5.p.3">A payload within a DELETE request message has no defined semantics; sending a payload body on a DELETE request might cause
     1491         some existing implementations to reject the request.
    14931492      </p>
    14941493      <p id="rfc.section.4.3.5.p.4">Responses to the DELETE method are not cacheable. If a DELETE request passes through a cache that has one or more stored responses
     
    15201519Proxy-Authorization: basic aGVsbG86d29ybGQ=
    15211520
    1522 </pre><p id="rfc.section.4.3.6.p.9">A message body on a CONNECT request has no defined semantics. Sending a body on a CONNECT request might cause existing implementations
    1523          to reject the request.
     1521</pre><p id="rfc.section.4.3.6.p.9">A payload within a CONNECT request message has no defined semantics; sending a payload body on a CONNECT request might cause
     1522         some existing implementations to reject the request.
    15241523      </p>
    15251524      <p id="rfc.section.4.3.6.p.10">Similar to a pipelined HTTP/1.1 request, data to be tunneled from client to server <em class="bcp14">MAY</em> be sent immediately after the request (before a response is received). The usual caveats also apply: data can be discarded
     
    15421541      </p>
    15431542      <p id="rfc.section.4.3.7.p.2">Responses to the OPTIONS method are not cacheable.</p>
    1544       <p id="rfc.section.4.3.7.p.3">If the OPTIONS request includes a message body (as indicated by the presence of <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a> or <a href="p1-messaging.html#header.transfer-encoding" class="smpl">Transfer-Encoding</a>), then the media type <em class="bcp14">MUST</em> be indicated by a <a href="#header.content-type" class="smpl">Content-Type</a> field. Although this specification does not define any use for such a body, future extensions to HTTP might use the OPTIONS
     1543      <p id="rfc.section.4.3.7.p.3">If the OPTIONS request includes a payload, then the media type <em class="bcp14">MUST</em> be indicated by a <a href="#header.content-type" class="smpl">Content-Type</a> field. Although this specification does not define any use for such a body, future extensions to HTTP might use the OPTIONS
    15451544         body to make more detailed queries on the server.
    15461545      </p>
     
    15531552         with that resource.
    15541553      </p>
    1555       <p id="rfc.section.4.3.7.p.6">A <a href="#status.200" class="smpl">200 (OK)</a> response <em class="bcp14">SHOULD</em> include any header fields that indicate optional features implemented by the server and applicable to that resource (e.g., <a href="#header.allow" class="smpl">Allow</a>), possibly including extensions not defined by this specification. The response body, if any, <em class="bcp14">SHOULD</em> also include information about the communication options. The format for such a body is not defined by this specification,
    1556          but might be defined by future extensions to HTTP. Content negotiation <em class="bcp14">MAY</em> be used to select the appropriate response format. If no response body is included, the response <em class="bcp14">MUST</em> include a <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a> field with a field-value of "0".
     1554      <p id="rfc.section.4.3.7.p.6">A <a href="#status.200" class="smpl">200 (OK)</a> response <em class="bcp14">SHOULD</em> include any header fields that indicate optional features implemented by the server and applicable to that resource (e.g., <a href="#header.allow" class="smpl">Allow</a>), possibly including extensions not defined by this specification. The response payload, if any, <em class="bcp14">SHOULD</em> also include information about the communication options. The format for such a payload is not defined by this specification,
     1555         but might be defined by future extensions to HTTP. Content negotiation <em class="bcp14">MAY</em> be used to select the appropriate representation. If no payload body is included, the response <em class="bcp14">MUST</em> include a <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a> field with a field-value of "0".
    15571556      </p>
    15581557      <p id="rfc.section.4.3.7.p.7">The <a href="#header.max-forwards" class="smpl">Max-Forwards</a> header field <em class="bcp14">MAY</em> be used to target a specific proxy in the request chain (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.1" title="Max-Forwards">Section&nbsp;5.1.1</a>). If no Max-Forwards field is present in the request, then the forwarded request <em class="bcp14">MUST NOT</em> include a Max-Forwards field.
     
    16411640      <p id="rfc.section.5.1.2.p.8">Many older HTTP/1.0 and HTTP/1.1 applications do not understand the Expect header field.</p>
    16421641      <h4 id="rfc.section.5.1.2.1"><a href="#rfc.section.5.1.2.1">5.1.2.1</a>&nbsp;<a id="use.of.the.100.status" href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></h4>
    1643       <p id="rfc.section.5.1.2.1.p.1">The purpose of the <a href="#status.100" class="smpl">100 (Continue)</a> status code (<a href="#status.100" id="rfc.xref.status.100.1" title="100 Continue">Section&nbsp;6.2.1</a>) is to allow a client that is sending a request message with a request body to determine if the origin server is willing
    1644          to accept the request (based on the request header fields) before the client sends the request body. In some cases, it might
    1645          either be inappropriate or highly inefficient for the client to send the body if the server will reject the message without
     1642      <p id="rfc.section.5.1.2.1.p.1">The purpose of the <a href="#status.100" class="smpl">100 (Continue)</a> status code (<a href="#status.100" id="rfc.xref.status.100.1" title="100 Continue">Section&nbsp;6.2.1</a>) is to allow a client that is sending a request message with a payload to determine if the origin server is willing to accept
     1643         the request (based on the request header fields) before the client sends the payload body. In some cases, it might either
     1644         be inappropriate or highly inefficient for the client to send the payload body if the server will reject the message without
    16461645         looking at the body.
    16471646      </p>
    16481647      <p id="rfc.section.5.1.2.1.p.2">Requirements for HTTP/1.1 clients: </p>
    16491648      <ul>
    1650          <li>If a client will wait for a <a href="#status.100" class="smpl">100 (Continue)</a> response before sending the request body, it <em class="bcp14">MUST</em> send an <a href="#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation.
    1651          </li>
    1652          <li>A client <em class="bcp14">MUST NOT</em> send an <a href="#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation if it does not intend to send a request body.
     1649         <li>If a client will wait for a <a href="#status.100" class="smpl">100 (Continue)</a> response before sending the payload body, it <em class="bcp14">MUST</em> send an <a href="#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation.
     1650         </li>
     1651         <li>A client <em class="bcp14">MUST NOT</em> send an <a href="#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation if it does not intend to send a payload body.
    16531652         </li>
    16541653      </ul>
    16551654      <p id="rfc.section.5.1.2.1.p.3">Because of the presence of older implementations, the protocol allows ambiguous situations in which a client might send "Expect:
    16561655         100-continue" without receiving either a <a href="#status.417" class="smpl">417 (Expectation Failed)</a> or a <a href="#status.100" class="smpl">100 (Continue)</a> status code. Therefore, when a client sends this header field to an origin server (possibly via a proxy) from which it has
    1657          never seen a <a href="#status.100" class="smpl">100 (Continue)</a> status code, the client <em class="bcp14">SHOULD NOT</em> wait for an indefinite period before sending the request body.
     1656         never seen a <a href="#status.100" class="smpl">100 (Continue)</a> status code, the client <em class="bcp14">SHOULD NOT</em> wait for an indefinite period before sending the payload body.
    16581657      </p>
    16591658      <p id="rfc.section.5.1.2.1.p.4">Requirements for HTTP/1.1 origin servers: </p>
    16601659      <ul>
    1661          <li>Upon receiving a request which includes an <a href="#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation, an origin server <em class="bcp14">MUST</em> either respond with <a href="#status.100" class="smpl">100 (Continue)</a> status code and continue to read from the input stream, or respond with a final status code. The origin server <em class="bcp14">MUST NOT</em> wait for the request body before sending the <a href="#status.100" class="smpl">100 (Continue)</a> response. If it responds with a final status code, it <em class="bcp14">MAY</em> close the transport connection or it <em class="bcp14">MAY</em> continue to read and discard the rest of the request. It <em class="bcp14">MUST NOT</em> perform the request method if it returns a final status code.
     1660         <li>Upon receiving a request which includes an <a href="#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation, an origin server <em class="bcp14">MUST</em> either respond with <a href="#status.100" class="smpl">100 (Continue)</a> status code and continue to read from the input stream, or respond with a final status code. The origin server <em class="bcp14">MUST NOT</em> wait for the payload body before sending the <a href="#status.100" class="smpl">100 (Continue)</a> response. If it responds with a final status code, it <em class="bcp14">MAY</em> close the transport connection or it <em class="bcp14">MAY</em> continue to read and discard the rest of the request. It <em class="bcp14">MUST NOT</em> perform the request method if it returns a final status code.
    16621661         </li>
    16631662         <li>An origin server <em class="bcp14">SHOULD NOT</em> send a <a href="#status.100" class="smpl">100 (Continue)</a> response if the request message does not include an <a href="#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation, and <em class="bcp14">MUST NOT</em> send a <a href="#status.100" class="smpl">100 (Continue)</a> response if such a request comes from an HTTP/1.0 (or earlier) client. There is an exception to this rule: for compatibility
     
    16661665            wait for <a href="#status.100" class="smpl">100 (Continue)</a> status code, applies only to HTTP/1.1 requests, and not to requests with any other HTTP-version value.
    16671666         </li>
    1668          <li>An origin server <em class="bcp14">MAY</em> omit a <a href="#status.100" class="smpl">100 (Continue)</a> response if it has already received some or all of the request body for the corresponding request.
    1669          </li>
    1670          <li>An origin server that sends a <a href="#status.100" class="smpl">100 (Continue)</a> response <em class="bcp14">MUST</em> ultimately send a final status code, once the request body is received and processed, unless it terminates the transport connection
     1667         <li>An origin server <em class="bcp14">MAY</em> omit a <a href="#status.100" class="smpl">100 (Continue)</a> response if it has already received some or all of the payload body for the corresponding request.
     1668         </li>
     1669         <li>An origin server that sends a <a href="#status.100" class="smpl">100 (Continue)</a> response <em class="bcp14">MUST</em> ultimately send a final status code, once the payload body is received and processed, unless it terminates the transport connection
    16711670            prematurely.
    16721671         </li>
    1673          <li>If an origin server receives a request that does not include an <a href="#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation, the request includes a request body, and the server responds with a final
    1674             status code before reading the entire request body from the transport connection, then the server <em class="bcp14">SHOULD NOT</em> close the transport connection until it has read the entire request, or until the client closes the connection. Otherwise,
     1672         <li>If an origin server receives a request that does not include an <a href="#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation, the request includes a payload body, and the server responds with a final
     1673            status code before reading the entire payload body from the transport connection, then the server <em class="bcp14">SHOULD NOT</em> close the transport connection until it has read the entire request, or until the client closes the connection. Otherwise,
    16751674            the client might not reliably receive the response message. However, this requirement ought not be construed as preventing
    16761675            a server from defending itself against denial-of-service attacks, or from badly broken client implementations.
     
    26032602      <h3 id="rfc.section.6.5.8"><a href="#rfc.section.6.5.8">6.5.8</a>&nbsp;<a id="status.409" href="#status.409">409 Conflict</a></h3>
    26042603      <p id="rfc.section.6.5.8.p.1">The request could not be completed due to a conflict with the current state of the resource. This code is only allowed in
    2605          situations where it is expected that the user might be able to resolve the conflict and resubmit the request. The response
    2606          body <em class="bcp14">SHOULD</em> include enough information for the user to recognize the source of the conflict. Ideally, the response representation would
     2604         situations where it is expected that the user might be able to resolve the conflict and resubmit the request. The payload <em class="bcp14">SHOULD</em> include enough information for the user to recognize the source of the conflict. Ideally, the response representation would
    26072605         include enough information for the user or user agent to fix the problem; however, that might not be possible and is not required.
    26082606      </p>
     
    31723170      </p>
    31733171      <h3 id="rfc.section.9.1.2"><a href="#rfc.section.9.1.2">9.1.2</a>&nbsp;<a id="considerations.for.new.methods" href="#considerations.for.new.methods">Considerations for New Methods</a></h3>
    3174       <p id="rfc.section.9.1.2.p.1">Standardized HTTP methods are generic; that is, they are potentially applicable to any resource, not just one particular media
    3175          type, kind of resource, or application. As such, it is preferred that new HTTP methods be registered in a document that isn't
    3176          specific to a single application or data format, since orthogonal technologies deserve orthogonal specification.
    3177       </p>
    3178       <p id="rfc.section.9.1.2.p.2">Since HTTP message parsing (<a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.29"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) is independent of method semantics (aside from responses to HEAD), definitions of new HTTP methods cannot change the parsing
    3179          algorithm or prohibit the presence of a message body on either the request or the response message. Definitions of new methods
    3180          can specify that only zero-length bodies are allowed, which would imply that each such messages would be required to contain
    3181          a Content-Length header field with a value of "0".
    3182       </p>
    3183       <p id="rfc.section.9.1.2.p.3">New method definitions need to indicate whether they are safe (<a href="#safe.methods" title="Safe Methods">Section&nbsp;4.2.1</a>), idempotent (<a href="#idempotent.methods" title="Idempotent Methods">Section&nbsp;4.2.2</a>), cacheable (<a href="#cacheable.methods" title="Cacheable Methods">Section&nbsp;4.2.3</a>), and what semantics are to be associated with the request body if any is present in the request. If a method is cacheable,
     3172      <p id="rfc.section.9.1.2.p.1">Standardized methods are generic; that is, they are potentially applicable to any resource, not just one particular media
     3173         type, kind of resource, or application. As such, it is preferred that new methods be registered in a document that isn't specific
     3174         to a single application or data format, since orthogonal technologies deserve orthogonal specification.
     3175      </p>
     3176      <p id="rfc.section.9.1.2.p.2">Since message parsing (<a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.29"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) needs to be independent of method semantics (aside from responses to HEAD), definitions of new methods cannot change the
     3177         parsing algorithm or prohibit the presence of a message body on either the request or the response message. Definitions of
     3178         new methods can specify that only a zero-length message body is allowed by requiring a Content-Length header field with a
     3179         value of "0".
     3180      </p>
     3181      <p id="rfc.section.9.1.2.p.3">New method definitions need to indicate whether they are safe (<a href="#safe.methods" title="Safe Methods">Section&nbsp;4.2.1</a>), idempotent (<a href="#idempotent.methods" title="Idempotent Methods">Section&nbsp;4.2.2</a>), cacheable (<a href="#cacheable.methods" title="Cacheable Methods">Section&nbsp;4.2.3</a>), and what semantics are to be associated with the payload body if any is present in the request. If a method is cacheable,
    31843182         the method definition ought to describe how, and under what conditions, a cache can store a response and use it to satisfy
    31853183         a subsequent request.
     
    32723270         isn't specific to a single application.
    32733271      </p>
    3274       <p id="rfc.section.9.2.2.p.2">New status codes are required to fall under one of the categories defined in <a href="#status.codes" title="Response Status Codes">Section&nbsp;6</a>. To allow existing parsers to properly handle them, new status codes cannot disallow a response body, although they can mandate
    3275          a zero-length response body.
     3272      <p id="rfc.section.9.2.2.p.2">New status codes are required to fall under one of the categories defined in <a href="#status.codes" title="Response Status Codes">Section&nbsp;6</a>. To allow existing parsers to properly handle them, new status codes cannot disallow a payload, although they can mandate
     3273         a zero-length payload body.
    32763274      </p>
    32773275      <p id="rfc.section.9.2.2.p.3">A definition for a new status code ought to explain the request conditions that produce a response containing that status
     
    44874485      <p id="rfc.section.F.8.p.1">Closed issues: </p>
    44884486      <ul>
    4489          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/98">http://tools.ietf.org/wg/httpbis/trac/ticket/98</a>&gt;: "OPTIONS request bodies"
     4487         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/98">http://tools.ietf.org/wg/httpbis/trac/ticket/98</a>&gt;: "OPTIONS payload bodies"
    44904488         </li>
    44914489         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/119">http://tools.ietf.org/wg/httpbis/trac/ticket/119</a>&gt;: "Description of CONNECT should refer to RFC2817"
  • draft-ietf-httpbis/latest/p2-semantics.xml

    r1909 r1910  
    302302   that can be readily communicated via the protocol, consisting of a set of
    303303   metadata (representation header fields) and a potentially unbounded stream
    304    of data (representation body).
     304   of octets (representation data).
    305305</t>
    306306
     
    371371<t>
    372372   The content-coding is a characteristic of the representation.
    373    Typically, the representation body is stored with this
     373   Typically, the representation data is stored with this
    374374   encoding and is only decoded before rendering or analogous usage.
    375375   However, a transforming proxy &MAY; modify the content-coding if the
     
    422422   Content-Language is to allow a user to identify and differentiate
    423423   representations according to the user's own preferred language. Thus, if the
    424    body content is intended only for a Danish-literate audience, the
     424   content is intended only for a Danish-literate audience, the
    425425   appropriate field is
    426426</t>
     
    569569  <x:anchor-alias value="representation-data"/>
    570570<t>
    571    The representation body associated with an HTTP message is
     571   The representation data associated with an HTTP message is
    572572   either provided as the payload body of the message or
    573573   referred to by the message semantics and the effective request
     
    599599   In practice, resource owners do not always properly configure their origin
    600600   server to provide the correct Content-Type for a given representation,
    601    with the result that some clients will examine a response body's content
     601   with the result that some clients will examine a payload's content
    602602   and override the specified type.
    603603   Clients that do so risk drawing incorrect conclusions, which might expose
     
    623623   message "<x:dfn>payload</x:dfn>".  In some cases, a payload might only
    624624   contain the associated representation's header fields (e.g., responses to
    625    HEAD) or only some part(s) of the representation body
     625   HEAD) or only some part(s) of the representation data
    626626   (e.g., the <x:ref>206 (Partial Content)</x:ref> status code).
    627627</t>
     
    646646   to POST might contain either a representation of the processing result or
    647647   a current representation of the target resource after applying the
    648    processing. Some responses only contain the representation's header fields
    649    as the payload. Response messages with an error status code usually contain
     648   processing. Response messages with an error status code usually contain
    650649   a representation that describes the error and what next steps are suggested
    651650   for resolving it.
     
    11121111</t>
    11131112<t>
    1114    Bodies on GET requests have no defined semantics. Note that sending a body
    1115    on a GET request might cause some existing implementations to reject the
    1116    request.
     1113   A payload within a GET request message has no defined semantics;
     1114   sending a payload body on a GET request might cause some existing
     1115   implementations to reject the request.
    11171116</t>
    11181117<t>
     
    11371136   to the information sent in response to a GET request. This method can
    11381137   be used for obtaining metadata about the representation implied by the
    1139    request without transferring the representation body. This method is
     1138   request without transferring the representation data. This method is
    11401139   often used for testing hypertext links for validity, accessibility,
    11411140   and recent modification.
     
    11471146</t>
    11481147<t>
    1149    Bodies on HEAD requests have no defined semantics. Note that sending a body
    1150    on a HEAD request might cause some existing implementations to reject the
    1151    request.
     1148   A payload within a HEAD request message has no defined semantics;
     1149   sending a payload body on a HEAD request might cause some existing
     1150   implementations to reject the request.
    11521151</t>
    11531152</section>
     
    13581357</t>
    13591358<t>
    1360    Bodies on DELETE requests have no defined semantics. Note that sending a body
    1361    on a DELETE request might cause some existing implementations to reject the
    1362    request.
     1359   A payload within a DELETE request message has no defined semantics;
     1360   sending a payload body on a DELETE request might cause some existing
     1361   implementations to reject the request.
    13631362</t>
    13641363<t>
     
    14171416</artwork></figure>
    14181417<t>
    1419    A message body on a CONNECT request has no defined semantics. Sending a
    1420    body on a CONNECT request might cause existing implementations to reject
    1421    the request.
     1418   A payload within a CONNECT request message has no defined semantics;
     1419   sending a payload body on a CONNECT request might cause some existing
     1420   implementations to reject the request.
    14221421</t>
    14231422<t>
     
    14691468</t>
    14701469<t>
    1471    If the OPTIONS request includes a message body (as indicated by the
    1472    presence of <x:ref>Content-Length</x:ref> or <x:ref>Transfer-Encoding</x:ref>),
     1470   If the OPTIONS request includes a payload,
    14731471   then the media type &MUST; be indicated by a <x:ref>Content-Type</x:ref>
    14741472   field. Although this specification does not define any use for such a body,
     
    14951493   indicate optional features implemented by the server and applicable to that
    14961494   resource (e.g., <x:ref>Allow</x:ref>), possibly including extensions not
    1497    defined by this specification. The response body, if any, &SHOULD; also
     1495   defined by this specification. The response payload, if any, &SHOULD; also
    14981496   include information about the communication options. The format for such a
    1499    body is not defined by this specification, but might be defined by
     1497   payload is not defined by this specification, but might be defined by
    15001498   future extensions to HTTP. Content negotiation &MAY; be used to select
    1501    the appropriate response format. If no response body is included, the
     1499   the appropriate representation. If no payload body is included, the
    15021500   response &MUST; include a <x:ref>Content-Length</x:ref> field with a
    15031501   field-value of "0".
     
    16601658   The purpose of the <x:ref>100 (Continue)</x:ref> status code
    16611659   (<xref target='status.100'/>)
    1662    is to allow a client that is sending a request message with a request body
     1660   is to allow a client that is sending a request message with a payload
    16631661   to determine if the origin server is willing to accept the request
    1664    (based on the request header fields) before the client sends the request
     1662   (based on the request header fields) before the client sends the payload
    16651663   body. In some cases, it might either be inappropriate or highly
    1666    inefficient for the client to send the body if the server will reject
    1667    the message without looking at the body.
     1664   inefficient for the client to send the payload body if the server will
     1665   reject the message without looking at the body.
    16681666</t>
    16691667<t>
     
    16721670    <t>
    16731671        If a client will wait for a <x:ref>100 (Continue)</x:ref> response before
    1674         sending the request body, it &MUST; send an <x:ref>Expect</x:ref> header
     1672        sending the payload body, it &MUST; send an <x:ref>Expect</x:ref> header
    16751673        field with the "100-continue" expectation.
    16761674    </t>
    16771675    <t>
    16781676        A client &MUST-NOT; send an <x:ref>Expect</x:ref> header field with
    1679         the "100-continue" expectation if it does not intend to send a request
     1677        the "100-continue" expectation if it does not intend to send a payload
    16801678        body.
    16811679    </t>
     
    16891687   header field to an origin server (possibly via a proxy) from which it
    16901688   has never seen a <x:ref>100 (Continue)</x:ref> status code, the client &SHOULD-NOT; 
    1691    wait for an indefinite period before sending the request body.
     1689   wait for an indefinite period before sending the payload body.
    16921690</t>
    16931691<t>
     
    16981696        either respond with <x:ref>100 (Continue)</x:ref> status code and continue to read
    16991697        from the input stream, or respond with a final status code. The
    1700         origin server &MUST-NOT; wait for the request body before sending
     1698        origin server &MUST-NOT; wait for the payload body before sending
    17011699        the <x:ref>100 (Continue)</x:ref> response. If it responds with a final status
    17021700        code, it &MAY; close the transport connection or it &MAY; continue
     
    17191717    </t>
    17201718    <t> An origin server &MAY; omit a <x:ref>100 (Continue)</x:ref> response if it has
    1721         already received some or all of the request body for the
     1719        already received some or all of the payload body for the
    17221720        corresponding request.
    17231721    </t>
    17241722    <t> An origin server that sends a <x:ref>100 (Continue)</x:ref> response &MUST;
    1725         ultimately send a final status code, once the request body is
     1723        ultimately send a final status code, once the payload body is
    17261724        received and processed, unless it terminates the transport
    17271725        connection prematurely.
     
    17291727    <t> If an origin server receives a request that does not include an
    17301728        <x:ref>Expect</x:ref> header field with the "100-continue" expectation,
    1731         the request includes a request body, and the server responds
    1732         with a final status code before reading the entire request body
     1729        the request includes a payload body, and the server responds
     1730        with a final status code before reading the entire payload body
    17331731        from the transport connection, then the server &SHOULD-NOT;  close
    17341732        the transport connection until it has read the entire request,
     
    30213019   state of the resource. This code is only allowed in situations where
    30223020   it is expected that the user might be able to resolve the conflict
    3023    and resubmit the request. The response body &SHOULD; include enough
     3021   and resubmit the request. The payload &SHOULD; include enough
    30243022   information for the user to recognize the source of the conflict.
    30253023   Ideally, the response representation would include enough information for the
     
    40264024<section title="Considerations for New Methods" anchor="considerations.for.new.methods">
    40274025<t>
    4028    Standardized HTTP methods are generic; that is, they are potentially
     4026   Standardized methods are generic; that is, they are potentially
    40294027   applicable to any resource, not just one particular media type, kind of
    4030    resource, or application. As such, it is preferred that new HTTP methods
     4028   resource, or application. As such, it is preferred that new methods
    40314029   be registered in a document that isn't specific to a single application or
    40324030   data format, since orthogonal technologies deserve orthogonal specification.
    40334031</t>
    40344032<t>
    4035    Since HTTP message parsing (&message-body;) is independent of method
    4036    semantics (aside from responses to HEAD), definitions of new HTTP methods
     4033   Since message parsing (&message-body;) needs to be independent of method
     4034   semantics (aside from responses to HEAD), definitions of new methods
    40374035   cannot change the parsing algorithm or prohibit the presence of a message
    40384036   body on either the request or the response message.
    4039    Definitions of new methods can specify that only zero-length bodies are
    4040    allowed, which would imply that each such messages would be required to
    4041    contain a Content-Length header field with a value of "0".
     4037   Definitions of new methods can specify that only a zero-length message body
     4038   is allowed by requiring a Content-Length header field with a value of "0".
    40424039</t>
    40434040<t>
     
    40454042   target="safe.methods"/>), idempotent (<xref target="idempotent.methods"/>),
    40464043   cacheable (<xref target="cacheable.methods"/>), and what
    4047    semantics are to be associated with the request body if any is present
     4044   semantics are to be associated with the payload body if any is present
    40484045   in the request.  If a method is cacheable, the method definition ought
    40494046   to describe how, and under what conditions, a cache can store a response
     
    41484145   New status codes are required to fall under one of the categories
    41494146   defined in <xref target="status.codes"/>. To allow existing parsers to
    4150    properly handle them, new status codes cannot disallow a response body,
    4151    although they can mandate a zero-length response body.
     4147   properly handle them, new status codes cannot disallow a payload,
     4148   although they can mandate a zero-length payload body.
    41524149</t>
    41534150<t>
     
    62666263    <t>
    62676264      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/98"/>:
    6268       "OPTIONS request bodies"
     6265      "OPTIONS payload bodies"
    62696266    </t>
    62706267    <t>
  • draft-ietf-httpbis/latest/p5-range.html

    r1906 r1910  
    449449  }
    450450  @bottom-center {
    451        content: "Expires March 22, 2013";
     451       content: "Expires March 25, 2013";
    452452  }
    453453  @bottom-right {
     
    493493      <meta name="dct.creator" content="Reschke, J. F.">
    494494      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p5-range-latest">
    495       <meta name="dct.issued" scheme="ISO8601" content="2012-09-18">
     495      <meta name="dct.issued" scheme="ISO8601" content="2012-09-21">
    496496      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    497497      <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.">
     
    519519            </tr>
    520520            <tr>
    521                <td class="left">Expires: March 22, 2013</td>
     521               <td class="left">Expires: March 25, 2013</td>
    522522               <td class="right">J. Reschke, Editor</td>
    523523            </tr>
     
    528528            <tr>
    529529               <td class="left"></td>
    530                <td class="right">September 18, 2012</td>
     530               <td class="right">September 21, 2012</td>
    531531            </tr>
    532532         </tbody>
     
    553553         in progress”.
    554554      </p>
    555       <p>This Internet-Draft will expire on March 22, 2013.</p>
     555      <p>This Internet-Draft will expire on March 25, 2013.</p>
    556556      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    557557      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    855855         representation. (However, not all clients and servers need to support byte-range operations.)
    856856      </p>
    857       <p id="rfc.section.5.4.1.p.2">Byte range specifications in HTTP apply to the sequence of bytes in the representation body (not necessarily the same as the
     857      <p id="rfc.section.5.4.1.p.2">Byte range specifications in HTTP apply to the sequence of bytes in the representation data (not necessarily the same as the
    858858         message body).
    859859      </p>
     
    875875      </p>
    876876      <p id="rfc.section.5.4.1.p.7">If the last-byte-pos value is absent, or if the value is greater than or equal to the current length of the representation
    877          body, last-byte-pos is taken to be equal to one less than the current length of the representation in bytes.
     877         data, last-byte-pos is taken to be equal to one less than the current length of the representation in bytes.
    878878      </p>
    879879      <p id="rfc.section.5.4.1.p.8">By its choice of last-byte-pos, a client can limit the number of bytes retrieved without knowing the size of the representation.</p>
    880880      <div id="rfc.figure.u.14"></div><pre class="inline"><span id="rfc.iref.g.17"></span><span id="rfc.iref.g.18"></span>  <a href="#rule.ranges-specifier" class="smpl">suffix-byte-range-spec</a> = "-" <a href="#rule.ranges-specifier" class="smpl">suffix-length</a>
    881881  <a href="#rule.ranges-specifier" class="smpl">suffix-length</a> = 1*<a href="#imported.abnf" class="smpl">DIGIT</a>
    882 </pre><p id="rfc.section.5.4.1.p.10">A suffix-byte-range-spec is used to specify the suffix of the representation body, of a length given by the suffix-length
     882</pre><p id="rfc.section.5.4.1.p.10">A suffix-byte-range-spec is used to specify the suffix of the representation data, of a length given by the suffix-length
    883883         value. (That is, this form specifies the last N bytes of a representation.) If the representation is shorter than the specified
    884884         suffix-length, the entire representation is used.
     
    912912      <h3 id="rfc.section.5.4.2"><a href="#rfc.section.5.4.2">5.4.2</a>&nbsp;<a id="range.retrieval.requests" href="#range.retrieval.requests">Range Retrieval Requests</a></h3>
    913913      <p id="rfc.section.5.4.2.p.1">The "Range" header field defines the GET method (conditional or not) to request one or more sub-ranges of the response representation
    914          body, instead of the entire representation body.
     914         data, instead of the entire representation data.
    915915      </p>
    916916      <div id="rfc.figure.u.21"></div><pre class="inline"><span id="rfc.iref.g.19"></span>  <a href="#range.retrieval.requests" class="smpl">Range</a> = <a href="#rule.ranges-specifier" class="smpl">byte-ranges-specifier</a> / <a href="#range.retrieval.requests" class="smpl">other-ranges-specifier</a>
  • draft-ietf-httpbis/latest/p5-range.xml

    r1906 r1910  
    627627<t>
    628628   Byte range specifications in HTTP apply to the sequence of bytes in
    629    the representation body (not necessarily the same as the message body).
     629   the representation data (not necessarily the same as the message body).
    630630</t>
    631631<t anchor="rule.ranges-specifier">
     
    663663<t>
    664664   If the last-byte-pos value is absent, or if the value is greater than
    665    or equal to the current length of the representation body, last-byte-pos is
     665   or equal to the current length of the representation data, last-byte-pos is
    666666   taken to be equal to one less than the current length of the representation
    667667   in bytes.
     
    677677<t>
    678678   A suffix-byte-range-spec is used to specify the suffix of the
    679    representation body, of a length given by the suffix-length value. (That is,
     679   representation data, of a length given by the suffix-length value. (That is,
    680680   this form specifies the last N bytes of a representation.) If the
    681681   representation is shorter than the specified suffix-length, the entire
     
    746746<t>
    747747   The "Range" header field defines the GET method (conditional or
    748    not) to request one or more sub-ranges of the response representation body, instead
    749    of the entire representation body.
     748   not) to request one or more sub-ranges of the response representation data, instead
     749   of the entire representation data.
    750750</t>
    751751<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Range"/>
  • draft-ietf-httpbis/latest/p6-cache.html

    r1906 r1910  
    452452  }
    453453  @bottom-center {
    454        content: "Expires March 22, 2013";
     454       content: "Expires March 25, 2013";
    455455  }
    456456  @bottom-right {
     
    499499      <meta name="dct.creator" content="Reschke, J. F.">
    500500      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest">
    501       <meta name="dct.issued" scheme="ISO8601" content="2012-09-18">
     501      <meta name="dct.issued" scheme="ISO8601" content="2012-09-21">
    502502      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    503503      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.">
     
    525525            </tr>
    526526            <tr>
    527                <td class="left">Expires: March 22, 2013</td>
     527               <td class="left">Expires: March 25, 2013</td>
    528528               <td class="right">M. Nottingham, Editor</td>
    529529            </tr>
     
    538538            <tr>
    539539               <td class="left"></td>
    540                <td class="right">September 18, 2012</td>
     540               <td class="right">September 21, 2012</td>
    541541            </tr>
    542542         </tbody>
     
    564564         in progress”.
    565565      </p>
    566       <p>This Internet-Draft will expire on March 22, 2013.</p>
     566      <p>This Internet-Draft will expire on March 25, 2013.</p>
    567567      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    568568      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    772772      </p>
    773773      <ul class="empty">
    774          <li>A validator that is defined by the origin server such that its current value will change if the representation body changes;
     774         <li>A validator that is defined by the origin server such that its current value will change if the representation data changes;
    775775            i.e., an entity-tag that is not marked as weak (<a href="p4-conditional.html#header.etag" title="ETag">Section 2.3</a> of <a href="#Part4" id="rfc.xref.Part4.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>) or, if no entity-tag is provided, a <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> value that is strong in the sense defined by <a href="p4-conditional.html#lastmod.comparison" title="Comparison">Section 2.2.2</a> of <a href="#Part4" id="rfc.xref.Part4.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>.
    776776         </li>
     
    10661066         <li>A <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response status code indicates that the stored response can be updated and reused; see <a href="#freshening.responses" title="Freshening Responses with 304 Not Modified">Section&nbsp;4.2.1</a>.
    10671067         </li>
    1068          <li>A full response (i.e., one with a response body) indicates that none of the stored responses nominated in the conditional
    1069             request is suitable. Instead, the cache can use the full response to satisfy the request and <em class="bcp14">MAY</em> replace the stored response(s).
     1068         <li>A full response (i.e., one with a payload body) indicates that none of the stored responses nominated in the conditional request
     1069            is suitable. Instead, the cache can use the full response to satisfy the request and <em class="bcp14">MAY</em> replace the stored response(s).
    10701070         </li>
    10711071         <li>However, if a cache receives a <a href="p2-semantics.html#status.5xx" class="smpl">5xx (Server Error)</a> response while attempting to validate a response, it can either forward this response to the requesting client, or act as
  • draft-ietf-httpbis/latest/p6-cache.xml

    r1906 r1910  
    291291   <list>
    292292      <t>A validator that is defined by the origin server such that its
    293          current value will change if the representation body changes; i.e.,
     293         current value will change if the representation data changes; i.e.,
    294294         an entity-tag that is not marked as weak (&entity-tags;) or,
    295295         if no entity-tag is provided, a <x:ref>Last-Modified</x:ref> value
     
    878878      </t>
    879879      <t>
    880          A full response (i.e., one with a response body) indicates that none
     880         A full response (i.e., one with a payload body) indicates that none
    881881         of the stored responses nominated in the conditional request is
    882882         suitable. Instead, the cache can use the full response to
Note: See TracChangeset for help on using the changeset viewer.