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).

File:
1 edited

Legend:

Unmodified
Added
Removed
  • 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"
Note: See TracChangeset for help on using the changeset viewer.