Ignore:
Timestamp:
13/01/13 09:28:45 (10 years ago)
Author:
fielding@…
Message:

reorder paragraphs in method descriptions for consistency; note that CONNECT is not cacheable; partly addresses #426

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

Legend:

Unmodified
Added
Removed

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

    r2117 r2118  
    449449  }
    450450  @bottom-center {
    451        content: "Expires July 16, 2013";
     451       content: "Expires July 17, 2013";
    452452  }
    453453  @bottom-right {
    … …  
    494494      <meta name="dct.creator" content="Reschke, J. F.">
    495495      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
    496       <meta name="dct.issued" scheme="ISO8601" content="2013-01-12">
     496      <meta name="dct.issued" scheme="ISO8601" content="2013-01-13">
    497497      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    498498      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.">
    … …  
    522522            <tr>
    523523               <td class="left">Intended status: Standards Track</td>
    524                <td class="right">January 12, 2013</td>
     524               <td class="right">January 13, 2013</td>
    525525            </tr>
    526526            <tr>
    527                <td class="left">Expires: July 16, 2013</td>
     527               <td class="left">Expires: July 17, 2013</td>
    528528               <td class="right"></td>
    529529            </tr>
    … …  
    553553         in progress”.
    554554      </p>
    555       <p>This Internet-Draft will expire on July 16, 2013.</p>
     555      <p>This Internet-Draft will expire on July 17, 2013.</p>
    556556      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    557557      <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    13931393         to be completed without transferring data already held by the client.
    13941394      </p>
    1395       <p id="rfc.section.4.3.1.p.5">The response to a GET request is cacheable; a cache <em class="bcp14">MAY</em> use it to satisfy subsequent GET and HEAD requests unless otherwise indicated by the Cache-Control header field (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 7.2</a> of <a href="#Part6" id="rfc.xref.Part6.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).
    1396       </p>
    1397       <p id="rfc.section.4.3.1.p.6">A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some
     1395      <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
    13981396         existing implementations to reject the request.
     1397      </p>
     1398      <p id="rfc.section.4.3.1.p.6">The response to a GET request is cacheable; a cache <em class="bcp14">MAY</em> use it to satisfy subsequent GET and HEAD requests unless otherwise indicated by the Cache-Control header field (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 7.2</a> of <a href="#Part6" id="rfc.xref.Part6.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>).
    13991399      </p>
    14001400      <h3 id="rfc.section.4.3.2"><a href="#rfc.section.4.3.2">4.3.2</a>&nbsp;<a id="HEAD" href="#HEAD">HEAD</a></h3>
    … …  
    14051405         is often used for testing hypertext links for validity, accessibility, and recent modification.
    14061406      </p>
    1407       <p id="rfc.section.4.3.2.p.2">The response to a HEAD request is cacheable; a cache <em class="bcp14">MAY</em> use it to satisfy subsequent HEAD requests unless otherwise indicated by the Cache-Control header field (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 7.2</a> of <a href="#Part6" id="rfc.xref.Part6.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). A HEAD response might also have an effect on previously cached 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>.
    1408       </p>
    1409       <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
     1407      <p id="rfc.section.4.3.2.p.2">A payload within a HEAD request message has no defined semantics; sending a payload body on a HEAD request might cause some
    14101408         existing implementations to reject the request.
     1409      </p>
     1410      <p id="rfc.section.4.3.2.p.3">The response to a HEAD request is cacheable; a cache <em class="bcp14">MAY</em> use it to satisfy subsequent HEAD requests unless otherwise indicated by the Cache-Control header field (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 7.2</a> of <a href="#Part6" id="rfc.xref.Part6.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). A HEAD response might also have an effect on previously cached 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>.
    14111411      </p>
    14121412      <div id="rfc.iref.p.2"></div>
    … …  
    15621562Proxy-Authorization: basic aGVsbG86d29ybGQ=
    15631563
    1564 </pre><p id="rfc.section.4.3.6.p.10">A payload within a CONNECT request message has no defined semantics; sending a payload body on a CONNECT request might cause
    1565          some existing implementations to reject the request.
    1566       </p>
    1567       <p id="rfc.section.4.3.6.p.11">When a tunnel intermediary detects that either side has closed its connection, any outstanding data that came from that side
     1564</pre><p id="rfc.section.4.3.6.p.10">When a tunnel intermediary detects that either side has closed its connection, any outstanding data that came from that side
    15681565         will first be sent to the other side and then the intermediary will close both connections. If there is outstanding data left
    15691566         undelivered, that data will be discarded.
    15701567      </p>
     1568      <p id="rfc.section.4.3.6.p.11">A payload within a CONNECT request message has no defined semantics; sending a payload body on a CONNECT request might cause
     1569         some existing implementations to reject the request.
     1570      </p>
     1571      <p id="rfc.section.4.3.6.p.12">Responses to the CONNECT method are not cacheable.</p>
    15711572      <h3 id="rfc.section.4.3.7"><a href="#rfc.section.4.3.7">4.3.7</a>&nbsp;<a id="OPTIONS" href="#OPTIONS">OPTIONS</a></h3>
    15721573      <div id="rfc.iref.o.1"></div>
    … …  
    15751576         or the capabilities of a server, without implying a resource action.
    15761577      </p>
    1577       <p id="rfc.section.4.3.7.p.2">Responses to the OPTIONS method are not cacheable.</p>
    1578       <p id="rfc.section.4.3.7.p.3">A client that generates an OPTIONS request containing a payload body <em class="bcp14">MUST</em> send a valid <a href="#header.content-type" class="smpl">Content-Type</a> header field describing the representation media type. Although this specification does not define any use for such a payload,
    1579          future extensions to HTTP might use the OPTIONS body to make more detailed queries about the target resource.
    1580       </p>
    1581       <p id="rfc.section.4.3.7.p.4">An OPTIONS request with an asterisk ("*") as the request-target (<a href="p1-messaging.html#request-target" title="Request Target">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.16"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) applies to the server in general rather than to a specific resource. Since a server's communication options typically depend
     1578      <p id="rfc.section.4.3.7.p.2">An OPTIONS request with an asterisk ("*") as the request-target (<a href="p1-messaging.html#request-target" title="Request Target">Section 5.3</a> of <a href="#Part1" id="rfc.xref.Part1.16"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) applies to the server in general rather than to a specific resource. Since a server's communication options typically depend
    15821579         on the resource, the "*" request is only useful as a "ping" or "no-op" type of method; it does nothing beyond allowing the
    15831580         client to test the capabilities of the server. For example, this can be used to test a proxy for HTTP/1.1 conformance (or
    15841581         lack thereof).
    15851582      </p>
    1586       <p id="rfc.section.4.3.7.p.5">If the request-target is not an asterisk, the OPTIONS request applies to the options that are available when communicating
     1583      <p id="rfc.section.4.3.7.p.3">If the request-target is not an asterisk, the OPTIONS request applies to the options that are available when communicating
    15871584         with the target resource.
    15881585      </p>
    1589       <p id="rfc.section.4.3.7.p.6">A server generating a successful response to OPTIONS <em class="bcp14">SHOULD</em> send any header fields that might indicate optional features implemented by the server and applicable to the target resource
     1586      <p id="rfc.section.4.3.7.p.4">A server generating a successful response to OPTIONS <em class="bcp14">SHOULD</em> send any header fields that might indicate optional features implemented by the server and applicable to the target resource
    15901587         (e.g., <a href="#header.allow" class="smpl">Allow</a>), including potential extensions not defined by this specification. The response payload, if any, might also describe the
    15911588         communication options in a machine or human-readable representation. A standard format for such a representation is not defined
    15921589         by this specification, but might be defined by future extensions to HTTP. A server <em class="bcp14">MUST</em> generate a <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a> field with a value of "0" if no payload body is to be sent in the response.
    15931590      </p>
    1594       <p id="rfc.section.4.3.7.p.7">A client <em class="bcp14">MAY</em> send a <a href="#header.max-forwards" class="smpl">Max-Forwards</a> header field in an OPTIONS request to target a specific recipient in the request chain (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.1" title="Max-Forwards">Section&nbsp;5.1.2</a>). A proxy <em class="bcp14">MUST NOT</em> generate a Max-Forwards header field while forwarding a request unless that request was received with a Max-Forwards field.
    1595       </p>
     1591      <p id="rfc.section.4.3.7.p.5">A client <em class="bcp14">MAY</em> send a <a href="#header.max-forwards" class="smpl">Max-Forwards</a> header field in an OPTIONS request to target a specific recipient in the request chain (see <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.1" title="Max-Forwards">Section&nbsp;5.1.2</a>). A proxy <em class="bcp14">MUST NOT</em> generate a Max-Forwards header field while forwarding a request unless that request was received with a Max-Forwards field.
     1592      </p>
     1593      <p id="rfc.section.4.3.7.p.6">A client that generates an OPTIONS request containing a payload body <em class="bcp14">MUST</em> send a valid <a href="#header.content-type" class="smpl">Content-Type</a> header field describing the representation media type. Although this specification does not define any use for such a payload,
     1594         future extensions to HTTP might use the OPTIONS body to make more detailed queries about the target resource.
     1595      </p>
     1596      <p id="rfc.section.4.3.7.p.7">Responses to the OPTIONS method are not cacheable.</p>
    15961597      <h3 id="rfc.section.4.3.8"><a href="#rfc.section.4.3.8">4.3.8</a>&nbsp;<a id="TRACE" href="#TRACE">TRACE</a></h3>
    15971598      <div id="rfc.iref.t.1"></div>
    15981599      <p id="rfc.section.4.3.8.p.1">The TRACE method requests a remote, application-level loop-back of the request message. The final recipient of the request <em class="bcp14">SHOULD</em> reflect the message received, excluding some fields described below, back to the client as the message body of a <a href="#status.200" class="smpl">200 (OK)</a> response with a <a href="#header.content-type" class="smpl">Content-Type</a> of "message/http" (<a href="p1-messaging.html#internet.media.type.message.http" title="Internet Media Type message/http">Section 7.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.17"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). The final recipient is either the origin server or the first server to receive a <a href="#header.max-forwards" class="smpl">Max-Forwards</a> value of zero (0) in the request (<a href="#header.max-forwards" id="rfc.xref.header.max-forwards.2" title="Max-Forwards">Section&nbsp;5.1.2</a>).
    15991600      </p>
    1600       <p id="rfc.section.4.3.8.p.2">A client <em class="bcp14">MUST NOT</em> send a message body in a TRACE request.
    1601       </p>
    1602       <p id="rfc.section.4.3.8.p.3">A client <em class="bcp14">MUST NOT</em> send header fields in a TRACE request containing sensitive data that might be disclosed by the response. For example, it would
     1601      <p id="rfc.section.4.3.8.p.2">A client <em class="bcp14">MUST NOT</em> send header fields in a TRACE request containing sensitive data that might be disclosed by the response. For example, it would
    16031602         be foolish for a user agent to send stored user credentials <a href="#Part7" id="rfc.xref.Part7.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Authentication">[Part7]</cite></a> or cookies <a href="#RFC6265" id="rfc.xref.RFC6265.1"><cite title="HTTP State Management Mechanism">[RFC6265]</cite></a> in a TRACE request. The final recipient <em class="bcp14">SHOULD</em> exclude any request header fields from the response body that are likely to contain sensitive data.
    16041603      </p>
    1605       <p id="rfc.section.4.3.8.p.4">TRACE allows the client to see what is being received at the other end of the request chain and use that data for testing
     1604      <p id="rfc.section.4.3.8.p.3">TRACE allows the client to see what is being received at the other end of the request chain and use that data for testing
    16061605         or diagnostic information. The value of the <a href="p1-messaging.html#header.via" class="smpl">Via</a> header field (<a href="p1-messaging.html#header.via" title="Via">Section 5.7.1</a> of <a href="#Part1" id="rfc.xref.Part1.18"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) is of particular interest, since it acts as a trace of the request chain. Use of the <a href="#header.max-forwards" class="smpl">Max-Forwards</a> header field allows the client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding
    16071606         messages in an infinite loop.
     1607      </p>
     1608      <p id="rfc.section.4.3.8.p.4">A client <em class="bcp14">MUST NOT</em> send a message body in a TRACE request.
    16081609      </p>
    16091610      <p id="rfc.section.4.3.8.p.5">Responses to the TRACE method are not cacheable.</p>

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

    r2117 r2118  
    12741274</t>
    12751275<t>
     1276   A payload within a GET request message has no defined semantics;
     1277   sending a payload body on a GET request might cause some existing
     1278   implementations to reject the request.
     1279</t>
     1280<t>
    12761281   The response to a GET request is cacheable; a cache &MAY; use it to satisfy
    12771282   subsequent GET and HEAD requests unless otherwise indicated by the
    12781283   Cache-Control header field (&header-cache-control;).
    1279 </t>
    1280 <t>
    1281    A payload within a GET request message has no defined semantics;
    1282    sending a payload body on a GET request might cause some existing
    1283    implementations to reject the request.
    12841284</t>
    12851285</section>
    … …  
    13031303</t>
    13041304<t>
     1305   A payload within a HEAD request message has no defined semantics;
     1306   sending a payload body on a HEAD request might cause some existing
     1307   implementations to reject the request.
     1308</t>
     1309<t>
    13051310   The response to a HEAD request is cacheable; a cache &MAY; use it to
    13061311   satisfy subsequent HEAD requests unless otherwise indicated by the
    13071312   Cache-Control header field (&header-cache-control;). A HEAD response might
    13081313   also have an effect on previously cached responses to GET; see &p6-head;.
    1309 </t>
    1310 <t>
    1311    A payload within a HEAD request message has no defined semantics;
    1312    sending a payload body on a HEAD request might cause some existing
    1313    implementations to reject the request.
    13141314</t>
    13151315</section>
    … …  
    16281628</artwork></figure>
    16291629<t>
    1630    A payload within a CONNECT request message has no defined semantics;
    1631    sending a payload body on a CONNECT request might cause some existing
    1632    implementations to reject the request.
    1633 </t>
    1634 <t>
    16351630   When a tunnel intermediary detects that either side has closed its
    16361631   connection, any outstanding data that came from that side will first be
    … …  
    16381633   connections. If there is outstanding data left undelivered,
    16391634   that data will be discarded.
     1635</t>
     1636<t>
     1637   A payload within a CONNECT request message has no defined semantics;
     1638   sending a payload body on a CONNECT request might cause some existing
     1639   implementations to reject the request.
     1640</t>
     1641<t>
     1642   Responses to the CONNECT method are not cacheable.
    16401643</t>
    16411644</section>
    … …  
    16531656   determine the options and/or requirements associated with a resource,
    16541657   or the capabilities of a server, without implying a resource action.
    1655 </t>
    1656 <t>
    1657    Responses to the OPTIONS method are not cacheable.
    1658 </t>
    1659 <t>
    1660    A client that generates an OPTIONS request containing a payload body
    1661    &MUST; send a valid <x:ref>Content-Type</x:ref> header field describing
    1662    the representation media type. Although this specification does not define
    1663    any use for such a payload, future extensions to HTTP might use the OPTIONS
    1664    body to make more detailed queries about the target resource.
    16651658</t>
    16661659<t>
    … …  
    16971690   was received with a Max-Forwards field.
    16981691</t>
     1692<t>
     1693   A client that generates an OPTIONS request containing a payload body
     1694   &MUST; send a valid <x:ref>Content-Type</x:ref> header field describing
     1695   the representation media type. Although this specification does not define
     1696   any use for such a payload, future extensions to HTTP might use the OPTIONS
     1697   body to make more detailed queries about the target resource.
     1698</t>
     1699<t>
     1700   Responses to the OPTIONS method are not cacheable.
     1701</t>
    16991702</section>
    17001703
    … …  
    17161719</t>
    17171720<t>
    1718    A client &MUST-NOT; send a message body in a TRACE request.
    1719 </t>
    1720 <t>
    17211721   A client &MUST-NOT; send header fields in a TRACE request containing
    17221722   sensitive data that might be disclosed by the response. For example, it
    … …  
    17341734   limit the length of the request chain, which is useful for testing a chain
    17351735   of proxies forwarding messages in an infinite loop.
     1736</t>
     1737<t>
     1738   A client &MUST-NOT; send a message body in a TRACE request.
    17361739</t>
    17371740<t>
Note: See TracChangeset for help on using the changeset viewer.