Ignore:
Timestamp:
19/01/14 02:53:35 (6 years ago)
Author:
fielding@…
Message:

(editorial) add section xrefs where the common method names are first used; see #531

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p2-semantics.html

    r2556 r2561  
    448448  }
    449449  @bottom-center {
    450        content: "Expires July 21, 2014";
     450       content: "Expires July 22, 2014";
    451451  }
    452452  @bottom-right {
     
    493493      <meta name="dct.creator" content="Reschke, J. F.">
    494494      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
    495       <meta name="dct.issued" scheme="ISO8601" content="2014-01-17">
     495      <meta name="dct.issued" scheme="ISO8601" content="2014-01-18">
    496496      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    497497      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is a stateless 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.">
     
    521521            <tr>
    522522               <td class="left">Intended status: Standards Track</td>
    523                <td class="right">January 17, 2014</td>
     523               <td class="right">January 18, 2014</td>
    524524            </tr>
    525525            <tr>
    526                <td class="left">Expires: July 21, 2014</td>
     526               <td class="left">Expires: July 22, 2014</td>
    527527               <td class="right"></td>
    528528            </tr>
     
    553553            in progress”.
    554554         </p>
    555          <p>This Internet-Draft will expire on July 21, 2014.</p>
     555         <p>This Internet-Draft will expire on July 22, 2014.</p>
    556556      </div>
    557557      <div id="rfc.copyrightnotice">
     
    11131113                  <p id="rfc.section.3.1.4.1.p.3">For a response message, the following rules are applied in order until a match is found: </p>
    11141114                  <ol>
    1115                      <li>If the request is GET or HEAD and the response status code is <a href="#status.200" class="smpl">200 (OK)</a>, <a href="#status.204" class="smpl">204 (No Content)</a>, <a href="p5-range.html#status.206" class="smpl">206 (Partial Content)</a>, or <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a>, the payload is a representation of the resource identified by the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.11"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).
     1115                     <li>If the request method is GET or HEAD and the response status code is <a href="#status.200" class="smpl">200 (OK)</a>, <a href="#status.204" class="smpl">204 (No Content)</a>, <a href="p5-range.html#status.206" class="smpl">206 (Partial Content)</a>, or <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a>, the payload is a representation of the resource identified by the effective request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.11"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>).
    11161116                     </li>
    1117                      <li>If the request is GET or HEAD and the response status code is <a href="#status.203" class="smpl">203 (Non-Authoritative Information)</a>, the payload is a potentially modified or enhanced representation of the <a href="#resources" class="smpl">target resource</a> as provided by an intermediary.
     1117                     <li>If the request method is GET or HEAD and the response status code is <a href="#status.203" class="smpl">203 (Non-Authoritative Information)</a>, the payload is a potentially modified or enhanced representation of the <a href="#resources" class="smpl">target resource</a> as provided by an intermediary.
    11181118                     </li>
    11191119                     <li>If the response has a <a href="#header.content-location" class="smpl">Content-Location</a> header field and its field-value is a reference to the same URI as the effective request URI, the payload is a representation
     
    11401140                  <p id="rfc.section.3.1.4.2.p.4">If Content-Location is included in a <a href="#status.2xx" class="smpl">2xx (Successful)</a> response message and its value refers (after conversion to absolute form) to a URI that is the same as the effective request
    11411141                     URI, then the recipient <em class="bcp14">MAY</em> consider the payload to be a current representation of that resource at the time indicated by the message origination date.
    1142                      For a GET or HEAD request, this is the same as the default semantics when no Content-Location is provided by the server. For
    1143                      a state-changing request like PUT or POST, it implies that the server's response contains the new representation of that resource,
    1144                      thereby distinguishing it from representations that might only report about the action (e.g., "It worked!"). This allows authoring
    1145                      applications to update their local copies without the need for a subsequent GET request.
     1142                     For a GET (<a href="#GET" id="rfc.xref.GET.2" title="GET">Section&nbsp;4.3.1</a>) or HEAD (<a href="#HEAD" id="rfc.xref.HEAD.1" title="HEAD">Section&nbsp;4.3.2</a>) request, this is the same as the default semantics when no Content-Location is provided by the server. For a state-changing
     1143                     request like PUT (<a href="#PUT" id="rfc.xref.PUT.1" title="PUT">Section&nbsp;4.3.4</a>) or POST (<a href="#POST" id="rfc.xref.POST.1" title="POST">Section&nbsp;4.3.3</a>), it implies that the server's response contains the new representation of that resource, thereby distinguishing it from
     1144                     representations that might only report about the action (e.g., "It worked!"). This allows authoring applications to update
     1145                     their local copies without the need for a subsequent GET request.
    11461146                  </p>
    11471147                  <p id="rfc.section.3.1.4.2.p.5">If Content-Location is included in a <a href="#status.2xx" class="smpl">2xx (Successful)</a> response message and its field-value refers to a URI that differs from the effective request URI, then the origin server claims
     
    11931193            </p>
    11941194            <p id="rfc.section.3.3.p.2">The purpose of a payload in a request is defined by the method semantics. For example, a representation in the payload of
    1195                a PUT request (<a href="#PUT" id="rfc.xref.PUT.1" title="PUT">Section&nbsp;4.3.4</a>) represents the desired state of the <a href="#resources" class="smpl">target resource</a> if the request is successfully applied, whereas a representation in the payload of a POST request (<a href="#POST" id="rfc.xref.POST.1" title="POST">Section&nbsp;4.3.3</a>) represents information to be processed by the target resource.
     1195               a PUT request (<a href="#PUT" id="rfc.xref.PUT.2" title="PUT">Section&nbsp;4.3.4</a>) represents the desired state of the <a href="#resources" class="smpl">target resource</a> if the request is successfully applied, whereas a representation in the payload of a POST request (<a href="#POST" id="rfc.xref.POST.2" title="POST">Section&nbsp;4.3.3</a>) represents information to be processed by the target resource.
    11961196            </p>
    11971197            <p id="rfc.section.3.3.p.3">In a response, the payload's purpose is defined by both the request method and the response status code. For example, the
    1198                payload of a <a href="#status.200" class="smpl">200 (OK)</a> response to GET (<a href="#GET" id="rfc.xref.GET.2" title="GET">Section&nbsp;4.3.1</a>) represents the current state of the <a href="#resources" class="smpl">target resource</a>, 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.1.1.2</a>), whereas the payload of the same status code in a response to POST might represent either the processing result or the new
     1198               payload of a <a href="#status.200" class="smpl">200 (OK)</a> response to GET (<a href="#GET" id="rfc.xref.GET.3" title="GET">Section&nbsp;4.3.1</a>) represents the current state of the <a href="#resources" class="smpl">target resource</a>, 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.1.1.2</a>), whereas the payload of the same status code in a response to POST might represent either the processing result or the new
    11991199               state of the target resource after applying the processing. Response messages with an error status code usually contain a
    12001200               payload that represents the error condition, such that it describes the error state and what next steps are suggested for
     
    13491349                        <td class="left">GET</td>
    13501350                        <td class="left">Transfer a current representation of the target resource.</td>
    1351                         <td class="left"><a href="#GET" id="rfc.xref.GET.3" title="GET">4.3.1</a></td>
     1351                        <td class="left"><a href="#GET" id="rfc.xref.GET.4" title="GET">4.3.1</a></td>
    13521352                     </tr>
    13531353                     <tr>
    13541354                        <td class="left">HEAD</td>
    13551355                        <td class="left">Same as GET, but only transfer the status line and header section.</td>
    1356                         <td class="left"><a href="#HEAD" id="rfc.xref.HEAD.1" title="HEAD">4.3.2</a></td>
     1356                        <td class="left"><a href="#HEAD" id="rfc.xref.HEAD.2" title="HEAD">4.3.2</a></td>
    13571357                     </tr>
    13581358                     <tr>
    13591359                        <td class="left">POST</td>
    13601360                        <td class="left">Perform resource-specific processing on the request payload.</td>
    1361                         <td class="left"><a href="#POST" id="rfc.xref.POST.2" title="POST">4.3.3</a></td>
     1361                        <td class="left"><a href="#POST" id="rfc.xref.POST.3" title="POST">4.3.3</a></td>
    13621362                     </tr>
    13631363                     <tr>
    13641364                        <td class="left">PUT</td>
    13651365                        <td class="left">Replace all current representations of the target resource with the request payload.</td>
    1366                         <td class="left"><a href="#PUT" id="rfc.xref.PUT.2" title="PUT">4.3.4</a></td>
     1366                        <td class="left"><a href="#PUT" id="rfc.xref.PUT.3" title="PUT">4.3.4</a></td>
    13671367                     </tr>
    13681368                     <tr>
     
    35153515                           <td class="left">yes</td>
    35163516                           <td class="left">yes</td>
    3517                            <td class="left"><a href="#GET" id="rfc.xref.GET.4" title="GET">Section&nbsp;4.3.1</a>
     3517                           <td class="left"><a href="#GET" id="rfc.xref.GET.5" title="GET">Section&nbsp;4.3.1</a>
    35183518                           </td>
    35193519                        </tr>
     
    35223522                           <td class="left">yes</td>
    35233523                           <td class="left">yes</td>
    3524                            <td class="left"><a href="#HEAD" id="rfc.xref.HEAD.2" title="HEAD">Section&nbsp;4.3.2</a>
     3524                           <td class="left"><a href="#HEAD" id="rfc.xref.HEAD.3" title="HEAD">Section&nbsp;4.3.2</a>
    35253525                           </td>
    35263526                        </tr>
     
    35363536                           <td class="left">no</td>
    35373537                           <td class="left">no</td>
    3538                            <td class="left"><a href="#POST" id="rfc.xref.POST.3" title="POST">Section&nbsp;4.3.3</a>
     3538                           <td class="left"><a href="#POST" id="rfc.xref.POST.4" title="POST">Section&nbsp;4.3.3</a>
    35393539                           </td>
    35403540                        </tr>
     
    35433543                           <td class="left">no</td>
    35443544                           <td class="left">yes</td>
    3545                            <td class="left"><a href="#PUT" id="rfc.xref.PUT.3" title="PUT">Section&nbsp;4.3.4</a>
     3545                           <td class="left"><a href="#PUT" id="rfc.xref.PUT.4" title="PUT">Section&nbsp;4.3.4</a>
    35463546                           </td>
    35473547                        </tr>
     
    45224522            and the undesirable effect of potentially breaking relative links in content-negotiated resources. (<a href="#header.content-location" id="rfc.xref.header.content-location.5" title="Content-Location">Section&nbsp;3.1.4.2</a>)
    45234523         </p>
    4524          <p id="rfc.section.B.p.6">To be consistent with the method-neutral parsing algorithm of <a href="#Part1" id="rfc.xref.Part1.45"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, the definition of GET has been relaxed so that requests can have a body, even though a body has no meaning for GET. (<a href="#GET" id="rfc.xref.GET.5" title="GET">Section&nbsp;4.3.1</a>)
    4525          </p>
    4526          <p id="rfc.section.B.p.7">Servers are no longer required to handle all Content-* header fields and use of <a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> has been explicitly banned in PUT requests. (<a href="#PUT" id="rfc.xref.PUT.4" title="PUT">Section&nbsp;4.3.4</a>)
     4524         <p id="rfc.section.B.p.6">To be consistent with the method-neutral parsing algorithm of <a href="#Part1" id="rfc.xref.Part1.45"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, the definition of GET has been relaxed so that requests can have a body, even though a body has no meaning for GET. (<a href="#GET" id="rfc.xref.GET.6" title="GET">Section&nbsp;4.3.1</a>)
     4525         </p>
     4526         <p id="rfc.section.B.p.7">Servers are no longer required to handle all Content-* header fields and use of <a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> has been explicitly banned in PUT requests. (<a href="#PUT" id="rfc.xref.PUT.5" title="PUT">Section&nbsp;4.3.4</a>)
    45274527         </p>
    45284528         <p id="rfc.section.B.p.8">Definition of the CONNECT method has been moved from <a href="#RFC2817" id="rfc.xref.RFC2817.2"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a> to this specification. (<a href="#CONNECT" id="rfc.xref.CONNECT.3" title="CONNECT">Section&nbsp;4.3.6</a>)
     
    48764876            </li>
    48774877            <li><a id="rfc.index.G" href="#rfc.index.G"><b>G</b></a><ul>
    4878                   <li>GET method&nbsp;&nbsp;<a href="#rfc.xref.GET.1">3</a>, <a href="#rfc.xref.GET.2">3.3</a>, <a href="#rfc.xref.GET.3">4.1</a>, <a href="#rfc.iref.g.14"><b>4.3.1</b></a>, <a href="#rfc.xref.GET.4">8.1.3</a>, <a href="#rfc.xref.GET.5">B</a></li>
     4878                  <li>GET method&nbsp;&nbsp;<a href="#rfc.xref.GET.1">3</a>, <a href="#rfc.xref.GET.2">3.1.4.2</a>, <a href="#rfc.xref.GET.3">3.3</a>, <a href="#rfc.xref.GET.4">4.1</a>, <a href="#rfc.iref.g.14"><b>4.3.1</b></a>, <a href="#rfc.xref.GET.5">8.1.3</a>, <a href="#rfc.xref.GET.6">B</a></li>
    48794879                  <li><tt>Grammar</tt>&nbsp;&nbsp;
    48804880                     <ul>
     
    49384938            </li>
    49394939            <li><a id="rfc.index.H" href="#rfc.index.H"><b>H</b></a><ul>
    4940                   <li>HEAD method&nbsp;&nbsp;<a href="#rfc.xref.HEAD.1">4.1</a>, <a href="#rfc.iref.h.1"><b>4.3.2</b></a>, <a href="#rfc.xref.HEAD.2">8.1.3</a></li>
     4940                  <li>HEAD method&nbsp;&nbsp;<a href="#rfc.xref.HEAD.1">3.1.4.2</a>, <a href="#rfc.xref.HEAD.2">4.1</a>, <a href="#rfc.iref.h.1"><b>4.3.2</b></a>, <a href="#rfc.xref.HEAD.3">8.1.3</a></li>
    49414941               </ul>
    49424942            </li>
     
    50405040                  </li>
    50415041                  <li>payload&nbsp;&nbsp;<a href="#rfc.iref.p.1">3.3</a></li>
    5042                   <li>POST method&nbsp;&nbsp;<a href="#rfc.xref.POST.1">3.3</a>, <a href="#rfc.xref.POST.2">4.1</a>, <a href="#rfc.iref.p.2"><b>4.3.3</b></a>, <a href="#rfc.xref.POST.3">8.1.3</a></li>
    5043                   <li>PUT method&nbsp;&nbsp;<a href="#rfc.xref.PUT.1">3.3</a>, <a href="#rfc.xref.PUT.2">4.1</a>, <a href="#rfc.iref.p.3"><b>4.3.4</b></a>, <a href="#rfc.xref.PUT.3">8.1.3</a>, <a href="#rfc.xref.PUT.4">B</a></li>
     5042                  <li>POST method&nbsp;&nbsp;<a href="#rfc.xref.POST.1">3.1.4.2</a>, <a href="#rfc.xref.POST.2">3.3</a>, <a href="#rfc.xref.POST.3">4.1</a>, <a href="#rfc.iref.p.2"><b>4.3.3</b></a>, <a href="#rfc.xref.POST.4">8.1.3</a></li>
     5043                  <li>PUT method&nbsp;&nbsp;<a href="#rfc.xref.PUT.1">3.1.4.2</a>, <a href="#rfc.xref.PUT.2">3.3</a>, <a href="#rfc.xref.PUT.3">4.1</a>, <a href="#rfc.iref.p.3"><b>4.3.4</b></a>, <a href="#rfc.xref.PUT.4">8.1.3</a>, <a href="#rfc.xref.PUT.5">B</a></li>
    50445044               </ul>
    50455045            </li>
Note: See TracChangeset for help on using the changeset viewer.