Ignore:
Timestamp:
Mar 30, 2012, 9:42:29 AM (7 years ago)
Author:
julian.reschke@…
Message:

Step 13 of p2/p3-merge (see #351)

File:
1 edited

Legend:

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

    r1649 r1650  
    25872587
    25882588<section title="Representation" anchor="representation">
     2589<iref item="representation"/>
     2590<t>
     2591   A "<x:dfn>representation</x:dfn>" is information in a format that can be readily
     2592   communicated from one party to another.  A resource representation
     2593   is information that reflects the state of that resource, as observed
     2594   at some point in the past (e.g., in a response to GET) or to be
     2595   desired at some point in the future (e.g., in a PUT request).
     2596</t>
     2597<t>
     2598   Most, but not all, representations transferred via HTTP are intended
     2599   to be a representation of the target resource (the resource identified
     2600   by the effective request URI).  The precise semantics of a representation
     2601   are determined by the type of message (request or response), the request
     2602   method, the response status code, and the representation metadata.
     2603   For example, the above semantic is true for the representation in any
     2604   200 (OK) response to GET and for the representation in any PUT request.
     2605   A 200 response to PUT, in contrast, contains either a representation
     2606   that describes the successful action or a representation of the target
     2607   resource, with the latter indicated by a Content-Location header field
     2608   with the same value as the effective request URI.  Likewise, response
     2609   messages with an error status code usually contain a representation that
     2610   describes the error and what next steps are suggested for resolving it.
     2611</t>
    25892612<t>
    25902613   Request and Response messages &MAY; transfer a representation if not otherwise
     
    25932616   body).  When a complete or partial representation is enclosed in an HTTP message,
    25942617   it is referred to as the payload of the message.
     2618   <cref>#351</cref>
    25952619</t>
    25962620<t>
     
    25992623   from the message body by decoding any Transfer-Encoding that might
    26002624   have been applied to ensure safe and proper transfer of the message.
     2625   <cref>#351</cref>
    26012626</t>
    26022627
     
    26402665</section>
    26412666
     2667<section title="Representation Header Fields" anchor="representation.header.fields">
     2668  <x:anchor-alias value="representation-header"/>
     2669<t>
     2670   Representation header fields define metadata about the representation data
     2671   enclosed in the message body or, if no message body is present, about
     2672   the representation that would have been transferred in a 200 response
     2673   to a simultaneous GET request with the same effective request URI.
     2674</t>
     2675<t>
     2676   The following header fields are defined as representation metadata:
     2677</t>
     2678<texttable align="left">
     2679  <ttcol>Header Field Name</ttcol>
     2680  <ttcol>Defined in...</ttcol>
     2681
     2682  <c>Content-Encoding</c> <c><xref target="header.content-encoding"/></c>
     2683  <c>Content-Language</c> <c><xref target="header.content-language"/></c>
     2684  <c>Content-Location</c> <c><xref target="header.content-location"/></c>
     2685  <c>Content-Type</c> <c><xref target="header.content-type"/></c>
     2686  <c>Expires</c> <c>&header-expires;</c>
     2687</texttable>
     2688<t>
     2689   Additional header fields define metadata about the selected
     2690   representation, which might differ from the representation included
     2691   in the message for responses to some state-changing methods.
     2692   The following header fields are defined as selected representation
     2693   metadata:
     2694</t>
     2695<texttable align="left">
     2696  <ttcol>Header Field Name</ttcol>
     2697  <ttcol>Defined in...</ttcol>
     2698
     2699  <c>ETag</c> <c>&header-etag;</c>
     2700  <c>Last-Modified</c> <c>&header-last-modified;</c>
     2701</texttable>
     2702</section>
     2703
     2704<section title="Representation Data" anchor="representation.data">
     2705  <x:anchor-alias value="representation-data"/>
     2706<t>
     2707   The representation body associated with an HTTP message is
     2708   either provided as the payload body of the message or
     2709   referred to by the message semantics and the effective request
     2710   URI.  The representation data is in a format and encoding defined by
     2711   the representation metadata header fields.
     2712</t>
     2713<t>
     2714   The data type of the representation data
     2715   is determined via the header fields Content-Type and Content-Encoding.
     2716   These define a two-layer, ordered encoding model:
     2717</t>
     2718<figure><artwork type="example">
     2719  representation-data := Content-Encoding( Content-Type( bits ) )
     2720</artwork></figure>
     2721<t>
     2722   Content-Type specifies the media type of the underlying data, which
     2723   defines both the data format and how that data &SHOULD; be processed
     2724   by the recipient (within the scope of the request method semantics).
     2725   Any HTTP/1.1 message containing a payload body &SHOULD; include a
     2726   Content-Type header field defining the media type of the associated
     2727   representation unless that metadata is unknown to the sender.
     2728   If the Content-Type header field is not present, it indicates that
     2729   the sender does not know the media type of the representation;
     2730   recipients &MAY; either assume that the media type is
     2731   "application/octet-stream" (<xref target="RFC2046" x:fmt="," x:sec="4.5.1"/>)
     2732   or examine the content to determine its type.
     2733</t>
     2734<t>
     2735   In practice, resource owners do not always properly configure their origin
     2736   server to provide the correct Content-Type for a given representation,
     2737   with the result that some clients will examine a response body's content
     2738   and override the specified type.
     2739   Clients that do so risk drawing incorrect conclusions, which might expose
     2740   additional security risks (e.g., "privilege escalation").  Furthermore,
     2741   it is impossible to determine the sender's intent by examining the data
     2742   format: many data formats match multiple media types that differ only in
     2743   processing semantics.  Implementers are encouraged to provide a means of
     2744   disabling such "content sniffing" when it is used.
     2745</t>
     2746<t>
     2747   Content-Encoding is used to indicate any additional content
     2748   codings applied to the data, usually for the purpose of data
     2749   compression, that are a property of the representation.  If
     2750   Content-Encoding is not present, then there is no additional
     2751   encoding beyond that defined by the Content-Type.
     2752</t>
     2753</section>
    26422754</section>
    26432755
     
    66756787</section>
    66766788
    6677 <section title="THE TEXT FORMERLY KNOWN AS PART3">
    6678 
    6679 <section title="Representation" anchor="representation3">
    6680 <iref item="representation"/>
    6681 <t>
    6682    A "<x:dfn>representation</x:dfn>" is information in a format that can be readily
    6683    communicated from one party to another.  A resource representation
    6684    is information that reflects the state of that resource, as observed
    6685    at some point in the past (e.g., in a response to GET) or to be
    6686    desired at some point in the future (e.g., in a PUT request).
    6687 </t>
    6688 <t>
    6689    Most, but not all, representations transferred via HTTP are intended
    6690    to be a representation of the target resource (the resource identified
    6691    by the effective request URI).  The precise semantics of a representation
    6692    are determined by the type of message (request or response), the request
    6693    method, the response status code, and the representation metadata.
    6694    For example, the above semantic is true for the representation in any
    6695    200 (OK) response to GET and for the representation in any PUT request.
    6696    A 200 response to PUT, in contrast, contains either a representation
    6697    that describes the successful action or a representation of the target
    6698    resource, with the latter indicated by a Content-Location header field
    6699    with the same value as the effective request URI.  Likewise, response
    6700    messages with an error status code usually contain a representation that
    6701    describes the error and what next steps are suggested for resolving it.
    6702 </t>
    6703 
    6704 <section title="Representation Header Fields" anchor="representation.header.fields">
    6705   <x:anchor-alias value="representation-header"/>
    6706 <t>
    6707    Representation header fields define metadata about the representation data
    6708    enclosed in the message body or, if no message body is present, about
    6709    the representation that would have been transferred in a 200 response
    6710    to a simultaneous GET request with the same effective request URI.
    6711 </t>
    6712 <t>
    6713    The following header fields are defined as representation metadata:
    6714 </t>
    6715 <texttable align="left">
    6716   <ttcol>Header Field Name</ttcol>
    6717   <ttcol>Defined in...</ttcol>
    6718 
    6719   <c>Content-Encoding</c> <c><xref target="header.content-encoding"/></c>
    6720   <c>Content-Language</c> <c><xref target="header.content-language"/></c>
    6721   <c>Content-Location</c> <c><xref target="header.content-location"/></c>
    6722   <c>Content-Type</c> <c><xref target="header.content-type"/></c>
    6723   <c>Expires</c> <c>&header-expires;</c>
    6724 </texttable>
    6725 <t>
    6726    Additional header fields define metadata about the selected
    6727    representation, which might differ from the representation included
    6728    in the message for responses to some state-changing methods.
    6729    The following header fields are defined as selected representation
    6730    metadata:
    6731 </t>
    6732 <texttable align="left">
    6733   <ttcol>Header Field Name</ttcol>
    6734   <ttcol>Defined in...</ttcol>
    6735 
    6736   <c>ETag</c> <c>&header-etag;</c>
    6737   <c>Last-Modified</c> <c>&header-last-modified;</c>
    6738 </texttable>
    6739 </section>
    6740 
    6741 <section title="Representation Data" anchor="representation.data">
    6742   <x:anchor-alias value="representation-data"/>
    6743 <t>
    6744    The representation body associated with an HTTP message is
    6745    either provided as the payload body of the message or
    6746    referred to by the message semantics and the effective request
    6747    URI.  The representation data is in a format and encoding defined by
    6748    the representation metadata header fields.
    6749 </t>
    6750 <t>
    6751    The data type of the representation data
    6752    is determined via the header fields Content-Type and Content-Encoding.
    6753    These define a two-layer, ordered encoding model:
    6754 </t>
    6755 <figure><artwork type="example">
    6756   representation-data := Content-Encoding( Content-Type( bits ) )
    6757 </artwork></figure>
    6758 <t>
    6759    Content-Type specifies the media type of the underlying data, which
    6760    defines both the data format and how that data &SHOULD; be processed
    6761    by the recipient (within the scope of the request method semantics).
    6762    Any HTTP/1.1 message containing a payload body &SHOULD; include a
    6763    Content-Type header field defining the media type of the associated
    6764    representation unless that metadata is unknown to the sender.
    6765    If the Content-Type header field is not present, it indicates that
    6766    the sender does not know the media type of the representation;
    6767    recipients &MAY; either assume that the media type is
    6768    "application/octet-stream" (<xref target="RFC2046" x:fmt="," x:sec="4.5.1"/>)
    6769    or examine the content to determine its type.
    6770 </t>
    6771 <t>
    6772    In practice, resource owners do not always properly configure their origin
    6773    server to provide the correct Content-Type for a given representation,
    6774    with the result that some clients will examine a response body's content
    6775    and override the specified type.
    6776    Clients that do so risk drawing incorrect conclusions, which might expose
    6777    additional security risks (e.g., "privilege escalation").  Furthermore,
    6778    it is impossible to determine the sender's intent by examining the data
    6779    format: many data formats match multiple media types that differ only in
    6780    processing semantics.  Implementers are encouraged to provide a means of
    6781    disabling such "content sniffing" when it is used.
    6782 </t>
    6783 <t>
    6784    Content-Encoding is used to indicate any additional content
    6785    codings applied to the data, usually for the purpose of data
    6786    compression, that are a property of the representation.  If
    6787    Content-Encoding is not present, then there is no additional
    6788    encoding beyond that defined by the Content-Type.
    6789 </t>
    6790 </section>
    6791 </section>
    6792 </section>
    6793 
    67946789</back>
    67956790</rfc>
Note: See TracChangeset for help on using the changeset viewer.