Ignore:
Timestamp:
05/01/13 13:09:32 (10 years ago)
Author:
fielding@…
Message:

(editorial) more consistency regarding representation

Location:
draft-ietf-httpbis/latest
Files:
2 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>.

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

    r2089 r2090  
    207207   HTTP provides a uniform interface for interacting with a resource
    208208   (<xref target="resources"/>), regardless of its type, nature, or
    209    implementation, and for transferring content  in message payloads in the
    210    form of a representation (<xref target="representations"/>).
     209   implementation, via the manipulation and transfer of representations
     210   (<xref target="representations"/>).
    211211</t>
    212212<t>
    … …  
    486486   assume a media type of
    487487   "application/octet-stream" (<xref target="RFC2046" x:fmt="," x:sec="4.5.1"/>)
    488    or examine the representation data to determine its type.
     488   or examine the data to determine its type.
    489489</t>
    490490<t>
    … …  
    774774   response message and its field-value refers to a URI that differs from the
    775775   effective request URI, then the origin server claims that the field-value
    776    is an identifier for the payload's representation. Such a claim can only be
    777    trusted if both identifiers share the same resource owner, which cannot be
    778    programmatically determined via HTTP.
     776   is an identifier for the representation enclosed as the payload. Such a
     777   claim can only be trusted if both identifiers share the same resource
     778   owner, which cannot be programmatically determined via HTTP.
    779779   <list style="symbols">
    780780    <t>For a response to a GET or HEAD request, this is an indication that the
    … …  
    813813<t>
    814814   For example, if a client makes a PUT request on a negotiated resource and
    815    the origin server accepts that PUT (without redirection), then the new set
    816    of values for that resource is expected to be consistent with the one
     815   the origin server accepts that PUT (without redirection), then the new
     816   state of that resource is expected to be consistent with the one
    817817   representation supplied in that PUT; the Content-Location cannot be used as
    818818   a form of reverse content selection identifier to update only one of the
    … …  
    868868<t>
    869869   Likewise, the payload of a <x:ref>200 (OK)</x:ref> response to GET
    870    (<xref target="GET"/>) contains a representation of the <x:ref>target resource</x:ref>,
    871    as observed at the time of the message origination date
    872    (<xref target="header.date"/>), whereas the same status code in a response
    873    to POST might contain either a representation of the processing result or
    874    a current representation of the target resource after applying the
    875    processing. Response messages with an error status code usually contain
    876    a representation that describes the error and what next steps are suggested
    877    for resolving it.
     870   (<xref target="GET"/>) ought to contain a representation of the
     871   <x:ref>target resource</x:ref>, as observed at the time of the message
     872   origination date (<xref target="header.date"/>), whereas the same status
     873   code in a response to POST might contain either a representation of the
     874   processing result or a current representation of the target resource after
     875   applying the processing. Response messages with an error status code
     876   usually contain a representation of the error condition, such that it
     877   describes the error state and what next steps are suggested for resolving
     878   it.
    878879</t>
    879880<t>
    … …  
    896897  <x:anchor-alias value="content negotiation"/>
    897898<t>
    898    When responses convey a representation, whether indicating a success or
     899   When responses convey payload information, whether indicating a success or
    899900   an error, the origin server often has different ways of representing that
    900901   information; for example, in different formats, languages, or encodings.
    … …  
    12881289   in the HTTP header fields in response to a HEAD request &SHOULD; be identical
    12891290   to the information sent in response to a GET request. This method can
    1290    be used for obtaining metadata about the representation implied by the
    1291    request without transferring the representation data. This method is
     1291   be used for obtaining metadata about the selected representation
     1292   without transferring the representation data. This method is
    12921293   often used for testing hypertext links for validity, accessibility,
    12931294   and recent modification.
Note: See TracChangeset for help on using the changeset viewer.