Ignore:
Timestamp:
22/09/12 05:32:51 (8 years ago)
Author:
fielding@…
Message:

(editorial) move payload below representation header fields and representation body sections

File:
1 edited

Legend:

Unmodified
Added
Removed

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

    r1907 r1909  
    305305</t>
    306306
     307<section title="Representation Header Fields" anchor="representation.header.fields">
     308  <x:anchor-alias value="representation-header"/>
     309<t>
     310   Representation header fields define metadata about the representation data
     311   enclosed in the message body or, if no message body is present, about
     312   the representation that would have been transferred in a <x:ref>200 (OK)</x:ref>
     313   response to a simultaneous GET request with the same effective request URI.
     314</t>
     315<t>
     316   The following header fields are defined as representation metadata:
     317</t>
     318<texttable align="left">
     319  <ttcol>Header Field Name</ttcol>
     320  <ttcol>Defined in...</ttcol>
     321
     322  <c>Content-Type</c> <c><xref target="header.content-type"/></c>
     323  <c>Content-Encoding</c> <c><xref target="header.content-encoding"/></c>
     324  <c>Content-Language</c> <c><xref target="header.content-language"/></c>
     325  <c>Content-Location</c> <c><xref target="header.content-location"/></c>
     326  <c>Expires</c> <c>&header-expires;</c>
     327</texttable>
     328
     329<section title="Content-Type" anchor="header.content-type">
     330  <iref primary="true" item="Content-Type header field" x:for-anchor=""/>
     331  <x:anchor-alias value="Content-Type"/>
     332<t>
     333   The "Content-Type" header field indicates the media type of the
     334   representation. In the case of responses to the HEAD method, the media type is
     335   that which would have been sent had the request been a GET.
     336</t>
     337<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Type"/>
     338  <x:ref>Content-Type</x:ref> = <x:ref>media-type</x:ref>
     339</artwork></figure>
     340<t>
     341   Media types are defined in <xref target="media.types"/>. An example of the field is
     342</t>
     343<figure><artwork type="example">
     344  Content-Type: text/html; charset=ISO-8859-4
     345</artwork></figure>
     346<t>
     347   Further discussion of Content-Type is provided in <xref target="representation.data"/>.
     348</t>
     349</section>
     350
     351<section title="Content-Encoding" anchor="header.content-encoding">
     352  <iref primary="true" item="Content-Encoding header field" x:for-anchor=""/>
     353  <x:anchor-alias value="Content-Encoding"/>
     354<t>
     355   The "Content-Encoding" header field indicates what content-codings
     356   have been applied to the representation beyond those inherent in the media
     357   type, and thus what decoding mechanisms have to be applied in order to obtain
     358   the media-type referenced by the <x:ref>Content-Type</x:ref> header field.
     359   Content-Encoding is primarily used to allow a representation to be
     360   compressed without losing the identity of its underlying media type.
     361</t>
     362<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Encoding"/>
     363  <x:ref>Content-Encoding</x:ref> = 1#<x:ref>content-coding</x:ref>
     364</artwork></figure>
     365<t>
     366   Content codings are defined in <xref target="content.codings"/>. An example of its use is
     367</t>
     368<figure><artwork type="example">
     369  Content-Encoding: gzip
     370</artwork></figure>
     371<t>
     372   The content-coding is a characteristic of the representation.
     373   Typically, the representation body is stored with this
     374   encoding and is only decoded before rendering or analogous usage.
     375   However, a transforming proxy &MAY; modify the content-coding if the
     376   new coding is known to be acceptable to the recipient, unless the
     377   "no-transform" cache-control directive is present in the message.
     378</t>
     379<t>
     380   If the media type includes an inherent encoding, such as a data format
     381   that is always compressed, then that encoding would not be restated as
     382   a Content-Encoding even if it happens to be the same algorithm as one
     383   of the content-codings.  Such a content-coding would only be listed if,
     384   for some bizarre reason, it is applied a second time to form the
     385   representation.  Likewise, an origin server might choose to publish the
     386   same payload data as multiple representations that differ only in whether
     387   the coding is defined as part of <x:ref>Content-Type</x:ref> or
     388   Content-Encoding, since some user agents will behave differently in their
     389   handling of each response (e.g., open a "Save as ..." dialog instead of
     390   automatic decompression and rendering of content).
     391</t>
     392<t>
     393   A representation that has a content-coding applied to it &MUST; include
     394   a Content-Encoding header field that lists the content-coding(s) applied.
     395</t>
     396<t>
     397   If multiple encodings have been applied to a representation, the content
     398   codings &MUST; be listed in the order in which they were applied.
     399   Additional information about the encoding parameters &MAY; be provided
     400   by other header fields not defined by this specification.
     401</t>
     402<t>
     403   If the content-coding of a representation in a request message is not
     404   acceptable to the origin server, the server &SHOULD; respond with a
     405   status code of 415 (Unsupported Media Type).
     406</t>
     407</section>
     408
     409<section title="Content-Language" anchor="header.content-language">
     410  <iref primary="true" item="Content-Language header field" x:for-anchor=""/>
     411  <x:anchor-alias value="Content-Language"/>
     412<t>
     413   The "Content-Language" header field describes the natural
     414   language(s) of the intended audience for the representation. Note that this might
     415   not be equivalent to all the languages used within the representation.
     416</t>
     417<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Language"/>
     418  <x:ref>Content-Language</x:ref> = 1#<x:ref>language-tag</x:ref>
     419</artwork></figure>
     420<t>
     421   Language tags are defined in <xref target="language.tags"/>. The primary purpose of
     422   Content-Language is to allow a user to identify and differentiate
     423   representations according to the user's own preferred language. Thus, if the
     424   body content is intended only for a Danish-literate audience, the
     425   appropriate field is
     426</t>
     427<figure><artwork type="example">
     428  Content-Language: da
     429</artwork></figure>
     430<t>
     431   If no Content-Language is specified, the default is that the content
     432   is intended for all language audiences. This might mean that the
     433   sender does not consider it to be specific to any natural language,
     434   or that the sender does not know for which language it is intended.
     435</t>
     436<t>
     437   Multiple languages &MAY; be listed for content that is intended for
     438   multiple audiences. For example, a rendition of the "Treaty of
     439   Waitangi", presented simultaneously in the original Maori and English
     440   versions, would call for
     441</t>
     442<figure><artwork type="example">
     443  Content-Language: mi, en
     444</artwork></figure>
     445<t>
     446   However, just because multiple languages are present within a representation
     447   does not mean that it is intended for multiple linguistic audiences.
     448   An example would be a beginner's language primer, such as "A First
     449   Lesson in Latin", which is clearly intended to be used by an
     450   English-literate audience. In this case, the Content-Language would
     451   properly only include "en".
     452</t>
     453<t>
     454   Content-Language &MAY; be applied to any media type &mdash; it is not
     455   limited to textual documents.
     456</t>
     457</section>
     458
     459<section title="Content-Location" anchor="header.content-location">
     460  <iref primary="true" item="Content-Location header field" x:for-anchor=""/>
     461  <x:anchor-alias value="Content-Location"/>
     462<t>
     463   The "Content-Location" header field supplies a URI that can be used
     464   as a specific identifier for the representation in this message.
     465   In other words, if one were to perform a GET on this URI at the time
     466   of this message's generation, then a <x:ref>200 (OK)</x:ref> response would
     467   contain the same representation that is enclosed as payload in this message.
     468</t>
     469<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Location"/>
     470  <x:ref>Content-Location</x:ref> = <x:ref>absolute-URI</x:ref> / <x:ref>partial-URI</x:ref>
     471</artwork></figure>
     472<t>
     473   The Content-Location value is not a replacement for the effective
     474   Request URI (&effective-request-uri;).  It is representation metadata.
     475   It has the same syntax and semantics as the header field of the same name
     476   defined for MIME body parts in <xref target="RFC2557" x:fmt="of" x:sec="4"/>.
     477   However, its appearance in an HTTP message has some special implications
     478   for HTTP recipients.
     479</t>
     480<t>
     481   If Content-Location is included in a response message and its value
     482   is the same as the effective request URI, then the response payload
     483   &SHOULD; be considered a current representation of that resource.
     484   For a GET or HEAD request, this is the same as the default semantics
     485   when no Content-Location is provided by the server.  For a state-changing
     486   request like PUT or POST, it implies that the server's response contains
     487   the new representation of that resource, thereby distinguishing it from
     488   representations that might only report about the action (e.g., "It worked!").
     489   This allows authoring applications to update their local copies without
     490   the need for a subsequent GET request.
     491</t>
     492<t>
     493   If Content-Location is included in a response message and its value
     494   differs from the effective request URI, then the origin server is
     495   informing recipients that this representation has its own, presumably
     496   more specific, identifier.  For a GET or HEAD request, this is an
     497   indication that the effective request URI identifies a resource that
     498   is subject to content negotiation and the selected representation for
     499   this response can also be found at the identified URI.  For other
     500   methods, such a Content-Location indicates that this representation
     501   contains a report on the action's status and the same report is
     502   available (for future access with GET) at the given URI.  For
     503   example, a purchase transaction made via a POST request might
     504   include a receipt document as the payload of the <x:ref>200 (OK)</x:ref>
     505   response; the Content-Location value provides an identifier for retrieving
     506   a copy of that same receipt in the future.
     507</t>
     508<t>
     509   If Content-Location is included in a request message, then it &MAY;
     510   be interpreted by the origin server as an indication of where the
     511   user agent originally obtained the content of the enclosed
     512   representation (prior to any subsequent modification of the content
     513   by that user agent).  In other words, the user agent is providing
     514   the same representation metadata that it received with the original
     515   representation.  However, such interpretation &MUST-NOT; be used to
     516   alter the semantics of the method requested by the client.  For
     517   example, if a client makes a PUT request on a negotiated resource
     518   and the origin server accepts that PUT (without redirection), then the
     519   new set of values for that resource is expected to be consistent with
     520   the one representation supplied in that PUT; the Content-Location
     521   cannot be used as a form of reverse content selection that
     522   identifies only one of the negotiated representations to be updated.
     523   If the user agent had wanted the latter semantics, it would have applied
     524   the PUT directly to the Content-Location URI.
     525</t>
     526<t>
     527   A Content-Location field received in a request message is transitory
     528   information that &SHOULD-NOT; be saved with other representation
     529   metadata for use in later responses.  The Content-Location's value
     530   might be saved for use in other contexts, such as within source links
     531   or other metadata.
     532</t>
     533<t>
     534   A cache cannot assume that a representation with a Content-Location
     535   different from the URI used to retrieve it can be used to respond to
     536   later requests on that Content-Location URI.
     537</t>
     538<t>
     539   If the Content-Location value is a partial URI, the partial URI is
     540   interpreted relative to the effective request URI.
     541</t>
     542</section>
     543</section>
     544
     545<section title="Selected Representation Header Fields" anchor="selected.representation">
     546<t><iref primary="true" item="selected representation"/>
     547   We use the term "<x:dfn>selected representation</x:dfn>" to refer to the
     548   the current representation of a target resource that would have been
     549   selected in a successful response if the same request had used the
     550   method GET and excluded any conditional request header fields.
     551</t>
     552<t>
     553   Additional header fields define metadata about the selected
     554   representation, which might differ from the representation included
     555   in the message for responses to some state-changing methods.
     556   The following header fields are defined as selected representation
     557   metadata:
     558</t>
     559<texttable align="left">
     560  <ttcol>Header Field Name</ttcol>
     561  <ttcol>Defined in...</ttcol>
     562
     563  <c>ETag</c> <c>&header-etag;</c>
     564  <c>Last-Modified</c> <c>&header-last-modified;</c>
     565</texttable>
     566</section>
     567
     568<section title="Representation Data" anchor="representation.data">
     569  <x:anchor-alias value="representation-data"/>
     570<t>
     571   The representation body associated with an HTTP message is
     572   either provided as the payload body of the message or
     573   referred to by the message semantics and the effective request
     574   URI.  The representation data is in a format and encoding defined by
     575   the representation metadata header fields.
     576</t>
     577<t>
     578   The data type of the representation data is determined via the header fields
     579   <x:ref>Content-Type</x:ref> and <x:ref>Content-Encoding</x:ref>.
     580   These define a two-layer, ordered encoding model:
     581</t>
     582<figure><artwork type="example">
     583  representation-data := Content-Encoding( Content-Type( bits ) )
     584</artwork></figure>
     585<t>
     586   <x:ref>Content-Type</x:ref> specifies the media type of the underlying data,
     587   which defines both the data format and how that data &SHOULD; be processed
     588   by the recipient (within the scope of the request method semantics).
     589   Any HTTP/1.1 message containing a payload body &SHOULD; include a
     590   Content-Type header field defining the media type of the associated
     591   representation unless that metadata is unknown to the sender.
     592   If the Content-Type header field is not present, it indicates that
     593   the sender does not know the media type of the representation;
     594   recipients &MAY; either assume that the media type is
     595   "application/octet-stream" (<xref target="RFC2046" x:fmt="," x:sec="4.5.1"/>)
     596   or examine the content to determine its type.
     597</t>
     598<t>
     599   In practice, resource owners do not always properly configure their origin
     600   server to provide the correct Content-Type for a given representation,
     601   with the result that some clients will examine a response body's content
     602   and override the specified type.
     603   Clients that do so risk drawing incorrect conclusions, which might expose
     604   additional security risks (e.g., "privilege escalation").  Furthermore,
     605   it is impossible to determine the sender's intent by examining the data
     606   format: many data formats match multiple media types that differ only in
     607   processing semantics.  Implementers are encouraged to provide a means of
     608   disabling such "content sniffing" when it is used.
     609</t>
     610<t>
     611   <x:ref>Content-Encoding</x:ref> is used to indicate any additional content
     612   codings applied to the data, usually for the purpose of data
     613   compression, that are a property of the representation.  If
     614   Content-Encoding is not present, then there is no additional
     615   encoding beyond that defined by the <x:ref>Content-Type</x:ref> header field.
     616</t>
     617</section>
     618
    307619<section title="Message Payload" anchor="payload">
    308620<iref item="payload"/>
    … …  
    407719</t>
    408720</section>
    409 </section>
    410 
    411 <section title="Representation Header Fields" anchor="representation.header.fields">
    412   <x:anchor-alias value="representation-header"/>
    413 <t>
    414    Representation header fields define metadata about the representation data
    415    enclosed in the message body or, if no message body is present, about
    416    the representation that would have been transferred in a <x:ref>200 (OK)</x:ref>
    417    response to a simultaneous GET request with the same effective request URI.
    418 </t>
    419 <t>
    420    The following header fields are defined as representation metadata:
    421 </t>
    422 <texttable align="left">
    423   <ttcol>Header Field Name</ttcol>
    424   <ttcol>Defined in...</ttcol>
    425 
    426   <c>Content-Type</c> <c><xref target="header.content-type"/></c>
    427   <c>Content-Encoding</c> <c><xref target="header.content-encoding"/></c>
    428   <c>Content-Language</c> <c><xref target="header.content-language"/></c>
    429   <c>Content-Location</c> <c><xref target="header.content-location"/></c>
    430   <c>Expires</c> <c>&header-expires;</c>
    431 </texttable>
    432 
    433 <section title="Content-Type" anchor="header.content-type">
    434   <iref primary="true" item="Content-Type header field" x:for-anchor=""/>
    435   <x:anchor-alias value="Content-Type"/>
    436 <t>
    437    The "Content-Type" header field indicates the media type of the
    438    representation. In the case of responses to the HEAD method, the media type is
    439    that which would have been sent had the request been a GET.
    440 </t>
    441 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Type"/>
    442   <x:ref>Content-Type</x:ref> = <x:ref>media-type</x:ref>
    443 </artwork></figure>
    444 <t>
    445    Media types are defined in <xref target="media.types"/>. An example of the field is
    446 </t>
    447 <figure><artwork type="example">
    448   Content-Type: text/html; charset=ISO-8859-4
    449 </artwork></figure>
    450 <t>
    451    Further discussion of Content-Type is provided in <xref target="representation.data"/>.
    452 </t>
    453 </section>
    454 
    455 <section title="Content-Encoding" anchor="header.content-encoding">
    456   <iref primary="true" item="Content-Encoding header field" x:for-anchor=""/>
    457   <x:anchor-alias value="Content-Encoding"/>
    458 <t>
    459    The "Content-Encoding" header field indicates what content-codings
    460    have been applied to the representation beyond those inherent in the media
    461    type, and thus what decoding mechanisms have to be applied in order to obtain
    462    the media-type referenced by the <x:ref>Content-Type</x:ref> header field.
    463    Content-Encoding is primarily used to allow a representation to be
    464    compressed without losing the identity of its underlying media type.
    465 </t>
    466 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Encoding"/>
    467   <x:ref>Content-Encoding</x:ref> = 1#<x:ref>content-coding</x:ref>
    468 </artwork></figure>
    469 <t>
    470    Content codings are defined in <xref target="content.codings"/>. An example of its use is
    471 </t>
    472 <figure><artwork type="example">
    473   Content-Encoding: gzip
    474 </artwork></figure>
    475 <t>
    476    The content-coding is a characteristic of the representation.
    477    Typically, the representation body is stored with this
    478    encoding and is only decoded before rendering or analogous usage.
    479    However, a transforming proxy &MAY; modify the content-coding if the
    480    new coding is known to be acceptable to the recipient, unless the
    481    "no-transform" cache-control directive is present in the message.
    482 </t>
    483 <t>
    484    If the media type includes an inherent encoding, such as a data format
    485    that is always compressed, then that encoding would not be restated as
    486    a Content-Encoding even if it happens to be the same algorithm as one
    487    of the content-codings.  Such a content-coding would only be listed if,
    488    for some bizarre reason, it is applied a second time to form the
    489    representation.  Likewise, an origin server might choose to publish the
    490    same payload data as multiple representations that differ only in whether
    491    the coding is defined as part of <x:ref>Content-Type</x:ref> or
    492    Content-Encoding, since some user agents will behave differently in their
    493    handling of each response (e.g., open a "Save as ..." dialog instead of
    494    automatic decompression and rendering of content).
    495 </t>
    496 <t>
    497    A representation that has a content-coding applied to it &MUST; include
    498    a Content-Encoding header field that lists the content-coding(s) applied.
    499 </t>
    500 <t>
    501    If multiple encodings have been applied to a representation, the content
    502    codings &MUST; be listed in the order in which they were applied.
    503    Additional information about the encoding parameters &MAY; be provided
    504    by other header fields not defined by this specification.
    505 </t>
    506 <t>
    507    If the content-coding of a representation in a request message is not
    508    acceptable to the origin server, the server &SHOULD; respond with a
    509    status code of 415 (Unsupported Media Type).
    510 </t>
    511 </section>
    512 
    513 <section title="Content-Language" anchor="header.content-language">
    514   <iref primary="true" item="Content-Language header field" x:for-anchor=""/>
    515   <x:anchor-alias value="Content-Language"/>
    516 <t>
    517    The "Content-Language" header field describes the natural
    518    language(s) of the intended audience for the representation. Note that this might
    519    not be equivalent to all the languages used within the representation.
    520 </t>
    521 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Language"/>
    522   <x:ref>Content-Language</x:ref> = 1#<x:ref>language-tag</x:ref>
    523 </artwork></figure>
    524 <t>
    525    Language tags are defined in <xref target="language.tags"/>. The primary purpose of
    526    Content-Language is to allow a user to identify and differentiate
    527    representations according to the user's own preferred language. Thus, if the
    528    body content is intended only for a Danish-literate audience, the
    529    appropriate field is
    530 </t>
    531 <figure><artwork type="example">
    532   Content-Language: da
    533 </artwork></figure>
    534 <t>
    535    If no Content-Language is specified, the default is that the content
    536    is intended for all language audiences. This might mean that the
    537    sender does not consider it to be specific to any natural language,
    538    or that the sender does not know for which language it is intended.
    539 </t>
    540 <t>
    541    Multiple languages &MAY; be listed for content that is intended for
    542    multiple audiences. For example, a rendition of the "Treaty of
    543    Waitangi", presented simultaneously in the original Maori and English
    544    versions, would call for
    545 </t>
    546 <figure><artwork type="example">
    547   Content-Language: mi, en
    548 </artwork></figure>
    549 <t>
    550    However, just because multiple languages are present within a representation
    551    does not mean that it is intended for multiple linguistic audiences.
    552    An example would be a beginner's language primer, such as "A First
    553    Lesson in Latin", which is clearly intended to be used by an
    554    English-literate audience. In this case, the Content-Language would
    555    properly only include "en".
    556 </t>
    557 <t>
    558    Content-Language &MAY; be applied to any media type &mdash; it is not
    559    limited to textual documents.
    560 </t>
    561 </section>
    562 
    563 <section title="Content-Location" anchor="header.content-location">
    564   <iref primary="true" item="Content-Location header field" x:for-anchor=""/>
    565   <x:anchor-alias value="Content-Location"/>
    566 <t>
    567    The "Content-Location" header field supplies a URI that can be used
    568    as a specific identifier for the representation in this message.
    569    In other words, if one were to perform a GET on this URI at the time
    570    of this message's generation, then a <x:ref>200 (OK)</x:ref> response would
    571    contain the same representation that is enclosed as payload in this message.
    572 </t>
    573 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Location"/>
    574   <x:ref>Content-Location</x:ref> = <x:ref>absolute-URI</x:ref> / <x:ref>partial-URI</x:ref>
    575 </artwork></figure>
    576 <t>
    577    The Content-Location value is not a replacement for the effective
    578    Request URI (&effective-request-uri;).  It is representation metadata.
    579    It has the same syntax and semantics as the header field of the same name
    580    defined for MIME body parts in <xref target="RFC2557" x:fmt="of" x:sec="4"/>.
    581    However, its appearance in an HTTP message has some special implications
    582    for HTTP recipients.
    583 </t>
    584 <t>
    585    If Content-Location is included in a response message and its value
    586    is the same as the effective request URI, then the response payload
    587    &SHOULD; be considered a current representation of that resource.
    588    For a GET or HEAD request, this is the same as the default semantics
    589    when no Content-Location is provided by the server.  For a state-changing
    590    request like PUT or POST, it implies that the server's response contains
    591    the new representation of that resource, thereby distinguishing it from
    592    representations that might only report about the action (e.g., "It worked!").
    593    This allows authoring applications to update their local copies without
    594    the need for a subsequent GET request.
    595 </t>
    596 <t>
    597    If Content-Location is included in a response message and its value
    598    differs from the effective request URI, then the origin server is
    599    informing recipients that this representation has its own, presumably
    600    more specific, identifier.  For a GET or HEAD request, this is an
    601    indication that the effective request URI identifies a resource that
    602    is subject to content negotiation and the selected representation for
    603    this response can also be found at the identified URI.  For other
    604    methods, such a Content-Location indicates that this representation
    605    contains a report on the action's status and the same report is
    606    available (for future access with GET) at the given URI.  For
    607    example, a purchase transaction made via a POST request might
    608    include a receipt document as the payload of the <x:ref>200 (OK)</x:ref>
    609    response; the Content-Location value provides an identifier for retrieving
    610    a copy of that same receipt in the future.
    611 </t>
    612 <t>
    613    If Content-Location is included in a request message, then it &MAY;
    614    be interpreted by the origin server as an indication of where the
    615    user agent originally obtained the content of the enclosed
    616    representation (prior to any subsequent modification of the content
    617    by that user agent).  In other words, the user agent is providing
    618    the same representation metadata that it received with the original
    619    representation.  However, such interpretation &MUST-NOT; be used to
    620    alter the semantics of the method requested by the client.  For
    621    example, if a client makes a PUT request on a negotiated resource
    622    and the origin server accepts that PUT (without redirection), then the
    623    new set of values for that resource is expected to be consistent with
    624    the one representation supplied in that PUT; the Content-Location
    625    cannot be used as a form of reverse content selection that
    626    identifies only one of the negotiated representations to be updated.
    627    If the user agent had wanted the latter semantics, it would have applied
    628    the PUT directly to the Content-Location URI.
    629 </t>
    630 <t>
    631    A Content-Location field received in a request message is transitory
    632    information that &SHOULD-NOT; be saved with other representation
    633    metadata for use in later responses.  The Content-Location's value
    634    might be saved for use in other contexts, such as within source links
    635    or other metadata.
    636 </t>
    637 <t>
    638    A cache cannot assume that a representation with a Content-Location
    639    different from the URI used to retrieve it can be used to respond to
    640    later requests on that Content-Location URI.
    641 </t>
    642 <t>
    643    If the Content-Location value is a partial URI, the partial URI is
    644    interpreted relative to the effective request URI.
    645 </t>
    646 </section>
    647 </section>
    648 
    649 <section title="Selected Representation Header Fields" anchor="selected.representation">
    650 <t><iref primary="true" item="selected representation"/>
    651    We use the term "<x:dfn>selected representation</x:dfn>" to refer to the
    652    the current representation of a target resource that would have been
    653    selected in a successful response if the same request had used the
    654    method GET and excluded any conditional request header fields.
    655 </t>
    656 <t>
    657    Additional header fields define metadata about the selected
    658    representation, which might differ from the representation included
    659    in the message for responses to some state-changing methods.
    660    The following header fields are defined as selected representation
    661    metadata:
    662 </t>
    663 <texttable align="left">
    664   <ttcol>Header Field Name</ttcol>
    665   <ttcol>Defined in...</ttcol>
    666 
    667   <c>ETag</c> <c>&header-etag;</c>
    668   <c>Last-Modified</c> <c>&header-last-modified;</c>
    669 </texttable>
    670 </section>
    671 
    672 <section title="Representation Data" anchor="representation.data">
    673   <x:anchor-alias value="representation-data"/>
    674 <t>
    675    The representation body associated with an HTTP message is
    676    either provided as the payload body of the message or
    677    referred to by the message semantics and the effective request
    678    URI.  The representation data is in a format and encoding defined by
    679    the representation metadata header fields.
    680 </t>
    681 <t>
    682    The data type of the representation data is determined via the header fields
    683    <x:ref>Content-Type</x:ref> and <x:ref>Content-Encoding</x:ref>.
    684    These define a two-layer, ordered encoding model:
    685 </t>
    686 <figure><artwork type="example">
    687   representation-data := Content-Encoding( Content-Type( bits ) )
    688 </artwork></figure>
    689 <t>
    690    <x:ref>Content-Type</x:ref> specifies the media type of the underlying data,
    691    which defines both the data format and how that data &SHOULD; be processed
    692    by the recipient (within the scope of the request method semantics).
    693    Any HTTP/1.1 message containing a payload body &SHOULD; include a
    694    Content-Type header field defining the media type of the associated
    695    representation unless that metadata is unknown to the sender.
    696    If the Content-Type header field is not present, it indicates that
    697    the sender does not know the media type of the representation;
    698    recipients &MAY; either assume that the media type is
    699    "application/octet-stream" (<xref target="RFC2046" x:fmt="," x:sec="4.5.1"/>)
    700    or examine the content to determine its type.
    701 </t>
    702 <t>
    703    In practice, resource owners do not always properly configure their origin
    704    server to provide the correct Content-Type for a given representation,
    705    with the result that some clients will examine a response body's content
    706    and override the specified type.
    707    Clients that do so risk drawing incorrect conclusions, which might expose
    708    additional security risks (e.g., "privilege escalation").  Furthermore,
    709    it is impossible to determine the sender's intent by examining the data
    710    format: many data formats match multiple media types that differ only in
    711    processing semantics.  Implementers are encouraged to provide a means of
    712    disabling such "content sniffing" when it is used.
    713 </t>
    714 <t>
    715    <x:ref>Content-Encoding</x:ref> is used to indicate any additional content
    716    codings applied to the data, usually for the purpose of data
    717    compression, that are a property of the representation.  If
    718    Content-Encoding is not present, then there is no additional
    719    encoding beyond that defined by the <x:ref>Content-Type</x:ref> header field.
    720 </t>
    721721</section>
    722722
Note: See TracChangeset for help on using the changeset viewer.