Changeset 745 for draft-ietf-httpbis
- Timestamp:
- 15/01/10 10:04:46 (11 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p3-payload.html
r741 r745 401 401 <meta name="DC.Creator" content="Reschke, J. F."> 402 402 <meta name="DC.Identifier" content="urn:ietf:id:draft-ietf-httpbis-p3-payload-latest"> 403 <meta name="DC.Date.Issued" scheme="ISO8601" content="2010-01- 01">403 <meta name="DC.Date.Issued" scheme="ISO8601" content="2010-01-15"> 404 404 <meta name="DC.Relation.Replaces" content="urn:ietf:rfc:2616"> 405 405 <meta name="DC.Description.Abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 3 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 3 defines HTTP message content, metadata, and content negotiation."> … … 427 427 </tr> 428 428 <tr> 429 <td class="left">Expires: July 5, 2010</td>429 <td class="left">Expires: July 19, 2010</td> 430 430 <td class="right">J. Mogul</td> 431 431 </tr> … … 484 484 <tr> 485 485 <td class="left"></td> 486 <td class="right">January 1 , 2010</td>486 <td class="right">January 15, 2010</td> 487 487 </tr> 488 488 </tbody> … … 514 514 <p>The list of Internet-Draft Shadow Directories can be accessed at <<a href="http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html</a>>. 515 515 </p> 516 <p>This Internet-Draft will expire in July 5, 2010.</p>516 <p>This Internet-Draft will expire in July 19, 2010.</p> 517 517 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 518 518 <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 570 570 <li class="tocline1">4.1 <a href="#server-driven.negotiation">Server-driven Negotiation</a></li> 571 571 <li class="tocline1">4.2 <a href="#agent-driven.negotiation">Agent-driven Negotiation</a></li> 572 <li class="tocline1">4.3 <a href="#transparent.negotiation">Transparent Negotiation</a></li>573 572 </ul> 574 573 </li> … … 918 917 </p> 919 918 <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <a id="content.negotiation" href="#content.negotiation">Content Negotiation</a></h1> 920 <p id="rfc.section.4.p.1">Most HTTP responses include an entity which contains information for interpretation by a human user. Naturally, it is desirable 921 to supply the user with the "best available" entity corresponding to the request. Unfortunately for servers and caches, not 922 all users have the same preferences for what is "best," and not all user agents are equally capable of rendering all entity 923 types. For that reason, HTTP has provisions for several mechanisms for "content negotiation" -- the process of selecting the 924 best representation for a given response when there are multiple representations available. 925 </p> 926 <div class="note"> 927 <p> <b>Note:</b> This is not called "format negotiation" because the alternate representations may be of the same media type, but use different 928 capabilities of that type, be in different languages, etc. 929 </p> 930 </div> 931 <p id="rfc.section.4.p.3">Any response containing an entity-body <em class="bcp14">MAY</em> be subject to negotiation, including error responses. 932 </p> 933 <p id="rfc.section.4.p.4">There are two kinds of content negotiation which are possible in HTTP: server-driven and agent-driven negotiation. These two 934 kinds of negotiation are orthogonal and thus may be used separately or in combination. One method of combination, referred 935 to as transparent negotiation, occurs when a cache uses the agent-driven negotiation information provided by the origin server 936 in order to provide server-driven negotiation for subsequent requests. 919 <p id="rfc.section.4.p.1">HTTP responses include a representation which contains information for interpretation, whether by a human user or for further 920 processing. Often, the server has different ways of representing the same information; for example, in different formats, 921 languages, or using different character encodings. 922 </p> 923 <p id="rfc.section.4.p.2">HTTP clients and their users might have different or variable capabilities, characteristics or preferences which would influence 924 which representation, among those available from the server, would be best for the server to deliver. For this reason, HTTP 925 provides mechanisms for "content negotiation" -- a process of allowing selection of a representation of a given resource, 926 when more than one is available. 927 </p> 928 <p id="rfc.section.4.p.3">This specification defines two patterns of content negotiation; "server-driven", where the server selects the representation 929 based upon the client's stated preferences, and "agent-driven" negotiation, where the server provides a list of representations 930 for the client to choose from, based upon their metadata. In addition, there are other patterns: some applications use an 931 "active content" pattern, where the server returns active content which runs on the client and, based on client available 932 parameters, selects additional resources to invoke. "Transparent Content Negotiation" (<a href="#RFC2295" id="rfc.xref.RFC2295.1"><cite title="Transparent Content Negotiation in HTTP">[RFC2295]</cite></a>) has also been proposed. 933 </p> 934 <p id="rfc.section.4.p.4">These patterns are all widely used, and have trade-offs in applicability and practicality. In particular, when the number 935 of preferences or capabilities to be expressed by a client are large (such as when many different formats are supported by 936 a user-agent), server-driven negotiation becomes unwieldy, and may not be appropriate. Conversely, when the number of representations 937 to choose from is very large, agent-driven negotiation may not be appropriate. 938 </p> 939 <p id="rfc.section.4.p.5">Note that in all cases, the supplier of representations has the responsibility for determining which representations might 940 be considered to be the "same information". 937 941 </p> 938 942 <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a> <a id="server-driven.negotiation" href="#server-driven.negotiation">Server-driven Negotiation</a></h2> … … 963 967 header fields not defined by this specification. 964 968 </p> 965 <p id="rfc.section.4.1.p.5">The Vary header field (<a href="p6-cache.html#header.vary" title="Vary">Section 3.5</a> of <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) can be used to express the parameters the server uses to select a representation that is subject to server-driven negotiation. 969 <div class="note"> 970 <p> <b>Note:</b> In practice, User-Agent based negotiation is fragile, because new clients might not be recognized. 971 </p> 972 </div> 973 <p id="rfc.section.4.1.p.6">The Vary header field (<a href="p6-cache.html#header.vary" title="Vary">Section 3.5</a> of <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) can be used to express the parameters the server uses to select a representation that is subject to server-driven negotiation. 966 974 </p> 967 975 <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a> <a id="agent-driven.negotiation" href="#agent-driven.negotiation">Agent-driven Negotiation</a></h2> … … 981 989 and used within HTTP/1.1. 982 990 </p> 983 <p id="rfc.section.4.2.p.4">HTTP/1.1 defines the 300 (Multiple Choices) and 406 (Not Acceptable) status codes for enabling agent-driven negotiation when 984 the server is unwilling or unable to provide a varying response using server-driven negotiation. 985 </p> 986 <h2 id="rfc.section.4.3"><a href="#rfc.section.4.3">4.3</a> <a id="transparent.negotiation" href="#transparent.negotiation">Transparent Negotiation</a></h2> 987 <p id="rfc.section.4.3.p.1">Transparent negotiation is a combination of both server-driven and agent-driven negotiation. When a cache is supplied with 988 a form of the list of available representations of the response (as in agent-driven negotiation) and the dimensions of variance 989 are completely understood by the cache, then the cache becomes capable of performing server-driven negotiation on behalf of 990 the origin server for subsequent requests on that resource. 991 </p> 992 <p id="rfc.section.4.3.p.2">Transparent negotiation has the advantage of distributing the negotiation work that would otherwise be required of the origin 993 server and also removing the second request delay of agent-driven negotiation when the cache is able to correctly guess the 994 right response. 995 </p> 996 <p id="rfc.section.4.3.p.3">This specification does not define any mechanism for transparent negotiation, though it also does not prevent any such mechanism 997 from being developed as an extension that could be used within HTTP/1.1. 991 <p id="rfc.section.4.2.p.4">This specification defines the 300 (Multiple Choices) and 406 (Not Acceptable) status codes for enabling agent-driven negotiation 992 when the server is unwilling or unable to provide a varying response using server-driven negotiation. 998 993 </p> 999 994 <h1 id="rfc.section.5"><a href="#rfc.section.5">5.</a> <a id="header.fields" href="#header.fields">Header Field Definitions</a></h1> … … 1592 1587 <h2 id="rfc.references.2"><a href="#rfc.section.9.2" id="rfc.section.9.2">9.2</a> Informative References 1593 1588 </h2> 1594 <table> 1589 <table> 1595 1590 <tr> 1596 1591 <td class="reference"><b id="BCP97">[BCP97]</b></td> … … 1626 1621 <td class="reference"><b id="RFC2277">[RFC2277]</b></td> 1627 1622 <td class="top"><a href="mailto:Harald.T.Alvestrand@uninett.no" title="UNINETT">Alvestrand, H.T.</a>, “<a href="http://tools.ietf.org/html/rfc2277">IETF Policy on Character Sets and Languages</a>”, BCP 18, RFC 2277, January 1998. 1623 </td> 1624 </tr> 1625 <tr> 1626 <td class="reference"><b id="RFC2295">[RFC2295]</b></td> 1627 <td class="top"><a href="mailto:koen@win.tue.nl" title="Technische Universiteit Eindhoven">Holtman, K.</a> and <a href="mailto:mutz@hpl.hp.com" title="Hewlett-Packard Company">A.H. Mutz</a>, “<a href="http://tools.ietf.org/html/rfc2295">Transparent Content Negotiation in HTTP</a>”, RFC 2295, March 1998. 1628 1628 </td> 1629 1629 </tr> … … 2032 2032 <p id="rfc.section.E.10.p.1">Closed issues: </p> 2033 2033 <ul> 2034 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/81">http://tools.ietf.org/wg/httpbis/trac/ticket/81</a>>: "Content Negotiation for media types" 2035 </li> 2034 2036 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/181">http://tools.ietf.org/wg/httpbis/trac/ticket/181</a>>: "Accept-Language: which RFC4647 filtering?" 2035 2037 </li> … … 2239 2241 </li> 2240 2242 <li class="indline1"><em>RFC2277</em> <a class="iref" href="#rfc.xref.RFC2277.1">2.1</a>, <a class="iref" href="#RFC2277"><b>9.2</b></a></li> 2243 <li class="indline1"><em>RFC2295</em> <a class="iref" href="#rfc.xref.RFC2295.1">4</a>, <a class="iref" href="#RFC2295"><b>9.2</b></a></li> 2241 2244 <li class="indline1"><em>RFC2388</em> <a class="iref" href="#rfc.xref.RFC2388.1">2.3.2</a>, <a class="iref" href="#RFC2388"><b>9.2</b></a></li> 2242 2245 <li class="indline1"><em>RFC2557</em> <a class="iref" href="#RFC2557"><b>9.2</b></a>, <a class="iref" href="#rfc.xref.RFC2557.1">A.7</a>, <a class="iref" href="#rfc.xref.RFC2557.2">C.1</a></li> -
draft-ietf-httpbis/latest/p3-payload.xml
r741 r745 807 807 <section title="Content Negotiation" anchor="content.negotiation"> 808 808 <t> 809 Most HTTP responses include an entity which contains information for 810 interpretation by a human user. Naturally, it is desirable to supply 811 the user with the "best available" entity corresponding to the 812 request. Unfortunately for servers and caches, not all users have the 813 same preferences for what is "best," and not all user agents are 814 equally capable of rendering all entity types. For that reason, HTTP 815 has provisions for several mechanisms for "content negotiation" -- 816 the process of selecting the best representation for a given response 817 when there are multiple representations available. 818 </t> 819 <x:note> 820 <t> 821 <x:h>Note:</x:h> This is not called "format negotiation" because the 822 alternate representations may be of the same media type, but use 823 different capabilities of that type, be in different languages, 824 etc. 825 </t> 826 </x:note> 827 <t> 828 Any response containing an entity-body &MAY; be subject to negotiation, 829 including error responses. 830 </t> 831 <t> 832 There are two kinds of content negotiation which are possible in 833 HTTP: server-driven and agent-driven negotiation. These two kinds of 834 negotiation are orthogonal and thus may be used separately or in 835 combination. One method of combination, referred to as transparent 836 negotiation, occurs when a cache uses the agent-driven negotiation 837 information provided by the origin server in order to provide 838 server-driven negotiation for subsequent requests. 809 HTTP responses include a representation which contains information for 810 interpretation, whether by a human user or for further processing. 811 Often, the server has different ways of representing the 812 same information; for example, in different formats, languages, 813 or using different character encodings. 814 </t> 815 <t> 816 HTTP clients and their users might have different or variable 817 capabilities, characteristics or preferences which would influence 818 which representation, among those available from the server, 819 would be best for the server to deliver. For this reason, HTTP 820 provides mechanisms for "content negotiation" -- a process of 821 allowing selection of a representation of a given resource, 822 when more than one is available. 823 </t> 824 <t> 825 This specification defines two patterns of content negotiation; 826 "server-driven", where the server selects the representation based 827 upon the client's stated preferences, and "agent-driven" negotiation, 828 where the server provides a list of representations for the client to 829 choose from, based upon their metadata. In addition, there are 830 other patterns: some applications use an "active content" pattern, 831 where the server returns active content which runs on the client 832 and, based on client available parameters, selects additional 833 resources to invoke. "Transparent Content Negotiation" (<xref target="RFC2295"/>) 834 has also been proposed. 835 </t> 836 <t> 837 These patterns are all widely used, and have trade-offs in applicability 838 and practicality. In particular, when the number of preferences or 839 capabilities to be expressed by a client are large (such as when many 840 different formats are supported by a user-agent), server-driven 841 negotiation becomes unwieldy, and may not be appropriate. Conversely, 842 when the number of representations to choose from is very large, 843 agent-driven negotiation may not be appropriate. 844 </t> 845 <t> 846 Note that in all cases, the supplier of representations has the 847 responsibility for determining which representations might be 848 considered to be the "same information". 839 849 </t> 840 850 … … 891 901 capabilities and user preferences: Accept (<xref target="header.accept"/>), Accept-Charset 892 902 (<xref target="header.accept-charset"/>), Accept-Encoding (<xref target="header.accept-encoding"/>), Accept-Language 893 (<xref target="header.accept-language"/>), and User-Agent (&header-user-agent;). However, an894 origin server is not limited to these dimensions and &MAY; vary the895 response based on any aspect of the request, including information903 (<xref target="header.accept-language"/>), and User-Agent (&header-user-agent;). 904 However, an origin server is not limited to these dimensions and &MAY; vary 905 the response based on any aspect of the request, including information 896 906 outside the request-header fields or within extension header fields 897 907 not defined by this specification. 898 908 </t> 909 <x:note> 910 <t> 911 <x:h>Note:</x:h> In practice, User-Agent based negotiation is fragile, 912 because new clients might not be recognized. 913 </t> 914 </x:note> 899 915 <t> 900 916 The Vary header field (&header-vary;) can be used to express the parameters the … … 933 949 </t> 934 950 <t> 935 HTTP/1.1defines the 300 (Multiple Choices) and 406 (Not Acceptable)951 This specification defines the 300 (Multiple Choices) and 406 (Not Acceptable) 936 952 status codes for enabling agent-driven negotiation when the server is 937 953 unwilling or unable to provide a varying response using server-driven 938 954 negotiation. 939 </t>940 </section>941 942 <section title="Transparent Negotiation" anchor="transparent.negotiation">943 <t>944 Transparent negotiation is a combination of both server-driven and945 agent-driven negotiation. When a cache is supplied with a form of the946 list of available representations of the response (as in agent-driven947 negotiation) and the dimensions of variance are completely understood948 by the cache, then the cache becomes capable of performing server-driven949 negotiation on behalf of the origin server for subsequent950 requests on that resource.951 </t>952 <t>953 Transparent negotiation has the advantage of distributing the954 negotiation work that would otherwise be required of the origin955 server and also removing the second request delay of agent-driven956 negotiation when the cache is able to correctly guess the right957 response.958 </t>959 <t>960 This specification does not define any mechanism for transparent961 negotiation, though it also does not prevent any such mechanism from962 being developed as an extension that could be used within HTTP/1.1.963 955 </t> 964 956 </section> … … 2283 2275 </reference> 2284 2276 2277 <reference anchor='RFC2295'> 2278 <front> 2279 <title abbrev='HTTP Content Negotiation'>Transparent Content Negotiation in HTTP</title> 2280 <author initials='K.' surname='Holtman' fullname='Koen Holtman'> 2281 <organization>Technische Universiteit Eindhoven</organization> 2282 <address> 2283 <email>koen@win.tue.nl</email> 2284 </address> 2285 </author> 2286 <author initials='A.H.' surname='Mutz' fullname='Andrew H. Mutz'> 2287 <organization>Hewlett-Packard Company</organization> 2288 <address> 2289 <email>mutz@hpl.hp.com</email> 2290 </address> 2291 </author> 2292 <date year='1998' month='March'/> 2293 </front> 2294 <seriesInfo name='RFC' value='2295'/> 2295 </reference> 2296 2285 2297 <reference anchor="RFC2388"> 2286 2298 <front> … … 3079 3091 <list style="symbols"> 3080 3092 <t> 3093 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/81"/>: 3094 "Content Negotiation for media types" 3095 </t> 3096 <t> 3081 3097 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/181"/>: 3082 3098 "Accept-Language: which RFC4647 filtering?"
Note: See TracChangeset
for help on using the changeset viewer.