Ignore:
Timestamp:
10/03/12 12:29:29 (11 years ago)
Author:
julian.reschke@…
Message:

clarify that 201 doesn't require Location header fields (see #331)

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

Legend:

Unmodified
Added
Removed

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

    r1572 r1577  
    460460  }
    461461  @bottom-center {
    462        content: "Expires September 10, 2012";
     462       content: "Expires September 11, 2012";
    463463  }
    464464  @bottom-right {
    … …  
    513513      <meta name="dct.creator" content="Reschke, J. F.">
    514514      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
    515       <meta name="dct.issued" scheme="ISO8601" content="2012-03-09">
     515      <meta name="dct.issued" scheme="ISO8601" content="2012-03-10">
    516516      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    517517      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext 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.">
    … …  
    544544            </tr>
    545545            <tr>
    546                <td class="left">Expires: September 10, 2012</td>
     546               <td class="left">Expires: September 11, 2012</td>
    547547               <td class="right">HP</td>
    548548            </tr>
    … …  
    597597            <tr>
    598598               <td class="left"></td>
    599                <td class="right">March 9, 2012</td>
     599               <td class="right">March 10, 2012</td>
    600600            </tr>
    601601         </tbody>
    … …  
    627627         in progress”.
    628628      </p>
    629       <p>This Internet-Draft will expire on September 10, 2012.</p>
     629      <p>This Internet-Draft will expire on September 11, 2012.</p>
    630630      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    631631      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    865865  <a href="#abnf.dependencies" class="smpl">URI-reference</a> = &lt;URI-reference, defined in <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>&gt;
    866866</pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a id="method" href="#method">Method</a></h1>
    867       <p id="rfc.section.2.p.1">The method token indicates the request method to be performed on the target resource (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.15"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The method is case-sensitive.
     867      <p id="rfc.section.2.p.1">The method token indicates the request method to be performed on the target resource (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.6</a> of <a href="#Part1" id="rfc.xref.Part1.15"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The method is case-sensitive.
    868868      </p>
    869869      <div id="rfc.figure.u.3"></div><pre class="inline"><span id="rfc.iref.g.1"></span>  <a href="#method" class="smpl">method</a>         = <a href="#core.rules" class="smpl">token</a>
    … …  
    10111011         </li>
    10121012         <li>
    1013             <p>Whether the header field is useful or allowable in trailers (see <a href="p1-messaging.html#chunked.encoding" title="Chunked Transfer Coding">Section 5.1</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
     1013            <p>Whether the header field is useful or allowable in trailers (see <a href="p1-messaging.html#chunked.encoding" title="Chunked Transfer Coding">Section 4.1</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
    10141014            </p>
    10151015         </li>
    … …  
    10621062               <tr>
    10631063                  <td class="left">Host</td>
    1064                   <td class="left"><a href="p1-messaging.html#header.host" title="Host">Section 8.2</a> of <a href="#Part1" id="rfc.xref.Part1.23"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a></td>
     1064                  <td class="left"><a href="p1-messaging.html#header.host" title="Host">Section 5.4</a> of <a href="#Part1" id="rfc.xref.Part1.23"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a></td>
    10651065               </tr>
    10661066               <tr>
    … …  
    11021102               <tr>
    11031103                  <td class="left">TE</td>
    1104                   <td class="left"><a href="p1-messaging.html#header.te" title="TE">Section 5.4</a> of <a href="#Part1" id="rfc.xref.Part1.24"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a></td>
     1104                  <td class="left"><a href="p1-messaging.html#header.te" title="TE">Section 4.4</a> of <a href="#Part1" id="rfc.xref.Part1.24"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a></td>
    11051105               </tr>
    11061106               <tr>
    … …  
    11131113      <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a>&nbsp;<a id="response.header.fields" href="#response.header.fields">Response Header Fields</a></h2>
    11141114      <p id="rfc.section.3.3.p.1">The response header fields allow the server to pass additional information about the response which cannot be placed in the
    1115          status-line. These header fields give information about the server and about further access to the target resource (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.25"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
     1115         status-line. These header fields give information about the server and about further access to the target resource (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.6</a> of <a href="#Part1" id="rfc.xref.Part1.25"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
    11161116      </p>
    11171117      <div id="rfc.table.u.3">
    … …  
    14411441      <p id="rfc.section.5.1.p.1">It is sometimes necessary to determine an identifier for the resource associated with a representation.</p>
    14421442      <p id="rfc.section.5.1.p.2">An HTTP request representation, when present, is always associated with an anonymous (i.e., unidentified) resource.</p>
    1443       <p id="rfc.section.5.1.p.3">In the common case, an HTTP response is a representation of the target resource (see <a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.27"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). However, this is not always the case. To determine the URI of the resource a response is associated with, the following
     1443      <p id="rfc.section.5.1.p.3">In the common case, an HTTP response is a representation of the target resource (see <a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.6</a> of <a href="#Part1" id="rfc.xref.Part1.27"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). However, this is not always the case. To determine the URI of the resource a response is associated with, the following
    14441444         rules are used (with the first applicable one being selected):
    14451445      </p>
    … …  
    16621662      </p>
    16631663      <p id="rfc.section.6.8.p.2">TRACE allows the client to see what is being received at the other end of the request chain and use that data for testing
    1664          or diagnostic information. The value of the Via header field (<a href="p1-messaging.html#header.via" title="Via">Section 8.4</a> of <a href="#Part1" id="rfc.xref.Part1.28"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) is of particular interest, since it acts as a trace of the request chain. Use of the Max-Forwards header field allows the
     1664         or diagnostic information. The value of the Via header field (<a href="p1-messaging.html#header.via" title="Via">Section 8.3</a> of <a href="#Part1" id="rfc.xref.Part1.28"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) is of particular interest, since it acts as a trace of the request chain. Use of the Max-Forwards header field allows the
    16651665         client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding messages in an
    16661666         infinite loop.
    … …  
    16741674         its behavior to blind forwarding of packets until the connection is closed.
    16751675      </p>
    1676       <p id="rfc.section.6.9.p.2">When using CONNECT, the request-target <em class="bcp14">MUST</em> use the authority form (<a href="p1-messaging.html#request-target" title="request-target">Section 3.1.1.2</a> of <a href="#Part1" id="rfc.xref.Part1.30"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>); i.e., the request-target consists of only the host name and port number of the tunnel destination, separated by a colon.
     1676      <p id="rfc.section.6.9.p.2">When using CONNECT, the request-target <em class="bcp14">MUST</em> use the authority form (<a href="p1-messaging.html#request-target" title="Request Target">Section 3.1.1.2</a> of <a href="#Part1" id="rfc.xref.Part1.30"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>); i.e., the request-target consists of only the host name and port number of the tunnel destination, separated by a colon.
    16771677         For example,
    16781678      </p>
    … …  
    17451745      <div id="rfc.iref.s.3"></div>
    17461746      <h3 id="rfc.section.7.1.2"><a href="#rfc.section.7.1.2">7.1.2</a>&nbsp;<a id="status.101" href="#status.101">101 Switching Protocols</a></h3>
    1747       <p id="rfc.section.7.1.2.p.1">The server understands and is willing to comply with the client's request, via the Upgrade message header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 8.3</a> of <a href="#Part1" id="rfc.xref.Part1.32"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>), for a change in the application protocol being used on this connection. The server will switch protocols to those defined
     1747      <p id="rfc.section.7.1.2.p.1">The server understands and is willing to comply with the client's request, via the Upgrade message header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 8.2</a> of <a href="#Part1" id="rfc.xref.Part1.32"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>), for a change in the application protocol being used on this connection. The server will switch protocols to those defined
    17481748         by the response's Upgrade header field immediately after the empty line which terminates the 101 response.
    17491749      </p>
    … …  
    17731773      <div id="rfc.iref.s.5"></div>
    17741774      <h3 id="rfc.section.7.2.2"><a href="#rfc.section.7.2.2">7.2.2</a>&nbsp;<a id="status.201" href="#status.201">201 Created</a></h3>
    1775       <p id="rfc.section.7.2.2.p.1">The request has been fulfilled and has resulted in a new resource being created. The newly created resource can be referenced
    1776          by the URI(s) returned in the payload of the response, with the most specific URI for the resource given by a Location header
    1777          field. The response can include a payload containing a list of resource characteristics and location(s) from which the user
    1778          or user agent can choose the one most appropriate.
    1779       </p>
    1780       <p id="rfc.section.7.2.2.p.2">The origin server <em class="bcp14">MUST</em> create the resource before returning the 201 status code. If the action cannot be carried out immediately, the server <em class="bcp14">SHOULD</em> respond with 202 (Accepted) response instead.
    1781       </p>
    1782       <p id="rfc.section.7.2.2.p.3">A 201 response <em class="bcp14">MAY</em> contain an ETag response header field indicating the current value of the entity-tag for the representation of the resource
     1775      <p id="rfc.section.7.2.2.p.1">The request has been fulfilled and has resulted in a new resource being created.</p>
     1776      <p id="rfc.section.7.2.2.p.2">The newly created resource is typically linked to from the response payload, with the most relevant URI also being carried
     1777         in the Location header field. If the newly created resource's URI is the same as the Effective Request URI, this information
     1778         can be omitted (e.g., in the case of a response to a PUT request).
     1779      </p>
     1780      <p id="rfc.section.7.2.2.p.3">The origin server <em class="bcp14">MUST</em> create the resource before returning the 201 status code. If the action cannot be carried out immediately, the server <em class="bcp14">SHOULD</em> respond with 202 (Accepted) response instead.
     1781      </p>
     1782      <p id="rfc.section.7.2.2.p.4">A 201 response <em class="bcp14">MAY</em> contain an ETag response header field indicating the current value of the entity-tag for the representation of the resource
    17831783         just created (see <a href="p4-conditional.html#header.etag" title="ETag">Section 2.3</a> of <a href="#Part4" id="rfc.xref.Part4.9"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>).
    17841784      </p>
    … …  
    20932093      <div id="rfc.iref.s.31"></div>
    20942094      <h3 id="rfc.section.7.4.15"><a href="#rfc.section.7.4.15">7.4.15</a>&nbsp;<a id="status.426" href="#status.426">426 Upgrade Required</a></h3>
    2095       <p id="rfc.section.7.4.15.p.1">The request can not be completed without a prior protocol upgrade. This response <em class="bcp14">MUST</em> include an Upgrade header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 8.3</a> of <a href="#Part1" id="rfc.xref.Part1.35"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) specifying the required protocols.
     2095      <p id="rfc.section.7.4.15.p.1">The request can not be completed without a prior protocol upgrade. This response <em class="bcp14">MUST</em> include an Upgrade header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 8.2</a> of <a href="#Part1" id="rfc.xref.Part1.35"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) specifying the required protocols.
    20962096      </p>
    20972097      <div id="rfc.figure.u.8"></div>
    … …  
    24362436</pre><p id="rfc.section.10.9.p.4">Example:</p>
    24372437      <div id="rfc.figure.u.35"></div><pre class="text">  Server: CERN/3.0 libwww/2.17
    2438 </pre><p id="rfc.section.10.9.p.6">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the Server header field. Instead, it <em class="bcp14">MUST</em> include a Via field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 8.4</a> of <a href="#Part1" id="rfc.xref.Part1.39"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
     2438</pre><p id="rfc.section.10.9.p.6">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the Server header field. Instead, it <em class="bcp14">MUST</em> include a Via field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 8.3</a> of <a href="#Part1" id="rfc.xref.Part1.39"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
    24392439      </p>
    24402440      <div class="note" id="rfc.section.10.9.p.7">
    … …  
    30873087      </p>
    30883088      <p id="rfc.section.A.p.16">In the description of the Server header field, the Via field was described as a SHOULD. The requirement was and is stated
    3089          correctly in the description of the Via header field in <a href="p1-messaging.html#header.via" title="Via">Section 8.4</a> of <a href="#Part1" id="rfc.xref.Part1.42"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section&nbsp;10.9</a>)
     3089         correctly in the description of the Via header field in <a href="p1-messaging.html#header.via" title="Via">Section 8.3</a> of <a href="#Part1" id="rfc.xref.Part1.42"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section&nbsp;10.9</a>)
    30903090      </p>
    30913091      <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;<a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1>
    … …  
    35083508         </li>
    35093509         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/302">http://tools.ietf.org/wg/httpbis/trac/ticket/302</a>&gt;: "Misplaced text on connection handling in p2"
     3510         </li>
     3511         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/331">http://tools.ietf.org/wg/httpbis/trac/ticket/331</a>&gt;: "clarify that 201 doesn't require Location header fields"
    35103512         </li>
    35113513         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/332">http://tools.ietf.org/wg/httpbis/trac/ticket/332</a>&gt;: "relax requirements on hypertext in 3/4/5xx error responses"
    … …  
    37033705                        <li><em>Section 3.2.5</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.18">3.1</a></li>
    37043706                        <li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.16">2.2.1</a>, <a href="#rfc.xref.Part1.26">5</a>, <a href="#rfc.xref.Part1.34">7.2.6</a></li>
    3705                         <li><em>Section 4.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.15">2</a>, <a href="#rfc.xref.Part1.25">3.3</a>, <a href="#rfc.xref.Part1.27">5.1</a></li>
    3706                         <li><em>Section 5.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.22">3.1</a></li>
    3707                         <li><em>Section 5.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.24">3.2</a></li>
     3707                        <li><em>Section 4.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.22">3.1</a></li>
     3708                        <li><em>Section 4.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.24">3.2</a></li>
     3709                        <li><em>Section 5.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.23">3.2</a></li>
     3710                        <li><em>Section 5.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.15">2</a>, <a href="#rfc.xref.Part1.25">3.3</a>, <a href="#rfc.xref.Part1.27">5.1</a></li>
    37083711                        <li><em>Section 6.2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.31">7.1.1</a>, <a href="#rfc.xref.Part1.37">10.3</a></li>
    37093712                        <li><em>Section 8.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.21">3.1</a></li>
    3710                         <li><em>Section 8.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.23">3.2</a></li>
    3711                         <li><em>Section 8.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.32">7.1.2</a>, <a href="#rfc.xref.Part1.35">7.4.15</a></li>
    3712                         <li><em>Section 8.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.28">6.8</a>, <a href="#rfc.xref.Part1.39">10.9</a>, <a href="#rfc.xref.Part1.42">A</a></li>
     3713                        <li><em>Section 8.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.32">7.1.2</a>, <a href="#rfc.xref.Part1.35">7.4.15</a></li>
     3714                        <li><em>Section 8.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.28">6.8</a>, <a href="#rfc.xref.Part1.39">10.9</a>, <a href="#rfc.xref.Part1.42">A</a></li>
    37133715                        <li><em>Section 9.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.29">6.8</a></li>
    37143716                        <li><em>Section 11</em>&nbsp;&nbsp;<a href="#rfc.xref.Part1.41">13</a></li>

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

    r1572 r1577  
    15081508<t>
    15091509   The request has been fulfilled and has resulted in a new resource being
    1510    created. The newly created resource can be referenced by the URI(s)
    1511    returned in the payload of the response, with the most specific URI
    1512    for the resource given by a Location header field. The response
    1513    can include a payload containing a list of resource
    1514    characteristics and location(s) from which the user or user agent can
    1515    choose the one most appropriate.
     1510   created.
     1511</t>
     1512<t>
     1513   The newly created resource is typically linked to from the response payload,
     1514   with the most relevant URI also being carried in the Location header field.
     1515   If the newly created resource's URI is the same as the Effective Request URI,
     1516   this information can be omitted (e.g., in the case of a response to a PUT
     1517   request). 
    15161518</t>
    15171519<t>
    … …  
    47134715    </t>
    47144716    <t>
     4717      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/331"/>:
     4718      "clarify that 201 doesn't require Location header fields"
     4719    </t>
     4720    <t>
    47154721      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/332"/>:
    47164722      "relax requirements on hypertext in 3/4/5xx error responses"
Note: See TracChangeset for help on using the changeset viewer.