Changeset 2090 for draft-ietf-httpbis/latest/p2-semantics.html
- Timestamp:
- 05/01/13 13:09:32 (9 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r2089 r2090 806 806 This document defines HTTP/1.1 request and response semantics in terms of the architecture defined in <a href="#Part1" id="rfc.xref.Part1.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>. 807 807 </p> 808 <p id="rfc.section.1.p.2">HTTP provides a uniform interface for interacting with a resource (<a href="#resources" title="Resources">Section 2</a>), regardless of its type, nature, or implementation, and for transferring content in message payloads in the form of a representation 809 (<a href="#representations" title="Representations">Section 3</a>). 808 <p id="rfc.section.1.p.2">HTTP provides a uniform interface for interacting with a resource (<a href="#resources" title="Resources">Section 2</a>), regardless of its type, nature, or implementation, via the manipulation and transfer of representations (<a href="#representations" title="Representations">Section 3</a>). 810 809 </p> 811 810 <p id="rfc.section.1.p.3">HTTP semantics include the intentions defined by each request method (<a href="#methods" title="Request Methods">Section 4</a>), extensions to those semantics that might be described in request header fields (<a href="#request.header.fields" title="Request Header Fields">Section 5</a>), the meaning of status codes to indicate a machine-readable response (<a href="#status.codes" title="Response Status Codes">Section 6</a>), and the meaning of other control data and resource metadata that might be given in response header fields (<a href="#response.header.fields" title="Response Header Fields">Section 7</a>). … … 959 958 <div id="rfc.figure.u.6"></div><pre class="text"> Content-Type: text/html; charset=ISO-8859-4 960 959 </pre><p id="rfc.section.3.1.1.5.p.5">A sender that generates a message containing a payload body <em class="bcp14">SHOULD</em> generate a Content-Type header field in that message unless the intended media type of the enclosed representation is unknown 961 to the sender. If a Content-Type header field is not present, recipients <em class="bcp14">MAY</em> either assume a media type of "application/octet-stream" (<a href="#RFC2046" id="rfc.xref.RFC2046.3"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a>, <a href="http://tools.ietf.org/html/rfc2046#section-4.5.1">Section 4.5.1</a>) or examine the representationdata to determine its type.960 to the sender. If a Content-Type header field is not present, recipients <em class="bcp14">MAY</em> either assume a media type of "application/octet-stream" (<a href="#RFC2046" id="rfc.xref.RFC2046.3"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a>, <a href="http://tools.ietf.org/html/rfc2046#section-4.5.1">Section 4.5.1</a>) or examine the data to determine its type. 962 961 </p> 963 962 <p id="rfc.section.3.1.1.5.p.6">In practice, resource owners do not always properly configure their origin server to provide the correct Content-Type for … … 1108 1107 </p> 1109 1108 <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 1110 that the field-value is an identifier for the payload's representation. Such a claim can only be trusted if both identifiers1111 share the same resource owner, which cannot be programmatically determined via HTTP.1109 that the field-value is an identifier for the representation enclosed as the payload. Such a claim can only be trusted if 1110 both identifiers share the same resource owner, which cannot be programmatically determined via HTTP. 1112 1111 </p> 1113 1112 <ul> … … 1131 1130 </p> 1132 1131 <p id="rfc.section.3.1.4.2.p.8">For example, if a client makes a PUT request on a negotiated resource and the origin server accepts that PUT (without redirection), 1133 then the new set of values for that resource is expected to be consistent with the one representation supplied in that PUT; 1134 the Content-Location cannot be used as a form of reverse content selection identifier to update only one of the negotiated 1135 representations. If the user agent had wanted the latter semantics, it would have applied the PUT directly to the Content-Location 1136 URI. 1132 then the new state of that resource is expected to be consistent with the one representation supplied in that PUT; the Content-Location 1133 cannot be used as a form of reverse content selection identifier to update only one of the negotiated representations. If 1134 the user agent had wanted the latter semantics, it would have applied the PUT directly to the Content-Location URI. 1137 1135 </p> 1138 1136 <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a> <a id="representation.data" href="#representation.data">Representation Data</a></h2> … … 1155 1153 an HTML form. 1156 1154 </p> 1157 <p id="rfc.section.3.3.p.4">Likewise, the payload of a <a href="#status.200" class="smpl">200 (OK)</a> response to GET (<a href="#GET" id="rfc.xref.GET.1" title="GET">Section 4.3.1</a>) containsa representation 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 7.1.1.2</a>), whereas the same status code in a response to POST might contain either a representation of the processing result or a1155 <p id="rfc.section.3.3.p.4">Likewise, the payload of a <a href="#status.200" class="smpl">200 (OK)</a> response to GET (<a href="#GET" id="rfc.xref.GET.1" title="GET">Section 4.3.1</a>) ought to contain a representation 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 7.1.1.2</a>), whereas the same status code in a response to POST might contain either a representation of the processing result or a 1158 1156 current representation of the target resource after applying the processing. Response messages with an error status code usually 1159 contain a representation that describes the error and what next steps are suggested for resolving it. 1157 contain a representation of the error condition, such that it describes the error state and what next steps are suggested 1158 for resolving it. 1160 1159 </p> 1161 1160 <p id="rfc.section.3.3.p.5">Header fields that specifically describe the payload, rather than the associated representation, are referred to as "payload … … 1187 1186 </div> 1188 1187 <h2 id="rfc.section.3.4"><a href="#rfc.section.3.4">3.4</a> <a id="content.negotiation" href="#content.negotiation">Content Negotiation</a></h2> 1189 <p id="rfc.section.3.4.p.1">When responses convey a representation, whether indicating a success or an error, the origin server often has different ways1190 of representing that information; for example, in different formats, languages, or encodings. Likewise, different users or1191 user agents might have differing capabilities, characteristics, or preferences that could influence which representation,1188 <p id="rfc.section.3.4.p.1">When responses convey payload information, whether indicating a success or an error, the origin server often has different 1189 ways of representing that information; for example, in different formats, languages, or encodings. Likewise, different users 1190 or user agents might have differing capabilities, characteristics, or preferences that could influence which representation, 1192 1191 among those available, would be best to deliver. For this reason, HTTP provides mechanisms for <a href="#content.negotiation" class="smpl">content negotiation</a>. 1193 1192 </p> … … 1409 1408 <div id="rfc.iref.h.1"></div> 1410 1409 <p id="rfc.section.4.3.2.p.1">The HEAD method is identical to GET except that the server <em class="bcp14">MUST NOT</em> send a message body in the response. The metadata contained in the HTTP header fields in response to a HEAD request <em class="bcp14">SHOULD</em> be identical to the information sent in response to a GET request. This method can be used for obtaining metadata about the 1411 representation implied by the request without transferring the representation data. This method is often used for testing1412 hypertext linksfor validity, accessibility, and recent modification.1410 selected representation without transferring the representation data. This method is often used for testing hypertext links 1411 for validity, accessibility, and recent modification. 1413 1412 </p> 1414 1413 <p id="rfc.section.4.3.2.p.2">The response to a HEAD request is cacheable and <em class="bcp14">MAY</em> be used to satisfy a subsequent HEAD request. It also has potential side effects on previously stored 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>.
Note: See TracChangeset
for help on using the changeset viewer.