Ignore:
Timestamp:
Jan 5, 2013, 5:09:32 AM (7 years ago)
Author:
fielding@…
Message:

(editorial) more consistency regarding representation

File:
1 edited

Legend:

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

    r2089 r2090  
    806806         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>.
    807807      </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&nbsp;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&nbsp;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&nbsp;2</a>), regardless of its type, nature, or implementation, via the manipulation and transfer of representations (<a href="#representations" title="Representations">Section&nbsp;3</a>).
    810809      </p>
    811810      <p id="rfc.section.1.p.3">HTTP semantics include the intentions defined by each request method (<a href="#methods" title="Request Methods">Section&nbsp;4</a>), extensions to those semantics that might be described in request header fields (<a href="#request.header.fields" title="Request Header Fields">Section&nbsp;5</a>), the meaning of status codes to indicate a machine-readable response (<a href="#status.codes" title="Response Status Codes">Section&nbsp;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&nbsp;7</a>).
     
    959958      <div id="rfc.figure.u.6"></div><pre class="text">  Content-Type: text/html; charset=ISO-8859-4
    960959</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 representation data 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.
    962961      </p>
    963962      <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
     
    11081107      </p>
    11091108      <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 identifiers
    1111          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.
    11121111      </p>
    11131112      <ul>
     
    11311130      </p>
    11321131      <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.
    11371135      </p>
    11381136      <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;<a id="representation.data" href="#representation.data">Representation Data</a></h2>
     
    11551153         an HTML form.
    11561154      </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&nbsp;4.3.1</a>) contains 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&nbsp;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
     1155      <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&nbsp;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&nbsp;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
    11581156         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.
    11601159      </p>
    11611160      <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
     
    11871186      </div>
    11881187      <h2 id="rfc.section.3.4"><a href="#rfc.section.3.4">3.4</a>&nbsp;<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 ways
    1190          of representing that information; for example, in different formats, languages, or encodings. Likewise, different users or
    1191          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,
    11921191         among those available, would be best to deliver. For this reason, HTTP provides mechanisms for <a href="#content.negotiation" class="smpl">content negotiation</a>.
    11931192      </p>
     
    14091408      <div id="rfc.iref.h.1"></div>
    14101409      <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 testing
    1412          hypertext links for 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.
    14131412      </p>
    14141413      <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.