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

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

File:
1 edited

Legend:

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

    r1648 r1649  
    21012101   protocols are supported by that server.
    21022102</t>
    2103 
    2104 </section>
    2105 </section>
    2106 
    2107 </section>
    2108 
    2109 <section title="Representation" anchor="representation">
    2110 <t>
    2111    Request and Response messages &MAY; transfer a representation if not otherwise
    2112    restricted by the request method or response status code. A representation
    2113    consists of metadata (representation header fields) and data (representation
    2114    body).  When a complete or partial representation is enclosed in an HTTP message,
    2115    it is referred to as the payload of the message.
    2116 </t>
    2117 <t>
    2118    A representation body is only present in a message when a message body is
    2119    present, as described in &message-body;. The representation body is obtained
    2120    from the message body by decoding any Transfer-Encoding that might
    2121    have been applied to ensure safe and proper transfer of the message.
    2122 </t>
    2123 
    2124 <section title="Identifying the Resource Associated with a Representation" anchor="identifying.response.associated.with.representation">
    2125 <t>
    2126    It is sometimes necessary to determine an identifier for the resource
    2127    associated with a representation.
    2128 </t>
    2129 <t>
    2130    An HTTP request representation, when present, is always associated with an
    2131    anonymous (i.e., unidentified) resource.
    2132 </t>
    2133 <t>
    2134    In the common case, an HTTP response is a representation of the target
    2135    resource (see &effective-request-uri;). However, this is not always the
    2136    case. To determine the URI of the resource a response is associated with,
    2137    the following rules are used (with the first applicable one being selected):
    2138 </t>
    2139 <t><list style="numbers">
    2140    <t>If the response status code is 200 or 203 and the request method was GET,
    2141    the response payload is a representation of the target resource.</t>
    2142    <t>If the response status code is 204, 206, or 304 and the request method was GET
    2143    or HEAD, the response payload is a partial representation of the target
    2144    resource.</t>
    2145    <t>If the response has a Content-Location header field, and that URI is the same
    2146    as the effective request URI, the response payload is a representation of the
    2147    target resource.</t>
    2148    <t>If the response has a Content-Location header field, and that URI is not the
    2149    same as the effective request URI, then the response asserts that its
    2150    payload is a representation of the resource identified by the
    2151    Content-Location URI. However, such an assertion cannot be trusted unless
    2152    it can be verified by other means (not defined by HTTP).</t>
    2153    <t>Otherwise, the response is a representation of an anonymous (i.e.,
    2154    unidentified) resource.</t>
    2155 </list></t>
    2156 <t>
    2157   <cref anchor="TODO-req-uri">
    2158    The comparison function is going to have to be defined somewhere,
    2159    because we already need to compare URIs for things like cache invalidation.</cref>
    2160 </t>
    2161 </section>
    2162 
    2163 </section>
    2164 
     2103</section>
     2104</section>
     2105</section>
    21652106
    21662107<section title="Protocol Parameters" anchor="protocol.parameters">
     
    25982539<t>
    25992540   See <xref target="RFC5646"/> for further information.
     2541</t>
     2542</section>
     2543</section>
     2544
     2545<section title="Payload" anchor="payload">
     2546<t>
     2547   HTTP messages &MAY; transfer a payload if not otherwise restricted by
     2548   the request method or response status code.  The payload consists of
     2549   metadata, in the form of header fields, and data, in the form of the
     2550   sequence of octets in the message body after any transfer-coding has
     2551   been decoded.
     2552</t>
     2553<iref item="payload"/>
     2554<t>   
     2555   A "<x:dfn>payload</x:dfn>" in HTTP is always a partial or complete
     2556   representation of some resource.  We use separate terms for payload
     2557   and representation because some messages contain only the associated
     2558   representation's header fields (e.g., responses to HEAD) or only some
     2559   part(s) of the representation (e.g., the 206 status code).
     2560</t>
     2561<section title="Payload Header Fields" anchor="payload.header.fields">
     2562  <x:anchor-alias value="payload-header"/>
     2563<t>
     2564   HTTP header fields that specifically define the payload, rather than the
     2565   associated representation, are referred to as "payload header fields".
     2566   The following payload header fields are defined by HTTP/1.1:
     2567</t>
     2568<texttable align="left">
     2569  <ttcol>Header Field Name</ttcol>
     2570  <ttcol>Defined in...</ttcol>
     2571
     2572  <c>Content-Length</c> <c>&header-content-length;</c>
     2573  <c>Content-Range</c> <c>&header-content-range;</c>
     2574</texttable>
     2575</section>
     2576
     2577<section title="Payload Body" anchor="payload.body">
     2578  <x:anchor-alias value="payload-body"/>
     2579<t>
     2580   A payload body is only present in a message when a message body is
     2581   present, as described in &message-body;. The payload body is obtained
     2582   from the message body by decoding any Transfer-Encoding that might
     2583   have been applied to ensure safe and proper transfer of the message.
     2584</t>
     2585</section>
     2586</section>
     2587
     2588<section title="Representation" anchor="representation">
     2589<t>
     2590   Request and Response messages &MAY; transfer a representation if not otherwise
     2591   restricted by the request method or response status code. A representation
     2592   consists of metadata (representation header fields) and data (representation
     2593   body).  When a complete or partial representation is enclosed in an HTTP message,
     2594   it is referred to as the payload of the message.
     2595</t>
     2596<t>
     2597   A representation body is only present in a message when a message body is
     2598   present, as described in &message-body;. The representation body is obtained
     2599   from the message body by decoding any Transfer-Encoding that might
     2600   have been applied to ensure safe and proper transfer of the message.
     2601</t>
     2602
     2603<section title="Identifying the Resource Associated with a Representation" anchor="identifying.response.associated.with.representation">
     2604<t>
     2605   It is sometimes necessary to determine an identifier for the resource
     2606   associated with a representation.
     2607</t>
     2608<t>
     2609   An HTTP request representation, when present, is always associated with an
     2610   anonymous (i.e., unidentified) resource.
     2611</t>
     2612<t>
     2613   In the common case, an HTTP response is a representation of the target
     2614   resource (see &effective-request-uri;). However, this is not always the
     2615   case. To determine the URI of the resource a response is associated with,
     2616   the following rules are used (with the first applicable one being selected):
     2617</t>
     2618<t><list style="numbers">
     2619   <t>If the response status code is 200 or 203 and the request method was GET,
     2620   the response payload is a representation of the target resource.</t>
     2621   <t>If the response status code is 204, 206, or 304 and the request method was GET
     2622   or HEAD, the response payload is a partial representation of the target
     2623   resource.</t>
     2624   <t>If the response has a Content-Location header field, and that URI is the same
     2625   as the effective request URI, the response payload is a representation of the
     2626   target resource.</t>
     2627   <t>If the response has a Content-Location header field, and that URI is not the
     2628   same as the effective request URI, then the response asserts that its
     2629   payload is a representation of the resource identified by the
     2630   Content-Location URI. However, such an assertion cannot be trusted unless
     2631   it can be verified by other means (not defined by HTTP).</t>
     2632   <t>Otherwise, the response is a representation of an anonymous (i.e.,
     2633   unidentified) resource.</t>
     2634</list></t>
     2635<t>
     2636  <cref anchor="TODO-req-uri">
     2637   The comparison function is going to have to be defined somewhere,
     2638   because we already need to compare URIs for things like cache invalidation.</cref>
     2639</t>
     2640</section>
     2641
     2642</section>
     2643
     2644
     2645
     2646<section title="Content Negotiation" anchor="content.negotiation">
     2647<t>
     2648   HTTP responses include a representation which contains information for
     2649   interpretation, whether by a human user or for further processing.
     2650   Often, the server has different ways of representing the
     2651   same information; for example, in different formats, languages,
     2652   or using different character encodings.
     2653</t>
     2654<t>
     2655   HTTP clients and their users might have different or variable
     2656   capabilities, characteristics or preferences which would influence
     2657   which representation, among those available from the server,
     2658   would be best for the server to deliver. For this reason, HTTP
     2659   provides mechanisms for "content negotiation" &mdash; a process of
     2660   allowing selection of a representation of a given resource,
     2661   when more than one is available.
     2662</t>
     2663<t>
     2664   This specification defines two patterns of content negotiation;
     2665   "server-driven", where the server selects the representation based
     2666   upon the client's stated preferences, and "agent-driven" negotiation,
     2667   where the server provides a list of representations for the client to
     2668   choose from, based upon their metadata. In addition,  there are
     2669   other patterns: some applications use an "active content" pattern,
     2670   where the server returns active content which runs on the client
     2671   and, based on client available parameters, selects additional
     2672   resources to invoke. "Transparent Content Negotiation" (<xref target="RFC2295"/>)
     2673   has also been proposed.
     2674</t>
     2675<t>
     2676   These patterns are all widely used, and have trade-offs in applicability
     2677   and practicality. In particular, when the number of preferences or
     2678   capabilities to be expressed by a client are large (such as when many
     2679   different formats are supported by a user-agent), server-driven
     2680   negotiation becomes unwieldy, and might not be appropriate. Conversely,
     2681   when the number of representations to choose from is very large,
     2682   agent-driven negotiation might not be appropriate.
     2683</t>
     2684<t>
     2685   Note that in all cases, the supplier of representations has the
     2686   responsibility for determining which representations might be
     2687   considered to be the "same information".
     2688</t>
     2689
     2690<section title="Server-driven Negotiation" anchor="server-driven.negotiation">
     2691<t>
     2692   If the selection of the best representation for a response is made by
     2693   an algorithm located at the server, it is called server-driven
     2694   negotiation. Selection is based on the available representations of
     2695   the response (the dimensions over which it can vary; e.g., language,
     2696   content-coding, etc.) and the contents of particular header fields in
     2697   the request message or on other information pertaining to the request
     2698   (such as the network address of the client).
     2699</t>
     2700<t>
     2701   Server-driven negotiation is advantageous when the algorithm for
     2702   selecting from among the available representations is difficult to
     2703   describe to the user agent, or when the server desires to send its
     2704   "best guess" to the client along with the first response (hoping to
     2705   avoid the round-trip delay of a subsequent request if the "best
     2706   guess" is good enough for the user). In order to improve the server's
     2707   guess, the user agent &MAY; include request header fields (Accept,
     2708   Accept-Language, Accept-Encoding, etc.) which describe its
     2709   preferences for such a response.
     2710</t>
     2711<t>
     2712   Server-driven negotiation has disadvantages:
     2713  <list style="numbers">
     2714    <t>
     2715         It is impossible for the server to accurately determine what
     2716         might be "best" for any given user, since that would require
     2717         complete knowledge of both the capabilities of the user agent
     2718         and the intended use for the response (e.g., does the user want
     2719         to view it on screen or print it on paper?).
     2720    </t>
     2721    <t>
     2722         Having the user agent describe its capabilities in every
     2723         request can be both very inefficient (given that only a small
     2724         percentage of responses have multiple representations) and a
     2725         potential violation of the user's privacy.
     2726    </t>
     2727    <t>
     2728         It complicates the implementation of an origin server and the
     2729         algorithms for generating responses to a request.
     2730    </t>
     2731    <t>
     2732         It might limit a public cache's ability to use the same response
     2733         for multiple user's requests.
     2734    </t>
     2735  </list>
     2736</t>
     2737<t>
     2738   Server-driven negotiation allows the user agent to specify its preferences,
     2739   but it cannot expect responses to always honor them. For example, the origin
     2740   server might not implement server-driven negotiation, or it might decide that
     2741   sending a response that doesn't conform to them is better than sending a 406
     2742   (Not Acceptable) response.
     2743</t>
     2744<t>
     2745   Many of the mechanisms for expressing preferences use quality values to
     2746   declare relative preference. See &qvalue; for more information.
     2747</t>
     2748<t>
     2749   HTTP/1.1 includes the following header fields for enabling
     2750   server-driven negotiation through description of user agent
     2751   capabilities and user preferences: Accept (<xref target="header.accept"/>), Accept-Charset
     2752   (<xref target="header.accept-charset"/>), Accept-Encoding (<xref target="header.accept-encoding"/>), Accept-Language
     2753   (<xref target="header.accept-language"/>), and User-Agent (&header-user-agent;).
     2754   However, an origin server is not limited to these dimensions and &MAY; vary
     2755   the response based on any aspect of the request, including aspects
     2756   of the connection (e.g., IP address) or information within extension
     2757   header fields not defined by this specification.
     2758</t>
     2759<x:note>
     2760  <t>
     2761    <x:h>Note:</x:h> In practice, User-Agent based negotiation is fragile,
     2762    because new clients might not be recognized.
     2763  </t>
     2764</x:note>
     2765<t>
     2766   The Vary header field (&header-vary;) can be used to express the parameters the
     2767   server uses to select a representation that is subject to server-driven
     2768   negotiation.
     2769</t>
     2770</section>
     2771
     2772<section title="Agent-driven Negotiation" anchor="agent-driven.negotiation">
     2773<t>
     2774   With agent-driven negotiation, selection of the best representation
     2775   for a response is performed by the user agent after receiving an
     2776   initial response from the origin server. Selection is based on a list
     2777   of the available representations of the response included within the
     2778   header fields or body of the initial response, with each
     2779   representation identified by its own URI. Selection from among the
     2780   representations can be performed automatically (if the user agent is
     2781   capable of doing so) or manually by the user selecting from a
     2782   generated (possibly hypertext) menu.
     2783</t>
     2784<t>
     2785   Agent-driven negotiation is advantageous when the response would vary
     2786   over commonly-used dimensions (such as type, language, or encoding),
     2787   when the origin server is unable to determine a user agent's
     2788   capabilities from examining the request, and generally when public
     2789   caches are used to distribute server load and reduce network usage.
     2790</t>
     2791<t>
     2792   Agent-driven negotiation suffers from the disadvantage of needing a
     2793   second request to obtain the best alternate representation. This
     2794   second request is only efficient when caching is used. In addition,
     2795   this specification does not define any mechanism for supporting
     2796   automatic selection, though it also does not prevent any such
     2797   mechanism from being developed as an extension and used within
     2798   HTTP/1.1.
     2799</t>
     2800<t>
     2801   This specification defines the 300 (Multiple Choices) and 406 (Not Acceptable)
     2802   status codes for enabling agent-driven negotiation when the server is
     2803   unwilling or unable to provide a varying response using server-driven
     2804   negotiation.
    26002805</t>
    26012806</section>
     
    64726677<section title="THE TEXT FORMERLY KNOWN AS PART3">
    64736678
    6474 <section title="Payload" anchor="payload">
    6475 <t>
    6476    HTTP messages &MAY; transfer a payload if not otherwise restricted by
    6477    the request method or response status code.  The payload consists of
    6478    metadata, in the form of header fields, and data, in the form of the
    6479    sequence of octets in the message body after any transfer-coding has
    6480    been decoded.
    6481 </t>
    6482 <iref item="payload"/>
    6483 <t>   
    6484    A "<x:dfn>payload</x:dfn>" in HTTP is always a partial or complete
    6485    representation of some resource.  We use separate terms for payload
    6486    and representation because some messages contain only the associated
    6487    representation's header fields (e.g., responses to HEAD) or only some
    6488    part(s) of the representation (e.g., the 206 status code).
    6489 </t>
    6490 <section title="Payload Header Fields" anchor="payload.header.fields">
    6491   <x:anchor-alias value="payload-header"/>
    6492 <t>
    6493    HTTP header fields that specifically define the payload, rather than the
    6494    associated representation, are referred to as "payload header fields".
    6495    The following payload header fields are defined by HTTP/1.1:
    6496 </t>
    6497 <texttable align="left">
    6498   <ttcol>Header Field Name</ttcol>
    6499   <ttcol>Defined in...</ttcol>
    6500 
    6501   <c>Content-Length</c> <c>&header-content-length;</c>
    6502   <c>Content-Range</c> <c>&header-content-range;</c>
    6503 </texttable>
    6504 </section>
    6505 
    6506 <section title="Payload Body" anchor="payload.body">
    6507   <x:anchor-alias value="payload-body"/>
    6508 <t>
    6509    A payload body is only present in a message when a message body is
    6510    present, as described in &message-body;. The payload body is obtained
    6511    from the message body by decoding any Transfer-Encoding that might
    6512    have been applied to ensure safe and proper transfer of the message.
    6513 </t>
    6514 </section>
    6515 </section>
    6516 
    65176679<section title="Representation" anchor="representation3">
    65186680<iref item="representation"/>
     
    66286790</section>
    66296791</section>
    6630 
    6631 <section title="Content Negotiation" anchor="content.negotiation">
    6632 <t>
    6633    HTTP responses include a representation which contains information for
    6634    interpretation, whether by a human user or for further processing.
    6635    Often, the server has different ways of representing the
    6636    same information; for example, in different formats, languages,
    6637    or using different character encodings.
    6638 </t>
    6639 <t>
    6640    HTTP clients and their users might have different or variable
    6641    capabilities, characteristics or preferences which would influence
    6642    which representation, among those available from the server,
    6643    would be best for the server to deliver. For this reason, HTTP
    6644    provides mechanisms for "content negotiation" &mdash; a process of
    6645    allowing selection of a representation of a given resource,
    6646    when more than one is available.
    6647 </t>
    6648 <t>
    6649    This specification defines two patterns of content negotiation;
    6650    "server-driven", where the server selects the representation based
    6651    upon the client's stated preferences, and "agent-driven" negotiation,
    6652    where the server provides a list of representations for the client to
    6653    choose from, based upon their metadata. In addition,  there are
    6654    other patterns: some applications use an "active content" pattern,
    6655    where the server returns active content which runs on the client
    6656    and, based on client available parameters, selects additional
    6657    resources to invoke. "Transparent Content Negotiation" (<xref target="RFC2295"/>)
    6658    has also been proposed.
    6659 </t>
    6660 <t>
    6661    These patterns are all widely used, and have trade-offs in applicability
    6662    and practicality. In particular, when the number of preferences or
    6663    capabilities to be expressed by a client are large (such as when many
    6664    different formats are supported by a user-agent), server-driven
    6665    negotiation becomes unwieldy, and might not be appropriate. Conversely,
    6666    when the number of representations to choose from is very large,
    6667    agent-driven negotiation might not be appropriate.
    6668 </t>
    6669 <t>
    6670    Note that in all cases, the supplier of representations has the
    6671    responsibility for determining which representations might be
    6672    considered to be the "same information".
    6673 </t>
    6674 
    6675 <section title="Server-driven Negotiation" anchor="server-driven.negotiation">
    6676 <t>
    6677    If the selection of the best representation for a response is made by
    6678    an algorithm located at the server, it is called server-driven
    6679    negotiation. Selection is based on the available representations of
    6680    the response (the dimensions over which it can vary; e.g., language,
    6681    content-coding, etc.) and the contents of particular header fields in
    6682    the request message or on other information pertaining to the request
    6683    (such as the network address of the client).
    6684 </t>
    6685 <t>
    6686    Server-driven negotiation is advantageous when the algorithm for
    6687    selecting from among the available representations is difficult to
    6688    describe to the user agent, or when the server desires to send its
    6689    "best guess" to the client along with the first response (hoping to
    6690    avoid the round-trip delay of a subsequent request if the "best
    6691    guess" is good enough for the user). In order to improve the server's
    6692    guess, the user agent &MAY; include request header fields (Accept,
    6693    Accept-Language, Accept-Encoding, etc.) which describe its
    6694    preferences for such a response.
    6695 </t>
    6696 <t>
    6697    Server-driven negotiation has disadvantages:
    6698   <list style="numbers">
    6699     <t>
    6700          It is impossible for the server to accurately determine what
    6701          might be "best" for any given user, since that would require
    6702          complete knowledge of both the capabilities of the user agent
    6703          and the intended use for the response (e.g., does the user want
    6704          to view it on screen or print it on paper?).
    6705     </t>
    6706     <t>
    6707          Having the user agent describe its capabilities in every
    6708          request can be both very inefficient (given that only a small
    6709          percentage of responses have multiple representations) and a
    6710          potential violation of the user's privacy.
    6711     </t>
    6712     <t>
    6713          It complicates the implementation of an origin server and the
    6714          algorithms for generating responses to a request.
    6715     </t>
    6716     <t>
    6717          It might limit a public cache's ability to use the same response
    6718          for multiple user's requests.
    6719     </t>
    6720   </list>
    6721 </t>
    6722 <t>
    6723    Server-driven negotiation allows the user agent to specify its preferences,
    6724    but it cannot expect responses to always honor them. For example, the origin
    6725    server might not implement server-driven negotiation, or it might decide that
    6726    sending a response that doesn't conform to them is better than sending a 406
    6727    (Not Acceptable) response.
    6728 </t>
    6729 <t>
    6730    Many of the mechanisms for expressing preferences use quality values to
    6731    declare relative preference. See &qvalue; for more information.
    6732 </t>
    6733 <t>
    6734    HTTP/1.1 includes the following header fields for enabling
    6735    server-driven negotiation through description of user agent
    6736    capabilities and user preferences: Accept (<xref target="header.accept"/>), Accept-Charset
    6737    (<xref target="header.accept-charset"/>), Accept-Encoding (<xref target="header.accept-encoding"/>), Accept-Language
    6738    (<xref target="header.accept-language"/>), and User-Agent (&header-user-agent;).
    6739    However, an origin server is not limited to these dimensions and &MAY; vary
    6740    the response based on any aspect of the request, including aspects
    6741    of the connection (e.g., IP address) or information within extension
    6742    header fields not defined by this specification.
    6743 </t>
    6744 <x:note>
    6745   <t>
    6746     <x:h>Note:</x:h> In practice, User-Agent based negotiation is fragile,
    6747     because new clients might not be recognized.
    6748   </t>
    6749 </x:note>
    6750 <t>
    6751    The Vary header field (&header-vary;) can be used to express the parameters the
    6752    server uses to select a representation that is subject to server-driven
    6753    negotiation.
    6754 </t>
    6755 </section>
    6756 
    6757 <section title="Agent-driven Negotiation" anchor="agent-driven.negotiation">
    6758 <t>
    6759    With agent-driven negotiation, selection of the best representation
    6760    for a response is performed by the user agent after receiving an
    6761    initial response from the origin server. Selection is based on a list
    6762    of the available representations of the response included within the
    6763    header fields or body of the initial response, with each
    6764    representation identified by its own URI. Selection from among the
    6765    representations can be performed automatically (if the user agent is
    6766    capable of doing so) or manually by the user selecting from a
    6767    generated (possibly hypertext) menu.
    6768 </t>
    6769 <t>
    6770    Agent-driven negotiation is advantageous when the response would vary
    6771    over commonly-used dimensions (such as type, language, or encoding),
    6772    when the origin server is unable to determine a user agent's
    6773    capabilities from examining the request, and generally when public
    6774    caches are used to distribute server load and reduce network usage.
    6775 </t>
    6776 <t>
    6777    Agent-driven negotiation suffers from the disadvantage of needing a
    6778    second request to obtain the best alternate representation. This
    6779    second request is only efficient when caching is used. In addition,
    6780    this specification does not define any mechanism for supporting
    6781    automatic selection, though it also does not prevent any such
    6782    mechanism from being developed as an extension and used within
    6783    HTTP/1.1.
    6784 </t>
    6785 <t>
    6786    This specification defines the 300 (Multiple Choices) and 406 (Not Acceptable)
    6787    status codes for enabling agent-driven negotiation when the server is
    6788    unwilling or unable to provide a varying response using server-driven
    6789    negotiation.
    6790 </t>
    6791 </section>
    6792 </section>
    6793 
    6794 
    6795 <section title="Change Log (to be removed by RFC Editor before publication)" anchor="change.log3">
    6796 
    6797 <section title="Since RFC 2616">
    6798 <t>
    6799   Extracted relevant partitions from <xref target="RFC2616"/>.
    6800 </t>
    6801 </section>
    6802 
    6803 </section>
    68046792</section>
    68056793
Note: See TracChangeset for help on using the changeset viewer.