Changeset 1261 for draft-ietf-httpbis/latest/p2-semantics.html

Timestamp:

07/04/11 01:08:58 (10 years ago)

Author:

mnot@…

Message:

Identify methods that don't define semantics for request bodies, and warn for interop #251

File:

• draft-ietf-httpbis/latest/p2-semantics.html (modified) (11 diffs)

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

@@ -359 +359 @@
   } 
   @bottom-center {
-       content: "Expires October 7, 2011"; 
+       content: "Expires October 9, 2011"; 
   } 
   @bottom-right {
@@ -409 +409 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2011-04-05">
+      <meta name="dct.issued" scheme="ISO8601" content="2011-04-07">
       <meta name="dct.replaces" content="urn:ietf:rfc:2616">
       <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 2 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 2 defines the semantics of HTTP messages as expressed by request methods, request header fields, response status codes, and response header fields.">
@@ -440 +440 @@
             </tr>
             <tr>
-               <td class="left">Expires: October 7, 2011</td>
+               <td class="left">Expires: October 9, 2011</td>
                <td class="right">HP</td>
             </tr>
@@ -493 +493 @@
             <tr>
                <td class="left"></td>
-               <td class="right">April 5, 2011</td>
+               <td class="right">April 7, 2011</td>
             </tr>
          </tbody>
@@ -520 +520 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on October 7, 2011.</p>
+      <p>This Internet-Draft will expire on October 9, 2011.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -830 +830 @@
          can specify that only zero-length bodies (as opposed to absent bodies) are allowed.
       </p>
-      <p id="rfc.section.2.2.1.p.4">New method definitions need to indicate whether they are safe (<a href="#safe.methods" title="Safe Methods">Section&nbsp;7.1.1</a>) and whether they are idempotent (<a href="#idempotent.methods" title="Idempotent Methods">Section&nbsp;7.1.2</a>). They also need to state whether they can be cached (<a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>); in particular what conditions a cache may store the response, and under what conditions such a stored response may be used
+      <p id="rfc.section.2.2.1.p.4">New method definitions need to indicate whether they are safe (<a href="#safe.methods" title="Safe Methods">Section&nbsp;7.1.1</a>), what semantics (if any) the request body has, and whether they are idempotent (<a href="#idempotent.methods" title="Idempotent Methods">Section&nbsp;7.1.2</a>). They also need to state whether they can be cached (<a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>); in particular what conditions a cache may store the response, and under what conditions such a stored response may be used
          to satisfy a subsequent request.
       </p>
@@ -1341 +1341 @@
          to be completed without transferring data already held by the client.
       </p>
-      <p id="rfc.section.7.3.p.5">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.6"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
-      </p>
-      <p id="rfc.section.7.3.p.6">See <a href="#encoding.sensitive.information.in.uris" title="Encoding Sensitive Information in URIs">Section&nbsp;11.2</a> for security considerations when used for forms.
+      <p id="rfc.section.7.3.p.5">Bodies on GET requests have no defined semantics. Note that sending a body on a GET request might cause some existing implementations
+         to reject the request.
+      </p>
+      <p id="rfc.section.7.3.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.6"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
+      </p>
+      <p id="rfc.section.7.3.p.7">See <a href="#encoding.sensitive.information.in.uris" title="Encoding Sensitive Information in URIs">Section&nbsp;11.2</a> for security considerations when used for forms.
       </p>
       <h2 id="rfc.section.7.4"><a href="#rfc.section.7.4">7.4</a>&nbsp;<a id="HEAD" href="#HEAD">HEAD</a></h2>
@@ -1355 +1358 @@
          representation differs from the current representation (as would be indicated by a change in Content-Length, Content-MD5,
          ETag or Last-Modified), then the cache <em class="bcp14">MUST</em> treat the cache entry as stale.
+      </p>
+      <p id="rfc.section.7.4.p.3">Bodies on HEAD requests have no defined semantics. Note that sending a body on a HEAD request might cause some existing implementations
+         to reject the request.
       </p>
       <div id="rfc.iref.p.1"></div>
@@ -1456 +1462 @@
          enacted, or 204 (No Content) if the action has been enacted but the response does not include a representation.
       </p>
-      <p id="rfc.section.7.7.p.3">Responses to the DELETE method are not cacheable. If a DELETE request passes through a cache that has one or more stored responses
+      <p id="rfc.section.7.7.p.3">Bodies on DELETE requests have no defined semantics. Note that sending a body on a DELETE request might cause some existing
+         implementations to reject the request.
+      </p>
+      <p id="rfc.section.7.7.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
          for the effective request URI, those stored responses will be invalidated (see <a href="p6-cache.html#invalidation.after.updates.or.deletions" title="Request Methods that Invalidate">Section 2.5</a> of <a href="#Part6" id="rfc.xref.Part6.10"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
       </p>
@@ -1492 +1501 @@
 Proxy-Authorization: basic aGVsbG86d29ybGQ=
 
-</pre><p id="rfc.section.7.9.p.7">Like any other pipelined HTTP/1.1 request, data to be tunnel may be sent immediately after the blank line. The usual caveats
+</pre><p id="rfc.section.7.9.p.7">Bodies on CONNECT requests have no defined semantics. Note that sending a body on a CONNECT request might cause some existing
+         implementations to reject the request.
+      </p>
+      <p id="rfc.section.7.9.p.8">Like any other pipelined HTTP/1.1 request, data to be tunnel may be sent immediately after the blank line. The usual caveats
          also apply: data may be discarded if the eventual response is negative, and the connection may be reset with no response if
          more than one TCP segment is outstanding.
@@ -3022 +3034 @@
       <ul>
          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/276">http://tools.ietf.org/wg/httpbis/trac/ticket/276</a>&gt;: "untangle ABNFs for header fields"
+         </li>
+         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/251">http://tools.ietf.org/wg/httpbis/trac/ticket/251</a>&gt;: "message-body in CONNECT request"
          </li>
       </ul>