Ignore:
Timestamp:
Mar 30, 2012, 8:39:09 AM (8 years ago)
Author:
julian.reschke@…
Message:

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

File:
1 edited

Legend:

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

    r1644 r1645  
    26052605<t>
    26062606   This section defines the syntax and semantics of HTTP/1.1 header fields
    2607    related to request and response semantics.
    2608 </t>
     2607   related to request and response semantics and to the payload of messages.
     2608</t>
     2609
     2610
     2611<section title="Accept" anchor="header.accept">
     2612  <iref primary="true" item="Accept header field" x:for-anchor=""/>
     2613  <iref primary="true" item="Header Fields" subitem="Accept" x:for-anchor=""/>
     2614  <x:anchor-alias value="Accept"/>
     2615  <x:anchor-alias value="accept-ext"/>
     2616  <x:anchor-alias value="accept-params"/>
     2617  <x:anchor-alias value="media-range"/>
     2618<t>
     2619   The "Accept" header field can be used by user agents to specify
     2620   response media types that are acceptable. Accept header fields can be used to
     2621   indicate that the request is specifically limited to a small set of desired
     2622   types, as in the case of a request for an in-line image.
     2623</t>
     2624<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Accept"/><iref primary="true" item="Grammar" subitem="media-range"/><iref primary="true" item="Grammar" subitem="accept-params"/><iref primary="true" item="Grammar" subitem="accept-ext"/>
     2625  <x:ref>Accept</x:ref> = #( <x:ref>media-range</x:ref> [ <x:ref>accept-params</x:ref> ] )
     2626 
     2627  <x:ref>media-range</x:ref>    = ( "*/*"
     2628                   / ( <x:ref>type</x:ref> "/" "*" )
     2629                   / ( <x:ref>type</x:ref> "/" <x:ref>subtype</x:ref> )
     2630                   ) *( <x:ref>OWS</x:ref> ";" <x:ref>OWS</x:ref> <x:ref>parameter</x:ref> )
     2631  <x:ref>accept-params</x:ref>  = <x:ref>OWS</x:ref> ";" <x:ref>OWS</x:ref> "q=" <x:ref>qvalue</x:ref> *( <x:ref>accept-ext</x:ref> )
     2632  <x:ref>accept-ext</x:ref>     = <x:ref>OWS</x:ref> ";" <x:ref>OWS</x:ref> <x:ref>token</x:ref> [ "=" <x:ref>word</x:ref> ]
     2633</artwork></figure>
     2634<t>
     2635   The asterisk "*" character is used to group media types into ranges,
     2636   with "*/*" indicating all media types and "type/*" indicating all
     2637   subtypes of that type. The media-range &MAY; include media type
     2638   parameters that are applicable to that range.
     2639</t>
     2640<t>
     2641   Each media-range &MAY; be followed by one or more accept-params,
     2642   beginning with the "q" parameter for indicating a relative quality
     2643   factor. The first "q" parameter (if any) separates the media-range
     2644   parameter(s) from the accept-params. Quality factors allow the user
     2645   or user agent to indicate the relative degree of preference for that
     2646   media-range, using the qvalue scale from 0 to 1 (&qvalue;). The
     2647   default value is q=1.
     2648</t>
     2649<x:note>
     2650  <t>
     2651    <x:h>Note:</x:h> Use of the "q" parameter name to separate media type
     2652    parameters from Accept extension parameters is due to historical
     2653    practice. Although this prevents any media type parameter named
     2654    "q" from being used with a media range, such an event is believed
     2655    to be unlikely given the lack of any "q" parameters in the IANA
     2656    media type registry and the rare usage of any media type
     2657    parameters in Accept. Future media types are discouraged from
     2658    registering any parameter named "q".
     2659  </t>
     2660</x:note>
     2661<t>
     2662   The example
     2663</t>
     2664<figure><artwork type="example">
     2665  Accept: audio/*; q=0.2, audio/basic
     2666</artwork></figure>
     2667<t>
     2668   &SHOULD; be interpreted as "I prefer audio/basic, but send me any audio
     2669   type if it is the best available after an 80% mark-down in quality".
     2670</t>
     2671<t>
     2672   A request without any Accept header field implies that the user agent
     2673   will accept any media type in response.
     2674   If an Accept header field is present in a request and none of the
     2675   available representations for the response have a media type that is
     2676   listed as acceptable, the origin server &MAY; either
     2677   honor the Accept header field by sending a 406 (Not Acceptable) response
     2678   or disregard the Accept header field by treating the response as if
     2679   it is not subject to content negotiation.
     2680</t>
     2681<t>
     2682   A more elaborate example is
     2683</t>
     2684<figure><artwork type="example">
     2685  Accept: text/plain; q=0.5, text/html,
     2686          text/x-dvi; q=0.8, text/x-c
     2687</artwork></figure>
     2688<t>
     2689   Verbally, this would be interpreted as "text/html and text/x-c are
     2690   the preferred media types, but if they do not exist, then send the
     2691   text/x-dvi representation, and if that does not exist, send the text/plain
     2692   representation".
     2693</t>
     2694<t>
     2695   Media ranges can be overridden by more specific media ranges or
     2696   specific media types. If more than one media range applies to a given
     2697   type, the most specific reference has precedence. For example,
     2698</t>
     2699<figure><artwork type="example">
     2700  Accept: text/*, text/plain, text/plain;format=flowed, */*
     2701</artwork></figure>
     2702<t>
     2703   have the following precedence:
     2704   <list style="numbers">
     2705    <t>text/plain;format=flowed</t>
     2706    <t>text/plain</t>
     2707    <t>text/*</t>
     2708    <t>*/*</t>
     2709   </list>
     2710</t>
     2711<t>
     2712   The media type quality factor associated with a given type is
     2713   determined by finding the media range with the highest precedence
     2714   which matches that type. For example,
     2715</t>
     2716<figure><artwork type="example">
     2717  Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,
     2718          text/html;level=2;q=0.4, */*;q=0.5
     2719</artwork></figure>
     2720<t>
     2721   would cause the following values to be associated:
     2722</t>
     2723<texttable align="left">
     2724  <ttcol>Media Type</ttcol><ttcol>Quality Value</ttcol>
     2725  <c>text/html;level=1</c>    <c>1</c>
     2726  <c>text/html</c>            <c>0.7</c>
     2727  <c>text/plain</c>           <c>0.3</c>
     2728  <c>image/jpeg</c>           <c>0.5</c>
     2729  <c>text/html;level=2</c>    <c>0.4</c>
     2730  <c>text/html;level=3</c>    <c>0.7</c>
     2731</texttable>
     2732<t>
     2733      <x:h>Note:</x:h> A user agent might be provided with a default set of quality
     2734      values for certain media ranges. However, unless the user agent is
     2735      a closed system which cannot interact with other rendering agents,
     2736      this default set ought to be configurable by the user.
     2737</t>
     2738</section>
     2739
     2740<section title="Accept-Charset" anchor="header.accept-charset">
     2741  <iref primary="true" item="Accept-Charset header field" x:for-anchor=""/>
     2742  <iref primary="true" item="Header Fields" subitem="Accept-Charset" x:for-anchor=""/>
     2743  <x:anchor-alias value="Accept-Charset"/>
     2744<t>
     2745   The "Accept-Charset" header field can be used by user agents to
     2746   indicate what character encodings are acceptable in a response
     2747   payload. This field allows
     2748   clients capable of understanding more comprehensive or special-purpose
     2749   character encodings to signal that capability to a server which is capable of
     2750   representing documents in those character encodings.
     2751</t>
     2752<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Accept-Charset"/>
     2753  <x:ref>Accept-Charset</x:ref> = 1#( ( <x:ref>charset</x:ref> / "*" )
     2754                         [ <x:ref>OWS</x:ref> ";" <x:ref>OWS</x:ref> "q=" <x:ref>qvalue</x:ref> ] )
     2755</artwork></figure>
     2756<t>
     2757   Character encoding values (a.k.a., charsets) are described in
     2758   <xref target="character.sets"/>. Each charset &MAY; be given an
     2759   associated quality value which represents the user's preference
     2760   for that charset. The default value is q=1. An example is
     2761</t>
     2762<figure><artwork type="example">
     2763  Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
     2764</artwork></figure>
     2765<t>
     2766   The special value "*", if present in the Accept-Charset field,
     2767   matches every character encoding which is not mentioned elsewhere in the
     2768   Accept-Charset field. If no "*" is present in an Accept-Charset field, then
     2769   all character encodings not explicitly mentioned get a quality value of 0.
     2770</t>
     2771<t>
     2772   A request without any Accept-Charset header field implies that the user
     2773   agent will accept any character encoding in response.
     2774   If an Accept-Charset header field is present in a request and none of the
     2775   available representations for the response have a character encoding that
     2776   is listed as acceptable, the origin server &MAY; either honor the
     2777   Accept-Charset header field by sending a 406 (Not Acceptable) response or
     2778   disregard the Accept-Charset header field by treating the response as if
     2779   it is not subject to content negotiation.
     2780</t>
     2781</section>
     2782
     2783<section title="Accept-Encoding" anchor="header.accept-encoding">
     2784  <iref primary="true" item="Accept-Encoding header field" x:for-anchor=""/>
     2785  <iref primary="true" item="Header Fields" subitem="Accept-Encoding" x:for-anchor=""/>
     2786  <x:anchor-alias value="Accept-Encoding"/>
     2787  <x:anchor-alias value="codings"/>
     2788<t>
     2789   The "Accept-Encoding" header field can be used by user agents to
     2790   indicate what response content-codings (<xref target="content.codings"/>)
     2791   are acceptable in the response.  An "identity" token is used as a synonym
     2792   for "no encoding" in order to communicate when no encoding is preferred.
     2793</t>
     2794<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Accept-Encoding"/><iref primary="true" item="Grammar" subitem="codings"/>
     2795  <x:ref>Accept-Encoding</x:ref>  = #( <x:ref>codings</x:ref> [ <x:ref>OWS</x:ref> ";" <x:ref>OWS</x:ref> "q=" <x:ref>qvalue</x:ref> ] )
     2796  <x:ref>codings</x:ref>          = <x:ref>content-coding</x:ref> / "identity" / "*"
     2797</artwork></figure>
     2798<t>
     2799   Each codings value &MAY; be given an associated quality value which
     2800   represents the preference for that encoding. The default value is q=1.
     2801</t>
     2802<t>
     2803   For example,
     2804</t>
     2805<figure><artwork type="example">
     2806  Accept-Encoding: compress, gzip
     2807  Accept-Encoding:
     2808  Accept-Encoding: *
     2809  Accept-Encoding: compress;q=0.5, gzip;q=1.0
     2810  Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0
     2811</artwork></figure>
     2812<t>
     2813   A server tests whether a content-coding for a given representation is
     2814   acceptable, according to an Accept-Encoding field, using these rules:
     2815  <list style="numbers">
     2816      <t>The special "*" symbol in an Accept-Encoding field matches any
     2817         available content-coding not explicitly listed in the header
     2818         field.</t>
     2819
     2820      <t>If the representation has no content-coding, then it is acceptable
     2821         by default unless specifically excluded by the Accept-Encoding field
     2822         stating either "identity;q=0" or "*;q=0" without a more specific
     2823         entry for "identity".</t>
     2824
     2825      <t>If the representation's content-coding is one of the content-codings
     2826         listed in the Accept-Encoding field, then it is acceptable unless
     2827         it is accompanied by a qvalue of 0. (As defined in &qvalue;, a
     2828         qvalue of 0 means "not acceptable".)</t>
     2829
     2830      <t>If multiple content-codings are acceptable, then the acceptable
     2831         content-coding with the highest non-zero qvalue is preferred.</t>
     2832  </list>
     2833</t>
     2834<t>
     2835   An Accept-Encoding header field with a combined field-value that is empty
     2836   implies that the user agent does not want any content-coding in response.
     2837   If an Accept-Encoding header field is present in a request and none of the
     2838   available representations for the response have a content-coding that
     2839   is listed as acceptable, the origin server &SHOULD; send a response
     2840   without any content-coding.
     2841</t>
     2842<t>
     2843   A request without an Accept-Encoding header field implies that the user
     2844   agent will accept any content-coding in response, but a representation
     2845   without content-coding is preferred for compatibility with the widest
     2846   variety of user agents.
     2847</t>
     2848<x:note>
     2849  <t>
     2850    <x:h>Note:</x:h> Most HTTP/1.0 applications do not recognize or obey qvalues
     2851    associated with content-codings. This means that qvalues will not
     2852    work and are not permitted with x-gzip or x-compress.
     2853  </t>
     2854</x:note>
     2855</section>
     2856
     2857<section title="Accept-Language" anchor="header.accept-language">
     2858  <iref primary="true" item="Accept-Language header field" x:for-anchor=""/>
     2859  <iref primary="true" item="Header Fields" subitem="Accept-Language" x:for-anchor=""/>
     2860  <x:anchor-alias value="Accept-Language"/>
     2861  <x:anchor-alias value="language-range"/>
     2862<t>
     2863   The "Accept-Language" header field can be used by user agents to
     2864   indicate the set of natural languages that are preferred in the response.
     2865   Language tags are defined in <xref target="language.tags"/>.
     2866</t>
     2867<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Accept-Language"/><iref primary="true" item="Grammar" subitem="language-range"/>
     2868  <x:ref>Accept-Language</x:ref> =
     2869                    1#( <x:ref>language-range</x:ref> [ <x:ref>OWS</x:ref> ";" <x:ref>OWS</x:ref> "q=" <x:ref>qvalue</x:ref> ] )
     2870  <x:ref>language-range</x:ref>  =
     2871            &lt;language-range, defined in <xref target="RFC4647" x:fmt="," x:sec="2.1"/>&gt;
     2872</artwork></figure>
     2873<t>
     2874   Each language-range can be given an associated quality value which
     2875   represents an estimate of the user's preference for the languages
     2876   specified by that range. The quality value defaults to "q=1". For
     2877   example,
     2878</t>
     2879<figure><artwork type="example">
     2880  Accept-Language: da, en-gb;q=0.8, en;q=0.7
     2881</artwork></figure>
     2882<t>
     2883   would mean: "I prefer Danish, but will accept British English and
     2884   other types of English".
     2885   (see also <xref target="RFC4647" x:sec="2.3" x:fmt="of"/>)
     2886</t>
     2887<t>
     2888   For matching, <xref target="RFC4647" x:sec="3" x:fmt="of"/> defines
     2889   several matching schemes. Implementations can offer the most appropriate
     2890   matching scheme for their requirements.
     2891</t>
     2892<x:note>
     2893  <t>
     2894    <x:h>Note:</x:h> The "Basic Filtering" scheme (<xref target="RFC4647"
     2895    x:fmt="," x:sec="3.3.1"/>) is identical to the matching scheme that was
     2896    previously defined in <xref target="RFC2616" x:fmt="of" x:sec="14.4"/>.
     2897  </t>
     2898</x:note>
     2899<t>
     2900   It might be contrary to the privacy expectations of the user to send
     2901   an Accept-Language header field with the complete linguistic preferences of
     2902   the user in every request. For a discussion of this issue, see
     2903   <xref target="privacy.issues.connected.to.accept.header.fields"/>.
     2904</t>
     2905<t>
     2906   As intelligibility is highly dependent on the individual user, it is
     2907   recommended that client applications make the choice of linguistic
     2908   preference available to the user. If the choice is not made
     2909   available, then the Accept-Language header field &MUST-NOT; be given in
     2910   the request.
     2911</t>
     2912<x:note>
     2913  <t>
     2914    <x:h>Note:</x:h> When making the choice of linguistic preference available to
     2915    the user, we remind implementors of  the fact that users are not
     2916    familiar with the details of language matching as described above,
     2917    and ought to be provided appropriate guidance. As an example, users
     2918    might assume that on selecting "en-gb", they will be served any
     2919    kind of English document if British English is not available. A
     2920    user agent might suggest in such a case to add "en" to get the
     2921    best matching behavior.
     2922  </t>
     2923</x:note>
     2924</section>
    26092925
    26102926<section title="Allow" anchor="header.allow">
     
    26342950   understand all the methods specified in order to handle them according to
    26352951   the generic message handling rules.
     2952</t>
     2953</section>
     2954
     2955
     2956<section title="Content-Encoding" anchor="header.content-encoding">
     2957  <iref primary="true" item="Content-Encoding header field" x:for-anchor=""/>
     2958  <iref primary="true" item="Header Fields" subitem="Content-Encoding" x:for-anchor=""/>
     2959  <x:anchor-alias value="Content-Encoding"/>
     2960<t>
     2961   The "Content-Encoding" header field indicates what content-codings
     2962   have been applied to the representation beyond those inherent in the media
     2963   type, and thus what decoding mechanisms have to be applied in order to obtain
     2964   the media-type referenced by the Content-Type header field.
     2965   Content-Encoding is primarily used to allow a representation to be
     2966   compressed without losing the identity of its underlying media type.
     2967</t>
     2968<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Encoding"/>
     2969  <x:ref>Content-Encoding</x:ref> = 1#<x:ref>content-coding</x:ref>
     2970</artwork></figure>
     2971<t>
     2972   Content codings are defined in <xref target="content.codings"/>. An example of its use is
     2973</t>
     2974<figure><artwork type="example">
     2975  Content-Encoding: gzip
     2976</artwork></figure>
     2977<t>
     2978   The content-coding is a characteristic of the representation.
     2979   Typically, the representation body is stored with this
     2980   encoding and is only decoded before rendering or analogous usage.
     2981   However, a transforming proxy &MAY; modify the content-coding if the
     2982   new coding is known to be acceptable to the recipient, unless the
     2983   "no-transform" cache-control directive is present in the message.
     2984</t>
     2985<t>
     2986   If the media type includes an inherent encoding, such as a data format
     2987   that is always compressed, then that encoding would not be restated as
     2988   a Content-Encoding even if it happens to be the same algorithm as one
     2989   of the content-codings.  Such a content-coding would only be listed if,
     2990   for some bizarre reason, it is applied a second time to form the
     2991   representation.  Likewise, an origin server might choose to publish the
     2992   same payload data as multiple representations that differ only in whether
     2993   the coding is defined as part of Content-Type or Content-Encoding, since
     2994   some user agents will behave differently in their handling of each
     2995   response (e.g., open a "Save as ..." dialog instead of automatic
     2996   decompression and rendering of content).
     2997</t>
     2998<t>
     2999   A representation that has a content-coding applied to it &MUST; include
     3000   a Content-Encoding header field (<xref target="header.content-encoding"/>)
     3001   that lists the content-coding(s) applied.
     3002</t>
     3003<t>
     3004   If multiple encodings have been applied to a representation, the content
     3005   codings &MUST; be listed in the order in which they were applied.
     3006   Additional information about the encoding parameters &MAY; be provided
     3007   by other header fields not defined by this specification.
     3008</t>
     3009<t>
     3010   If the content-coding of a representation in a request message is not
     3011   acceptable to the origin server, the server &SHOULD; respond with a
     3012   status code of 415 (Unsupported Media Type).
     3013</t>
     3014</section>
     3015
     3016<section title="Content-Language" anchor="header.content-language">
     3017  <iref primary="true" item="Content-Language header field" x:for-anchor=""/>
     3018  <iref primary="true" item="Header Fields" subitem="Content-Language" x:for-anchor=""/>
     3019  <x:anchor-alias value="Content-Language"/>
     3020<t>
     3021   The "Content-Language" header field describes the natural
     3022   language(s) of the intended audience for the representation. Note that this might
     3023   not be equivalent to all the languages used within the representation.
     3024</t>
     3025<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Language"/>
     3026  <x:ref>Content-Language</x:ref> = 1#<x:ref>language-tag</x:ref>
     3027</artwork></figure>
     3028<t>
     3029   Language tags are defined in <xref target="language.tags"/>. The primary purpose of
     3030   Content-Language is to allow a user to identify and differentiate
     3031   representations according to the user's own preferred language. Thus, if the
     3032   body content is intended only for a Danish-literate audience, the
     3033   appropriate field is
     3034</t>
     3035<figure><artwork type="example">
     3036  Content-Language: da
     3037</artwork></figure>
     3038<t>
     3039   If no Content-Language is specified, the default is that the content
     3040   is intended for all language audiences. This might mean that the
     3041   sender does not consider it to be specific to any natural language,
     3042   or that the sender does not know for which language it is intended.
     3043</t>
     3044<t>
     3045   Multiple languages &MAY; be listed for content that is intended for
     3046   multiple audiences. For example, a rendition of the "Treaty of
     3047   Waitangi", presented simultaneously in the original Maori and English
     3048   versions, would call for
     3049</t>
     3050<figure><artwork type="example">
     3051  Content-Language: mi, en
     3052</artwork></figure>
     3053<t>
     3054   However, just because multiple languages are present within a representation
     3055   does not mean that it is intended for multiple linguistic audiences.
     3056   An example would be a beginner's language primer, such as "A First
     3057   Lesson in Latin", which is clearly intended to be used by an
     3058   English-literate audience. In this case, the Content-Language would
     3059   properly only include "en".
     3060</t>
     3061<t>
     3062   Content-Language &MAY; be applied to any media type &mdash; it is not
     3063   limited to textual documents.
     3064</t>
     3065</section>
     3066
     3067<section title="Content-Location" anchor="header.content-location">
     3068  <iref primary="true" item="Content-Location header field" x:for-anchor=""/>
     3069  <iref primary="true" item="Header Fields" subitem="Content-Location" x:for-anchor=""/>
     3070  <x:anchor-alias value="Content-Location"/>
     3071<t>
     3072   The "Content-Location" header field supplies a URI that can be used
     3073   as a specific identifier for the representation in this message.
     3074   In other words, if one were to perform a GET on this URI at the time
     3075   of this message's generation, then a 200 response would contain the
     3076   same representation that is enclosed as payload in this message.
     3077</t>
     3078<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Location"/>
     3079  <x:ref>Content-Location</x:ref> = <x:ref>absolute-URI</x:ref> / <x:ref>partial-URI</x:ref>
     3080</artwork></figure>
     3081<t>
     3082   The Content-Location value is not a replacement for the effective
     3083   Request URI (&effective-request-uri;).  It is representation metadata.
     3084   It has the same syntax and semantics as the header field of the same name
     3085   defined for MIME body parts in <xref target="RFC2557" x:fmt="of" x:sec="4"/>.
     3086   However, its appearance in an HTTP message has some special implications
     3087   for HTTP recipients.
     3088</t>
     3089<t>
     3090   If Content-Location is included in a response message and its value
     3091   is the same as the effective request URI, then the response payload
     3092   &SHOULD; be considered a current representation of that resource.
     3093   For a GET or HEAD request, this is the same as the default semantics
     3094   when no Content-Location is provided by the server.  For a state-changing
     3095   request like PUT or POST, it implies that the server's response contains
     3096   the new representation of that resource, thereby distinguishing it from
     3097   representations that might only report about the action (e.g., "It worked!").
     3098   This allows authoring applications to update their local copies without
     3099   the need for a subsequent GET request.
     3100</t>
     3101<t>
     3102   If Content-Location is included in a response message and its value
     3103   differs from the effective request URI, then the origin server is
     3104   informing recipients that this representation has its own, presumably
     3105   more specific, identifier.  For a GET or HEAD request, this is an
     3106   indication that the effective request URI identifies a resource that
     3107   is subject to content negotiation and the selected representation for
     3108   this response can also be found at the identified URI.  For other
     3109   methods, such a Content-Location indicates that this representation
     3110   contains a report on the action's status and the same report is
     3111   available (for future access with GET) at the given URI.  For
     3112   example, a purchase transaction made via a POST request might
     3113   include a receipt document as the payload of the 200 response;
     3114   the Content-Location value provides an identifier for retrieving
     3115   a copy of that same receipt in the future.
     3116</t>
     3117<t>
     3118   If Content-Location is included in a request message, then it &MAY;
     3119   be interpreted by the origin server as an indication of where the
     3120   user agent originally obtained the content of the enclosed
     3121   representation (prior to any subsequent modification of the content
     3122   by that user agent).  In other words, the user agent is providing
     3123   the same representation metadata that it received with the original
     3124   representation.  However, such interpretation &MUST-NOT; be used to
     3125   alter the semantics of the method requested by the client.  For
     3126   example, if a client makes a PUT request on a negotiated resource
     3127   and the origin server accepts that PUT (without redirection), then the
     3128   new set of values for that resource is expected to be consistent with
     3129   the one representation supplied in that PUT; the Content-Location
     3130   cannot be used as a form of reverse content selection that
     3131   identifies only one of the negotiated representations to be updated.
     3132   If the user agent had wanted the latter semantics, it would have applied
     3133   the PUT directly to the Content-Location URI.
     3134</t>
     3135<t>
     3136   A Content-Location field received in a request message is transitory
     3137   information that &SHOULD-NOT; be saved with other representation
     3138   metadata for use in later responses.  The Content-Location's value
     3139   might be saved for use in other contexts, such as within source links
     3140   or other metadata.
     3141</t>
     3142<t>
     3143   A cache cannot assume that a representation with a Content-Location
     3144   different from the URI used to retrieve it can be used to respond to
     3145   later requests on that Content-Location URI.
     3146</t>
     3147<t>
     3148   If the Content-Location value is a partial URI, the partial URI is
     3149   interpreted relative to the effective request URI.
     3150</t>
     3151</section>
     3152
     3153<section title="Content-Type" anchor="header.content-type">
     3154  <iref primary="true" item="Content-Type header field" x:for-anchor=""/>
     3155  <iref primary="true" item="Header Fields" subitem="Content-Type" x:for-anchor=""/>
     3156  <x:anchor-alias value="Content-Type"/>
     3157<t>
     3158   The "Content-Type" header field indicates the media type of the
     3159   representation. In the case of responses to the HEAD method, the media type is
     3160   that which would have been sent had the request been a GET.
     3161</t>
     3162<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Type"/>
     3163  <x:ref>Content-Type</x:ref> = <x:ref>media-type</x:ref>
     3164</artwork></figure>
     3165<t>
     3166   Media types are defined in <xref target="media.types"/>. An example of the field is
     3167</t>
     3168<figure><artwork type="example">
     3169  Content-Type: text/html; charset=ISO-8859-4
     3170</artwork></figure>
     3171<t>
     3172   Further discussion of Content-Type is provided in <xref target="representation.data"/>.
    26363173</t>
    26373174</section>
     
    30613598</artwork></figure>
    30623599</section>
    3063 
    30643600</section>
    30653601
     
    55106046</section>
    55116047
    5512 <section title="Header Field Definitions" anchor="header.field.definitions3">
    5513 <t>
    5514    This section defines the syntax and semantics of HTTP/1.1 header fields
    5515    related to the payload of messages.
    5516 </t>
    5517 
    5518 <section title="Accept" anchor="header.accept">
    5519   <iref primary="true" item="Accept header field" x:for-anchor=""/>
    5520   <iref primary="true" item="Header Fields" subitem="Accept" x:for-anchor=""/>
    5521   <x:anchor-alias value="Accept"/>
    5522   <x:anchor-alias value="accept-ext"/>
    5523   <x:anchor-alias value="accept-params"/>
    5524   <x:anchor-alias value="media-range"/>
    5525 <t>
    5526    The "Accept" header field can be used by user agents to specify
    5527    response media types that are acceptable. Accept header fields can be used to
    5528    indicate that the request is specifically limited to a small set of desired
    5529    types, as in the case of a request for an in-line image.
    5530 </t>
    5531 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Accept"/><iref primary="true" item="Grammar" subitem="media-range"/><iref primary="true" item="Grammar" subitem="accept-params"/><iref primary="true" item="Grammar" subitem="accept-ext"/>
    5532   <x:ref>Accept</x:ref> = #( <x:ref>media-range</x:ref> [ <x:ref>accept-params</x:ref> ] )
    5533  
    5534   <x:ref>media-range</x:ref>    = ( "*/*"
    5535                    / ( <x:ref>type</x:ref> "/" "*" )
    5536                    / ( <x:ref>type</x:ref> "/" <x:ref>subtype</x:ref> )
    5537                    ) *( <x:ref>OWS</x:ref> ";" <x:ref>OWS</x:ref> <x:ref>parameter</x:ref> )
    5538   <x:ref>accept-params</x:ref>  = <x:ref>OWS</x:ref> ";" <x:ref>OWS</x:ref> "q=" <x:ref>qvalue</x:ref> *( <x:ref>accept-ext</x:ref> )
    5539   <x:ref>accept-ext</x:ref>     = <x:ref>OWS</x:ref> ";" <x:ref>OWS</x:ref> <x:ref>token</x:ref> [ "=" <x:ref>word</x:ref> ]
    5540 </artwork></figure>
    5541 <t>
    5542    The asterisk "*" character is used to group media types into ranges,
    5543    with "*/*" indicating all media types and "type/*" indicating all
    5544    subtypes of that type. The media-range &MAY; include media type
    5545    parameters that are applicable to that range.
    5546 </t>
    5547 <t>
    5548    Each media-range &MAY; be followed by one or more accept-params,
    5549    beginning with the "q" parameter for indicating a relative quality
    5550    factor. The first "q" parameter (if any) separates the media-range
    5551    parameter(s) from the accept-params. Quality factors allow the user
    5552    or user agent to indicate the relative degree of preference for that
    5553    media-range, using the qvalue scale from 0 to 1 (&qvalue;). The
    5554    default value is q=1.
    5555 </t>
    5556 <x:note>
    5557   <t>
    5558     <x:h>Note:</x:h> Use of the "q" parameter name to separate media type
    5559     parameters from Accept extension parameters is due to historical
    5560     practice. Although this prevents any media type parameter named
    5561     "q" from being used with a media range, such an event is believed
    5562     to be unlikely given the lack of any "q" parameters in the IANA
    5563     media type registry and the rare usage of any media type
    5564     parameters in Accept. Future media types are discouraged from
    5565     registering any parameter named "q".
    5566   </t>
    5567 </x:note>
    5568 <t>
    5569    The example
    5570 </t>
    5571 <figure><artwork type="example">
    5572   Accept: audio/*; q=0.2, audio/basic
    5573 </artwork></figure>
    5574 <t>
    5575    &SHOULD; be interpreted as "I prefer audio/basic, but send me any audio
    5576    type if it is the best available after an 80% mark-down in quality".
    5577 </t>
    5578 <t>
    5579    A request without any Accept header field implies that the user agent
    5580    will accept any media type in response.
    5581    If an Accept header field is present in a request and none of the
    5582    available representations for the response have a media type that is
    5583    listed as acceptable, the origin server &MAY; either
    5584    honor the Accept header field by sending a 406 (Not Acceptable) response
    5585    or disregard the Accept header field by treating the response as if
    5586    it is not subject to content negotiation.
    5587 </t>
    5588 <t>
    5589    A more elaborate example is
    5590 </t>
    5591 <figure><artwork type="example">
    5592   Accept: text/plain; q=0.5, text/html,
    5593           text/x-dvi; q=0.8, text/x-c
    5594 </artwork></figure>
    5595 <t>
    5596    Verbally, this would be interpreted as "text/html and text/x-c are
    5597    the preferred media types, but if they do not exist, then send the
    5598    text/x-dvi representation, and if that does not exist, send the text/plain
    5599    representation".
    5600 </t>
    5601 <t>
    5602    Media ranges can be overridden by more specific media ranges or
    5603    specific media types. If more than one media range applies to a given
    5604    type, the most specific reference has precedence. For example,
    5605 </t>
    5606 <figure><artwork type="example">
    5607   Accept: text/*, text/plain, text/plain;format=flowed, */*
    5608 </artwork></figure>
    5609 <t>
    5610    have the following precedence:
    5611    <list style="numbers">
    5612     <t>text/plain;format=flowed</t>
    5613     <t>text/plain</t>
    5614     <t>text/*</t>
    5615     <t>*/*</t>
    5616    </list>
    5617 </t>
    5618 <t>
    5619    The media type quality factor associated with a given type is
    5620    determined by finding the media range with the highest precedence
    5621    which matches that type. For example,
    5622 </t>
    5623 <figure><artwork type="example">
    5624   Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,
    5625           text/html;level=2;q=0.4, */*;q=0.5
    5626 </artwork></figure>
    5627 <t>
    5628    would cause the following values to be associated:
    5629 </t>
    5630 <texttable align="left">
    5631   <ttcol>Media Type</ttcol><ttcol>Quality Value</ttcol>
    5632   <c>text/html;level=1</c>    <c>1</c>
    5633   <c>text/html</c>            <c>0.7</c>
    5634   <c>text/plain</c>           <c>0.3</c>
    5635   <c>image/jpeg</c>           <c>0.5</c>
    5636   <c>text/html;level=2</c>    <c>0.4</c>
    5637   <c>text/html;level=3</c>    <c>0.7</c>
    5638 </texttable>
    5639 <t>
    5640       <x:h>Note:</x:h> A user agent might be provided with a default set of quality
    5641       values for certain media ranges. However, unless the user agent is
    5642       a closed system which cannot interact with other rendering agents,
    5643       this default set ought to be configurable by the user.
    5644 </t>
    5645 </section>
    5646 
    5647 <section title="Accept-Charset" anchor="header.accept-charset">
    5648   <iref primary="true" item="Accept-Charset header field" x:for-anchor=""/>
    5649   <iref primary="true" item="Header Fields" subitem="Accept-Charset" x:for-anchor=""/>
    5650   <x:anchor-alias value="Accept-Charset"/>
    5651 <t>
    5652    The "Accept-Charset" header field can be used by user agents to
    5653    indicate what character encodings are acceptable in a response
    5654    payload. This field allows
    5655    clients capable of understanding more comprehensive or special-purpose
    5656    character encodings to signal that capability to a server which is capable of
    5657    representing documents in those character encodings.
    5658 </t>
    5659 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Accept-Charset"/>
    5660   <x:ref>Accept-Charset</x:ref> = 1#( ( <x:ref>charset</x:ref> / "*" )
    5661                          [ <x:ref>OWS</x:ref> ";" <x:ref>OWS</x:ref> "q=" <x:ref>qvalue</x:ref> ] )
    5662 </artwork></figure>
    5663 <t>
    5664    Character encoding values (a.k.a., charsets) are described in
    5665    <xref target="character.sets"/>. Each charset &MAY; be given an
    5666    associated quality value which represents the user's preference
    5667    for that charset. The default value is q=1. An example is
    5668 </t>
    5669 <figure><artwork type="example">
    5670   Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
    5671 </artwork></figure>
    5672 <t>
    5673    The special value "*", if present in the Accept-Charset field,
    5674    matches every character encoding which is not mentioned elsewhere in the
    5675    Accept-Charset field. If no "*" is present in an Accept-Charset field, then
    5676    all character encodings not explicitly mentioned get a quality value of 0.
    5677 </t>
    5678 <t>
    5679    A request without any Accept-Charset header field implies that the user
    5680    agent will accept any character encoding in response.
    5681    If an Accept-Charset header field is present in a request and none of the
    5682    available representations for the response have a character encoding that
    5683    is listed as acceptable, the origin server &MAY; either honor the
    5684    Accept-Charset header field by sending a 406 (Not Acceptable) response or
    5685    disregard the Accept-Charset header field by treating the response as if
    5686    it is not subject to content negotiation.
    5687 </t>
    5688 </section>
    5689 
    5690 <section title="Accept-Encoding" anchor="header.accept-encoding">
    5691   <iref primary="true" item="Accept-Encoding header field" x:for-anchor=""/>
    5692   <iref primary="true" item="Header Fields" subitem="Accept-Encoding" x:for-anchor=""/>
    5693   <x:anchor-alias value="Accept-Encoding"/>
    5694   <x:anchor-alias value="codings"/>
    5695 <t>
    5696    The "Accept-Encoding" header field can be used by user agents to
    5697    indicate what response content-codings (<xref target="content.codings"/>)
    5698    are acceptable in the response.  An "identity" token is used as a synonym
    5699    for "no encoding" in order to communicate when no encoding is preferred.
    5700 </t>
    5701 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Accept-Encoding"/><iref primary="true" item="Grammar" subitem="codings"/>
    5702   <x:ref>Accept-Encoding</x:ref>  = #( <x:ref>codings</x:ref> [ <x:ref>OWS</x:ref> ";" <x:ref>OWS</x:ref> "q=" <x:ref>qvalue</x:ref> ] )
    5703   <x:ref>codings</x:ref>          = <x:ref>content-coding</x:ref> / "identity" / "*"
    5704 </artwork></figure>
    5705 <t>
    5706    Each codings value &MAY; be given an associated quality value which
    5707    represents the preference for that encoding. The default value is q=1.
    5708 </t>
    5709 <t>
    5710    For example,
    5711 </t>
    5712 <figure><artwork type="example">
    5713   Accept-Encoding: compress, gzip
    5714   Accept-Encoding:
    5715   Accept-Encoding: *
    5716   Accept-Encoding: compress;q=0.5, gzip;q=1.0
    5717   Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0
    5718 </artwork></figure>
    5719 <t>
    5720    A server tests whether a content-coding for a given representation is
    5721    acceptable, according to an Accept-Encoding field, using these rules:
    5722   <list style="numbers">
    5723       <t>The special "*" symbol in an Accept-Encoding field matches any
    5724          available content-coding not explicitly listed in the header
    5725          field.</t>
    5726 
    5727       <t>If the representation has no content-coding, then it is acceptable
    5728          by default unless specifically excluded by the Accept-Encoding field
    5729          stating either "identity;q=0" or "*;q=0" without a more specific
    5730          entry for "identity".</t>
    5731 
    5732       <t>If the representation's content-coding is one of the content-codings
    5733          listed in the Accept-Encoding field, then it is acceptable unless
    5734          it is accompanied by a qvalue of 0. (As defined in &qvalue;, a
    5735          qvalue of 0 means "not acceptable".)</t>
    5736 
    5737       <t>If multiple content-codings are acceptable, then the acceptable
    5738          content-coding with the highest non-zero qvalue is preferred.</t>
    5739   </list>
    5740 </t>
    5741 <t>
    5742    An Accept-Encoding header field with a combined field-value that is empty
    5743    implies that the user agent does not want any content-coding in response.
    5744    If an Accept-Encoding header field is present in a request and none of the
    5745    available representations for the response have a content-coding that
    5746    is listed as acceptable, the origin server &SHOULD; send a response
    5747    without any content-coding.
    5748 </t>
    5749 <t>
    5750    A request without an Accept-Encoding header field implies that the user
    5751    agent will accept any content-coding in response, but a representation
    5752    without content-coding is preferred for compatibility with the widest
    5753    variety of user agents.
    5754 </t>
    5755 <x:note>
    5756   <t>
    5757     <x:h>Note:</x:h> Most HTTP/1.0 applications do not recognize or obey qvalues
    5758     associated with content-codings. This means that qvalues will not
    5759     work and are not permitted with x-gzip or x-compress.
    5760   </t>
    5761 </x:note>
    5762 </section>
    5763 
    5764 <section title="Accept-Language" anchor="header.accept-language">
    5765   <iref primary="true" item="Accept-Language header field" x:for-anchor=""/>
    5766   <iref primary="true" item="Header Fields" subitem="Accept-Language" x:for-anchor=""/>
    5767   <x:anchor-alias value="Accept-Language"/>
    5768   <x:anchor-alias value="language-range"/>
    5769 <t>
    5770    The "Accept-Language" header field can be used by user agents to
    5771    indicate the set of natural languages that are preferred in the response.
    5772    Language tags are defined in <xref target="language.tags"/>.
    5773 </t>
    5774 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Accept-Language"/><iref primary="true" item="Grammar" subitem="language-range"/>
    5775   <x:ref>Accept-Language</x:ref> =
    5776                     1#( <x:ref>language-range</x:ref> [ <x:ref>OWS</x:ref> ";" <x:ref>OWS</x:ref> "q=" <x:ref>qvalue</x:ref> ] )
    5777   <x:ref>language-range</x:ref>  =
    5778             &lt;language-range, defined in <xref target="RFC4647" x:fmt="," x:sec="2.1"/>&gt;
    5779 </artwork></figure>
    5780 <t>
    5781    Each language-range can be given an associated quality value which
    5782    represents an estimate of the user's preference for the languages
    5783    specified by that range. The quality value defaults to "q=1". For
    5784    example,
    5785 </t>
    5786 <figure><artwork type="example">
    5787   Accept-Language: da, en-gb;q=0.8, en;q=0.7
    5788 </artwork></figure>
    5789 <t>
    5790    would mean: "I prefer Danish, but will accept British English and
    5791    other types of English".
    5792    (see also <xref target="RFC4647" x:sec="2.3" x:fmt="of"/>)
    5793 </t>
    5794 <t>
    5795    For matching, <xref target="RFC4647" x:sec="3" x:fmt="of"/> defines
    5796    several matching schemes. Implementations can offer the most appropriate
    5797    matching scheme for their requirements.
    5798 </t>
    5799 <x:note>
    5800   <t>
    5801     <x:h>Note:</x:h> The "Basic Filtering" scheme (<xref target="RFC4647"
    5802     x:fmt="," x:sec="3.3.1"/>) is identical to the matching scheme that was
    5803     previously defined in <xref target="RFC2616" x:fmt="of" x:sec="14.4"/>.
    5804   </t>
    5805 </x:note>
    5806 <t>
    5807    It might be contrary to the privacy expectations of the user to send
    5808    an Accept-Language header field with the complete linguistic preferences of
    5809    the user in every request. For a discussion of this issue, see
    5810    <xref target="privacy.issues.connected.to.accept.header.fields"/>.
    5811 </t>
    5812 <t>
    5813    As intelligibility is highly dependent on the individual user, it is
    5814    recommended that client applications make the choice of linguistic
    5815    preference available to the user. If the choice is not made
    5816    available, then the Accept-Language header field &MUST-NOT; be given in
    5817    the request.
    5818 </t>
    5819 <x:note>
    5820   <t>
    5821     <x:h>Note:</x:h> When making the choice of linguistic preference available to
    5822     the user, we remind implementors of  the fact that users are not
    5823     familiar with the details of language matching as described above,
    5824     and ought to be provided appropriate guidance. As an example, users
    5825     might assume that on selecting "en-gb", they will be served any
    5826     kind of English document if British English is not available. A
    5827     user agent might suggest in such a case to add "en" to get the
    5828     best matching behavior.
    5829   </t>
    5830 </x:note>
    5831 </section>
    5832 
    5833 <section title="Content-Encoding" anchor="header.content-encoding">
    5834   <iref primary="true" item="Content-Encoding header field" x:for-anchor=""/>
    5835   <iref primary="true" item="Header Fields" subitem="Content-Encoding" x:for-anchor=""/>
    5836   <x:anchor-alias value="Content-Encoding"/>
    5837 <t>
    5838    The "Content-Encoding" header field indicates what content-codings
    5839    have been applied to the representation beyond those inherent in the media
    5840    type, and thus what decoding mechanisms have to be applied in order to obtain
    5841    the media-type referenced by the Content-Type header field.
    5842    Content-Encoding is primarily used to allow a representation to be
    5843    compressed without losing the identity of its underlying media type.
    5844 </t>
    5845 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Encoding"/>
    5846   <x:ref>Content-Encoding</x:ref> = 1#<x:ref>content-coding</x:ref>
    5847 </artwork></figure>
    5848 <t>
    5849    Content codings are defined in <xref target="content.codings"/>. An example of its use is
    5850 </t>
    5851 <figure><artwork type="example">
    5852   Content-Encoding: gzip
    5853 </artwork></figure>
    5854 <t>
    5855    The content-coding is a characteristic of the representation.
    5856    Typically, the representation body is stored with this
    5857    encoding and is only decoded before rendering or analogous usage.
    5858    However, a transforming proxy &MAY; modify the content-coding if the
    5859    new coding is known to be acceptable to the recipient, unless the
    5860    "no-transform" cache-control directive is present in the message.
    5861 </t>
    5862 <t>
    5863    If the media type includes an inherent encoding, such as a data format
    5864    that is always compressed, then that encoding would not be restated as
    5865    a Content-Encoding even if it happens to be the same algorithm as one
    5866    of the content-codings.  Such a content-coding would only be listed if,
    5867    for some bizarre reason, it is applied a second time to form the
    5868    representation.  Likewise, an origin server might choose to publish the
    5869    same payload data as multiple representations that differ only in whether
    5870    the coding is defined as part of Content-Type or Content-Encoding, since
    5871    some user agents will behave differently in their handling of each
    5872    response (e.g., open a "Save as ..." dialog instead of automatic
    5873    decompression and rendering of content).
    5874 </t>
    5875 <t>
    5876    A representation that has a content-coding applied to it &MUST; include
    5877    a Content-Encoding header field (<xref target="header.content-encoding"/>)
    5878    that lists the content-coding(s) applied.
    5879 </t>
    5880 <t>
    5881    If multiple encodings have been applied to a representation, the content
    5882    codings &MUST; be listed in the order in which they were applied.
    5883    Additional information about the encoding parameters &MAY; be provided
    5884    by other header fields not defined by this specification.
    5885 </t>
    5886 <t>
    5887    If the content-coding of a representation in a request message is not
    5888    acceptable to the origin server, the server &SHOULD; respond with a
    5889    status code of 415 (Unsupported Media Type).
    5890 </t>
    5891 </section>
    5892 
    5893 <section title="Content-Language" anchor="header.content-language">
    5894   <iref primary="true" item="Content-Language header field" x:for-anchor=""/>
    5895   <iref primary="true" item="Header Fields" subitem="Content-Language" x:for-anchor=""/>
    5896   <x:anchor-alias value="Content-Language"/>
    5897 <t>
    5898    The "Content-Language" header field describes the natural
    5899    language(s) of the intended audience for the representation. Note that this might
    5900    not be equivalent to all the languages used within the representation.
    5901 </t>
    5902 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Language"/>
    5903   <x:ref>Content-Language</x:ref> = 1#<x:ref>language-tag</x:ref>
    5904 </artwork></figure>
    5905 <t>
    5906    Language tags are defined in <xref target="language.tags"/>. The primary purpose of
    5907    Content-Language is to allow a user to identify and differentiate
    5908    representations according to the user's own preferred language. Thus, if the
    5909    body content is intended only for a Danish-literate audience, the
    5910    appropriate field is
    5911 </t>
    5912 <figure><artwork type="example">
    5913   Content-Language: da
    5914 </artwork></figure>
    5915 <t>
    5916    If no Content-Language is specified, the default is that the content
    5917    is intended for all language audiences. This might mean that the
    5918    sender does not consider it to be specific to any natural language,
    5919    or that the sender does not know for which language it is intended.
    5920 </t>
    5921 <t>
    5922    Multiple languages &MAY; be listed for content that is intended for
    5923    multiple audiences. For example, a rendition of the "Treaty of
    5924    Waitangi", presented simultaneously in the original Maori and English
    5925    versions, would call for
    5926 </t>
    5927 <figure><artwork type="example">
    5928   Content-Language: mi, en
    5929 </artwork></figure>
    5930 <t>
    5931    However, just because multiple languages are present within a representation
    5932    does not mean that it is intended for multiple linguistic audiences.
    5933    An example would be a beginner's language primer, such as "A First
    5934    Lesson in Latin", which is clearly intended to be used by an
    5935    English-literate audience. In this case, the Content-Language would
    5936    properly only include "en".
    5937 </t>
    5938 <t>
    5939    Content-Language &MAY; be applied to any media type &mdash; it is not
    5940    limited to textual documents.
    5941 </t>
    5942 </section>
    5943 
    5944 <section title="Content-Location" anchor="header.content-location">
    5945   <iref primary="true" item="Content-Location header field" x:for-anchor=""/>
    5946   <iref primary="true" item="Header Fields" subitem="Content-Location" x:for-anchor=""/>
    5947   <x:anchor-alias value="Content-Location"/>
    5948 <t>
    5949    The "Content-Location" header field supplies a URI that can be used
    5950    as a specific identifier for the representation in this message.
    5951    In other words, if one were to perform a GET on this URI at the time
    5952    of this message's generation, then a 200 response would contain the
    5953    same representation that is enclosed as payload in this message.
    5954 </t>
    5955 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Location"/>
    5956   <x:ref>Content-Location</x:ref> = <x:ref>absolute-URI</x:ref> / <x:ref>partial-URI</x:ref>
    5957 </artwork></figure>
    5958 <t>
    5959    The Content-Location value is not a replacement for the effective
    5960    Request URI (&effective-request-uri;).  It is representation metadata.
    5961    It has the same syntax and semantics as the header field of the same name
    5962    defined for MIME body parts in <xref target="RFC2557" x:fmt="of" x:sec="4"/>.
    5963    However, its appearance in an HTTP message has some special implications
    5964    for HTTP recipients.
    5965 </t>
    5966 <t>
    5967    If Content-Location is included in a response message and its value
    5968    is the same as the effective request URI, then the response payload
    5969    &SHOULD; be considered a current representation of that resource.
    5970    For a GET or HEAD request, this is the same as the default semantics
    5971    when no Content-Location is provided by the server.  For a state-changing
    5972    request like PUT or POST, it implies that the server's response contains
    5973    the new representation of that resource, thereby distinguishing it from
    5974    representations that might only report about the action (e.g., "It worked!").
    5975    This allows authoring applications to update their local copies without
    5976    the need for a subsequent GET request.
    5977 </t>
    5978 <t>
    5979    If Content-Location is included in a response message and its value
    5980    differs from the effective request URI, then the origin server is
    5981    informing recipients that this representation has its own, presumably
    5982    more specific, identifier.  For a GET or HEAD request, this is an
    5983    indication that the effective request URI identifies a resource that
    5984    is subject to content negotiation and the selected representation for
    5985    this response can also be found at the identified URI.  For other
    5986    methods, such a Content-Location indicates that this representation
    5987    contains a report on the action's status and the same report is
    5988    available (for future access with GET) at the given URI.  For
    5989    example, a purchase transaction made via a POST request might
    5990    include a receipt document as the payload of the 200 response;
    5991    the Content-Location value provides an identifier for retrieving
    5992    a copy of that same receipt in the future.
    5993 </t>
    5994 <t>
    5995    If Content-Location is included in a request message, then it &MAY;
    5996    be interpreted by the origin server as an indication of where the
    5997    user agent originally obtained the content of the enclosed
    5998    representation (prior to any subsequent modification of the content
    5999    by that user agent).  In other words, the user agent is providing
    6000    the same representation metadata that it received with the original
    6001    representation.  However, such interpretation &MUST-NOT; be used to
    6002    alter the semantics of the method requested by the client.  For
    6003    example, if a client makes a PUT request on a negotiated resource
    6004    and the origin server accepts that PUT (without redirection), then the
    6005    new set of values for that resource is expected to be consistent with
    6006    the one representation supplied in that PUT; the Content-Location
    6007    cannot be used as a form of reverse content selection that
    6008    identifies only one of the negotiated representations to be updated.
    6009    If the user agent had wanted the latter semantics, it would have applied
    6010    the PUT directly to the Content-Location URI.
    6011 </t>
    6012 <t>
    6013    A Content-Location field received in a request message is transitory
    6014    information that &SHOULD-NOT; be saved with other representation
    6015    metadata for use in later responses.  The Content-Location's value
    6016    might be saved for use in other contexts, such as within source links
    6017    or other metadata.
    6018 </t>
    6019 <t>
    6020    A cache cannot assume that a representation with a Content-Location
    6021    different from the URI used to retrieve it can be used to respond to
    6022    later requests on that Content-Location URI.
    6023 </t>
    6024 <t>
    6025    If the Content-Location value is a partial URI, the partial URI is
    6026    interpreted relative to the effective request URI.
    6027 </t>
    6028 </section>
    6029 
    6030 <section title="Content-Type" anchor="header.content-type">
    6031   <iref primary="true" item="Content-Type header field" x:for-anchor=""/>
    6032   <iref primary="true" item="Header Fields" subitem="Content-Type" x:for-anchor=""/>
    6033   <x:anchor-alias value="Content-Type"/>
    6034 <t>
    6035    The "Content-Type" header field indicates the media type of the
    6036    representation. In the case of responses to the HEAD method, the media type is
    6037    that which would have been sent had the request been a GET.
    6038 </t>
    6039 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Content-Type"/>
    6040   <x:ref>Content-Type</x:ref> = <x:ref>media-type</x:ref>
    6041 </artwork></figure>
    6042 <t>
    6043    Media types are defined in <xref target="media.types"/>. An example of the field is
    6044 </t>
    6045 <figure><artwork type="example">
    6046   Content-Type: text/html; charset=ISO-8859-4
    6047 </artwork></figure>
    6048 <t>
    6049    Further discussion of Content-Type is provided in <xref target="representation.data"/>.
    6050 </t>
    6051 </section>
    6052 
    6053 </section>
    60546048
    60556049<section title="IANA Considerations" anchor="IANA.considerations3">
Note: See TracChangeset for help on using the changeset viewer.