Ignore:
Timestamp:
Mar 28, 2012, 9:29:49 AM (8 years ago)
Author:
julian.reschke@…
Message:

reorg experiment

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/experiment/p2-semantics.xml

    r1630 r1631  
    20932093</section>
    20942094
    2095 <section title="Representation" anchor="representation">
    2096 <t>
    2097    Request and Response messages &MAY; transfer a representation if not otherwise
    2098    restricted by the request method or response status code. A representation
    2099    consists of metadata (representation header fields) and data (representation
    2100    body).  When a complete or partial representation is enclosed in an HTTP message,
    2101    it is referred to as the payload of the message. HTTP representations
    2102    are defined in <xref target="payload"/>.
    2103 </t>
    2104 <t>
    2105    A representation body is only present in a message when a message body is
    2106    present, as described in &message-body;. The representation body is obtained
    2107    from the message body by decoding any Transfer-Encoding that might
    2108    have been applied to ensure safe and proper transfer of the message.
    2109 </t>
    2110 
    2111 <section title="Identifying the Resource Associated with a Representation" anchor="identifying.response.associated.with.representation">
    2112 <t>
    2113    It is sometimes necessary to determine an identifier for the resource
    2114    associated with a representation.
    2115 </t>
    2116 <t>
    2117    An HTTP request representation, when present, is always associated with an
    2118    anonymous (i.e., unidentified) resource.
    2119 </t>
    2120 <t>
    2121    In the common case, an HTTP response is a representation of the target
    2122    resource (see &effective-request-uri;). However, this is not always the
    2123    case. To determine the URI of the resource a response is associated with,
    2124    the following rules are used (with the first applicable one being selected):
    2125 </t>
    2126 <t><list style="numbers">
    2127    <t>If the response status code is 200 or 203 and the request method was GET,
    2128    the response payload is a representation of the target resource.</t>
    2129    <t>If the response status code is 204, 206, or 304 and the request method was GET
    2130    or HEAD, the response payload is a partial representation of the target
    2131    resource.</t>
    2132    <t>If the response has a Content-Location header field, and that URI is the same
    2133    as the effective request URI, the response payload is a representation of the
    2134    target resource.</t>
    2135    <t>If the response has a Content-Location header field, and that URI is not the
    2136    same as the effective request URI, then the response asserts that its
    2137    payload is a representation of the resource identified by the
    2138    Content-Location URI. However, such an assertion cannot be trusted unless
    2139    it can be verified by other means (not defined by HTTP).</t>
    2140    <t>Otherwise, the response is a representation of an anonymous (i.e.,
    2141    unidentified) resource.</t>
    2142 </list></t>
    2143 <t>
    2144   <cref anchor="TODO-req-uri">
    2145    The comparison function is going to have to be defined somewhere,
    2146    because we already need to compare URIs for things like cache invalidation.</cref>
    2147 </t>
    2148 </section>
    2149 
    2150 </section>
    2151 
    21522095
    21532096<section title="Common Protocol Parameters" anchor="common.protocol.parameters">
     
    26322575</section>
    26332576
    2634 <section title="Representation" anchor="representation-TODO">
     2577<section title="Representation">
    26352578<iref item="representation"/>
    26362579<t>
     
    26562599   describes the error and what next steps are suggested for resolving it.
    26572600</t>
     2601<t>
     2602   Request and Response messages &MAY; transfer a representation if not otherwise
     2603   restricted by the request method or response status code. A representation
     2604   consists of metadata (representation header fields) and data (representation
     2605   body).  When a complete or partial representation is enclosed in an HTTP message,
     2606   it is referred to as the payload of the message.<cref>MOVEDFIXME</cref>
     2607</t>
     2608<t>
     2609   A representation body is only present in a message when a message body is
     2610   present, as described in &message-body;. The representation body is obtained
     2611   from the message body by decoding any Transfer-Encoding that might
     2612   have been applied to ensure safe and proper transfer of the message.<cref>MOVEDFIXME</cref>
     2613</t>
     2614
     2615<section title="Identifying the Resource Associated with a Representation" anchor="identifying.response.associated.with.representation">
     2616<t>
     2617   It is sometimes necessary to determine an identifier for the resource
     2618   associated with a representation.
     2619</t>
     2620<t>
     2621   An HTTP request representation, when present, is always associated with an
     2622   anonymous (i.e., unidentified) resource.
     2623</t>
     2624<t>
     2625   In the common case, an HTTP response is a representation of the target
     2626   resource (see &effective-request-uri;). However, this is not always the
     2627   case. To determine the URI of the resource a response is associated with,
     2628   the following rules are used (with the first applicable one being selected):
     2629</t>
     2630<t><list style="numbers">
     2631   <t>If the response status code is 200 or 203 and the request method was GET,
     2632   the response payload is a representation of the target resource.</t>
     2633   <t>If the response status code is 204, 206, or 304 and the request method was GET
     2634   or HEAD, the response payload is a partial representation of the target
     2635   resource.</t>
     2636   <t>If the response has a Content-Location header field, and that URI is the same
     2637   as the effective request URI, the response payload is a representation of the
     2638   target resource.</t>
     2639   <t>If the response has a Content-Location header field, and that URI is not the
     2640   same as the effective request URI, then the response asserts that its
     2641   payload is a representation of the resource identified by the
     2642   Content-Location URI. However, such an assertion cannot be trusted unless
     2643   it can be verified by other means (not defined by HTTP).</t>
     2644   <t>Otherwise, the response is a representation of an anonymous (i.e.,
     2645   unidentified) resource.</t>
     2646</list></t>
     2647<t>
     2648  <cref anchor="TODO-req-uri">
     2649   The comparison function is going to have to be defined somewhere,
     2650   because we already need to compare URIs for things like cache invalidation.</cref>
     2651</t>
     2652</section>
    26582653
    26592654<section title="Representation Header Fields" anchor="representation.header.fields">
Note: See TracChangeset for help on using the changeset viewer.