Changeset 2349


Ignore:
Timestamp:
06/08/13 15:03:33 (10 years ago)
Author:
julian.reschke@…
Message:

note change for [2348] (see #487)

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

Legend:

Unmodified
Added
Removed

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

    r2344 r2349  
    449449  }
    450450  @bottom-center {
    451        content: "Expires February 6, 2014";
     451       content: "Expires February 7, 2014";
    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-08-05">
     496      <meta name="dct.issued" scheme="ISO8601" content="2013-08-06">
    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">August 5, 2013</td>
     524               <td class="right">August 6, 2013</td>
    525525            </tr>
    526526            <tr>
    527                <td class="left">Expires: February 6, 2014</td>
     527               <td class="left">Expires: February 7, 2014</td>
    528528               <td class="right"></td>
    529529            </tr>
    … …  
    553553         in progress”.
    554554      </p>
    555       <p>This Internet-Draft will expire on February 6, 2014.</p>
     555      <p>This Internet-Draft will expire on February 7, 2014.</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>
    … …  
    579579         <li><a href="#rfc.section.3">3.</a>&nbsp;&nbsp;&nbsp;<a href="#representations">Representations</a><ul>
    580580               <li><a href="#rfc.section.3.1">3.1</a>&nbsp;&nbsp;&nbsp;<a href="#representation.metadata">Representation Metadata</a><ul>
    581                      <li><a href="#rfc.section.3.1.1">3.1.1</a>&nbsp;&nbsp;&nbsp;<a href="#data.type">Processing the Data</a><ul>
     581                     <li><a href="#rfc.section.3.1.1">3.1.1</a>&nbsp;&nbsp;&nbsp;<a href="#data.type">Processing Representation Data</a><ul>
    582582                           <li><a href="#rfc.section.3.1.1.1">3.1.1.1</a>&nbsp;&nbsp;&nbsp;<a href="#media.type">Media Type</a></li>
    583583                           <li><a href="#rfc.section.3.1.1.2">3.1.1.2</a>&nbsp;&nbsp;&nbsp;<a href="#charset">Charset</a></li>
    … …  
    827827      </p>
    828828      <h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a id="resources" href="#resources">Resources</a></h1>
    829       <p id="rfc.section.2.p.1">The target of each HTTP request is called a resource. HTTP does not limit the nature of a resource; it merely defines an interface
     829      <p id="rfc.section.2.p.1">The target of a HTTP request is called a resource. HTTP does not limit the nature of a resource; it merely defines an interface
    830830         that might be used to interact with resources. Each resource is identified by a Uniform Resource Identifier (URI), as described
    831831         in <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a> of <a href="#Part1" id="rfc.xref.Part1.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>.
    … …  
    859859         same request had been a GET.
    860860      </p>
    861       <p id="rfc.section.3.1.p.2">The following header fields are defined to convey representation metadata:</p>
     861      <p id="rfc.section.3.1.p.2">The following header fields convey representation metadata:</p>
    862862      <div id="rfc.table.u.1">
    863863         <table class="tt full left" cellpadding="3" cellspacing="0">
    … …  
    888888         </table>
    889889      </div>
    890       <h3 id="rfc.section.3.1.1"><a href="#rfc.section.3.1.1">3.1.1</a>&nbsp;<a id="data.type" href="#data.type">Processing the Data</a></h3>
     890      <h3 id="rfc.section.3.1.1"><a href="#rfc.section.3.1.1">3.1.1</a>&nbsp;<a id="data.type" href="#data.type">Processing Representation Data</a></h3>
    891891      <h4 id="rfc.section.3.1.1.1"><a href="#rfc.section.3.1.1.1">3.1.1.1</a>&nbsp;<a id="media.type" href="#media.type">Media Type</a></h4>
    892892      <p id="rfc.section.3.1.1.1.p.1">HTTP uses Internet Media Types <a href="#RFC2046" id="rfc.xref.RFC2046.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a> in the <a href="#header.content-type" class="smpl">Content-Type</a> (<a href="#header.content-type" id="rfc.xref.header.content-type.2" title="Content-Type">Section&nbsp;3.1.1.5</a>) and <a href="#header.accept" class="smpl">Accept</a> (<a href="#header.accept" id="rfc.xref.header.accept.1" title="Accept">Section&nbsp;5.3.2</a>) header fields in order to provide open and extensible data typing and type negotiation. Media types define both a data format
    … …  
    983983         are primarily used to allow a representation to be compressed or otherwise usefully transformed without losing the identity
    984984         of its underlying media type and without loss of information. Frequently, the representation is stored in coded form, transmitted
    985          directly, and only decoded by the recipient.
     985         directly, and only decoded by the final recipient.
    986986      </p>
    987987      <div id="rfc.figure.u.7"></div><pre class="inline"><span id="rfc.iref.g.10"></span>  <a href="#content.codings" class="smpl">content-coding</a>   = <a href="#imported.abnf" class="smpl">token</a>
    … …  
    10731073      <ul>
    10741074         <li>If the request has a <a href="#header.content-location" class="smpl">Content-Location</a> header field, then the sender asserts that the payload is a representation of the resource identified by the Content-Location
    1075             field-value. However, such an assertion cannot be trusted unless it can be verified by other means (not defined by HTTP).
     1075            field-value. However, such an assertion cannot be trusted unless it can be verified by other means (not defined by this document).
    10761076            The information might still be useful for revision history links.
    10771077         </li>
    … …  
    10891089         <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 a URI different from the effective request URI, then the sender asserts
    10901090            that the payload is a representation of the resource identified by the Content-Location field-value. However, such an assertion
    1091             cannot be trusted unless it can be verified by other means (not defined by HTTP).
     1091            cannot be trusted unless it can be verified by other means (not defined by this document).
    10921092         </li>
    10931093         <li>Otherwise, the payload is unidentified.</li>
    … …  
    12021202         in applicability and practicality.
    12031203      </p>
    1204       <p id="rfc.section.3.4.p.3">Note that, in all cases, the supplier of representations to the origin server determines which representations might be considered
    1205          to be the "same information".
    1206       </p>
     1204      <p id="rfc.section.3.4.p.3">Note that, in all cases, the resource determines which representations might be considered to be the "same information".</p>
    12071205      <h3 id="rfc.section.3.4.1"><a href="#rfc.section.3.4.1">3.4.1</a>&nbsp;<a id="proactive.negotiation" href="#proactive.negotiation">Proactive Negotiation</a></h3>
    1208       <p id="rfc.section.3.4.1.p.1">When content negotiation preferences are sent by the user agent in a request in order to encourage an algorithm located at
    1209          the server to select the preferred representation, it is called <dfn>proactive negotiation</dfn> (a.k.a., <dfn>server-driven negotiation</dfn>). Selection is based on the available representations for a response (the dimensions over which it might vary, such as language,
     1206      <p id="rfc.section.3.4.1.p.1">When content negotiation preferences are sent by the user agent in a request to encourage an algorithm located at the server
     1207         to select the preferred representation, it is called <dfn>proactive negotiation</dfn> (a.k.a., <dfn>server-driven negotiation</dfn>). Selection is based on the available representations for a response (the dimensions over which it might vary, such as language,
    12101208         content-coding, etc.) compared to various information supplied in the request, including both the explicit negotiation fields
    12111209         of <a href="#request.conneg" title="Content Negotiation">Section&nbsp;5.3</a> and implicit characteristics, such as the client's network address or parts of the <a href="#header.user-agent" class="smpl">User-Agent</a> field.
    … …  
    12461244         the available representations so that the user or user agent can react by making a selection.
    12471245      </p>
    1248       <p id="rfc.section.3.4.2.p.3">Reactive negotiation is advantageous when the response would vary over commonly-used dimensions (such as type, language, or
     1246      <p id="rfc.section.3.4.2.p.3">Reactive negotiation can also be supported in successful responses (e.g., <a href="#status.200" class="smpl">200 (OK)</a> responses) if the payload format allows it.
     1247      </p>
     1248      <p id="rfc.section.3.4.2.p.4">Reactive negotiation is advantageous when the response would vary over commonly-used dimensions (such as type, language, or
    12491249         encoding), when the origin server is unable to determine a user agent's capabilities from examining the request, and generally
    12501250         when public caches are used to distribute server load and reduce network usage.
    12511251      </p>
    1252       <p id="rfc.section.3.4.2.p.4">Reactive negotiation suffers from the disadvantages of transmitting a list of alternatives to the user agent, which degrades
     1252      <p id="rfc.section.3.4.2.p.5">Reactive negotiation suffers from the disadvantages of transmitting a list of alternatives to the user agent, which degrades
    12531253         user-perceived latency if transmitted in the header section, and needing a second request to obtain an alternate representation.
    12541254         Furthermore, this specification does not define a mechanism for supporting automatic selection, though it does not prevent
    … …  
    12611261         by the semantics of some header fields when present in a request (<a href="#request.header.fields" title="Request Header Fields">Section&nbsp;5</a>) if those additional semantics do not conflict with the method.
    12621262      </p>
     1263      <p id="rfc.section.4.1.p.2">For example, a client can send conditional request header fields (<a href="#request.conditionals" title="Conditionals">Section&nbsp;5.2</a>) to make the requested action conditional on the current state of the target resource (<a href="#Part4" id="rfc.xref.Part4.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>).
     1264      </p>
    12631265      <div id="rfc.figure.u.17"></div><pre class="inline"><span id="rfc.iref.g.15"></span>  <a href="#method.overview" class="smpl">method</a> = <a href="#imported.abnf" class="smpl">token</a>
    1264 </pre><p id="rfc.section.4.1.p.3">HTTP was originally designed to be usable as an interface to distributed object systems. The request method was envisioned
     1266</pre><p id="rfc.section.4.1.p.4">HTTP was originally designed to be usable as an interface to distributed object systems. The request method was envisioned
    12651267         as applying semantics to a <a href="#resources" class="smpl">target resource</a> in much the same way as invoking a defined method on an identified object would apply semantics. The method token is case-sensitive
    12661268         because it might be used as a gateway to object-based systems with case-sensitive method names.
    12671269      </p>
    1268       <p id="rfc.section.4.1.p.4">Unlike distributed objects, the standardized request methods in HTTP are not resource-specific, since uniform interfaces provide
     1270      <p id="rfc.section.4.1.p.5">Unlike distributed objects, the standardized request methods in HTTP are not resource-specific, since uniform interfaces provide
    12691271         for better visibility and reuse in network-based systems <a href="#REST" id="rfc.xref.REST.2"><cite title="Architectural Styles and the Design of Network-based Software Architectures">[REST]</cite></a>. Once defined, a standardized method ought to have the same semantics when applied to any resource, though each resource
    12701272         determines for itself whether those semantics are implemented or allowed.
    12711273      </p>
    1272       <p id="rfc.section.4.1.p.5">This specification defines a number of standardized methods that are commonly used in HTTP, as outlined by the following table.
     1274      <p id="rfc.section.4.1.p.6">This specification defines a number of standardized methods that are commonly used in HTTP, as outlined by the following table.
    12731275         By convention, standardized methods are defined in all-uppercase ASCII letters.
    12741276      </p>
    … …  
    13271329         </table>
    13281330      </div>
    1329       <p id="rfc.section.4.1.p.6">All general-purpose servers <em class="bcp14">MUST</em> support the methods GET and HEAD. All other methods are <em class="bcp14">OPTIONAL</em>; when implemented, a server <em class="bcp14">MUST</em> implement the above methods according to the semantics defined for them in <a href="#method.definitions" title="Method Definitions">Section&nbsp;4.3</a>.
    1330       </p>
    1331       <p id="rfc.section.4.1.p.7">Additional methods, outside the scope of this specification, have been standardized for use in HTTP. All such methods ought
     1331      <p id="rfc.section.4.1.p.7">All general-purpose servers <em class="bcp14">MUST</em> support the methods GET and HEAD. All other methods are <em class="bcp14">OPTIONAL</em>; when implemented, a server <em class="bcp14">MUST</em> implement the above methods according to the semantics defined for them in <a href="#method.definitions" title="Method Definitions">Section&nbsp;4.3</a>.
     1332      </p>
     1333      <p id="rfc.section.4.1.p.8">Additional methods, outside the scope of this specification, have been standardized for use in HTTP. All such methods ought
    13321334         to be registered within the HTTP Method Registry maintained by IANA, as defined in <a href="#method.registry" title="Method Registry">Section&nbsp;8.1</a>.
    13331335      </p>
    1334       <p id="rfc.section.4.1.p.8">The set of methods allowed by a target resource can be listed in an <a href="#header.allow" class="smpl">Allow</a> header field (<a href="#header.allow" id="rfc.xref.header.allow.1" title="Allow">Section&nbsp;7.4.1</a>). However, the set of allowed methods can change dynamically. When a request method is received that is unrecognized or not
     1336      <p id="rfc.section.4.1.p.9">The set of methods allowed by a target resource can be listed in an <a href="#header.allow" class="smpl">Allow</a> header field (<a href="#header.allow" id="rfc.xref.header.allow.1" title="Allow">Section&nbsp;7.4.1</a>). However, the set of allowed methods can change dynamically. When a request method is received that is unrecognized or not
    13351337         implemented by an origin server, the origin server <em class="bcp14">SHOULD</em> respond with the <a href="#status.501" class="smpl">501 (Not Implemented)</a> status code. When a request method is received that is known by an origin server but not allowed for the target resource,
    13361338         the origin server <em class="bcp14">SHOULD</em> respond with the <a href="#status.405" class="smpl">405 (Method Not Allowed)</a> status code.
    1337       </p>
    1338       <p id="rfc.section.4.1.p.9">A client can send conditional request header fields (<a href="#request.conditionals" title="Conditionals">Section&nbsp;5.2</a>) to make the requested action conditional on the current state of the target resource (<a href="#Part4" id="rfc.xref.Part4.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>).
    13391339      </p>
    13401340      <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a>&nbsp;<a id="method.properties" href="#method.properties">Common Method Properties</a></h2>
    … …  
    15341534         use DELETE based on an assumption that the server's URI space has been crafted to correspond to a version repository.
    15351535      </p>
    1536       <p id="rfc.section.4.3.5.p.4">If a DELETE method is successfully applied, the origin server <em class="bcp14">SHOULD</em> send a <a href="#status.202" class="smpl">202 (Accepted)</a> status code if the action seems okay but has not yet been enacted, a <a href="#status.204" class="smpl">204 (No Content)</a> status code if the action has been enacted and no further information is to be supplied, or a <a href="#status.200" class="smpl">200 (OK)</a> status code if the action has been enacted and the response message includes a representation describing the status.
     1536      <p id="rfc.section.4.3.5.p.4">If a DELETE method is successfully applied, the origin server <em class="bcp14">SHOULD</em> send a <a href="#status.202" class="smpl">202 (Accepted)</a> status code if the action will likely succeed but has not yet been enacted, a <a href="#status.204" class="smpl">204 (No Content)</a> status code if the action has been enacted and no further information is to be supplied, or a <a href="#status.200" class="smpl">200 (OK)</a> status code if the action has been enacted and the response message includes a representation describing the status.
    15371537      </p>
    15381538      <p id="rfc.section.4.3.5.p.5">A payload within a DELETE request message has no defined semantics; sending a payload body on a DELETE request might cause
    … …  
    15831583      <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>
    15841584      <div id="rfc.iref.o.1"></div>
    1585       <p id="rfc.section.4.3.7.p.1">The OPTIONS method requests information about the communication options available on the request/response chain identified
    1586          by the effective request URI. This method allows a client to determine the options and/or requirements associated with a resource,
    1587          or the capabilities of a server, without implying a resource action.
     1585      <p id="rfc.section.4.3.7.p.1">The OPTIONS method requests information about the communication options available for the target resource, either at the origin
     1586         server or an intervening intermediary. This method allows a client to determine the options and/or requirements associated
     1587         with a resource, or the capabilities of a server, without implying a resource action.
    15881588      </p>
    15891589      <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
    … …  
    26872687         why the request has been forbidden can describe that reason in the response payload (if any).
    26882688      </p>
    2689       <p id="rfc.section.6.5.3.p.2">If authentication credentials were provided in the request, the server considers them insufficient to grant access. The client <em class="bcp14">SHOULD NOT</em> repeat the request with the same credentials. The client <em class="bcp14">MAY</em> repeat the request with new or different credentials. However, a request might be forbidden for reasons unrelated to the credentials.
     2689      <p id="rfc.section.6.5.3.p.2">If authentication credentials were provided in the request, the server considers them insufficient to grant access. The client <em class="bcp14">SHOULD NOT</em> automatically repeat the request with the same credentials. The client <em class="bcp14">MAY</em> repeat the request with new or different credentials. However, a request might be forbidden for reasons unrelated to the credentials.
    26902690      </p>
    26912691      <p id="rfc.section.6.5.3.p.3">An origin server that wishes to "hide" the current existence of a forbidden <a href="#resources" class="smpl">target resource</a> <em class="bcp14">MAY</em> instead respond with a status code of <a href="#status.404" class="smpl">404 (Not Found)</a>.
    … …  
    27212721      <div id="rfc.iref.76"></div>
    27222722      <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>
    2723       <p id="rfc.section.6.5.8.p.1">The <dfn>409 (Conflict)</dfn> status code indicates that the request could not be completed due to a conflict with the current state of the resource. This
    2724          code is used in situations where the user might be able to resolve the conflict and resubmit the request. The server <em class="bcp14">SHOULD</em> generate a payload that includes enough information for a user to recognize the source of the conflict.
     2723      <p id="rfc.section.6.5.8.p.1">The <dfn>409 (Conflict)</dfn> status code indicates that the request could not be completed due to a conflict with the current state of the target resource.
     2724         This code is used in situations where the user might be able to resolve the conflict and resubmit the request. The server <em class="bcp14">SHOULD</em> generate a payload that includes enough information for a user to recognize the source of the conflict.
    27252725      </p>
    27262726      <p id="rfc.section.6.5.8.p.2">Conflicts are most likely to occur in response to a PUT request. For example, if versioning were being used and the representation
    … …  
    45314531         </li>
    45324532         <li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/478">http://tools.ietf.org/wg/httpbis/trac/ticket/478</a>&gt;: "MUSTs and other feedback"
     4533         </li>
     4534         <li>&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/487">http://tools.ietf.org/wg/httpbis/trac/ticket/487</a>&gt;: "Resubmission of 403"
    45334535         </li>
    45344536      </ul>

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

    r2348 r2349  
    64166416      "MUSTs and other feedback"
    64176417    </t>
     6418    <t>
     6419      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/487"/>:
     6420      "Resubmission of 403"
     6421    </t>
    64186422  </list>
    64196423</t>
Note: See TracChangeset for help on using the changeset viewer.