Changeset 2291 for draft-ietf-httpbis/latest
- Timestamp:
- 12/06/13 08:26:28 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r2288 r2291 449 449 } 450 450 @bottom-center { 451 content: "Expires December 1 1, 2013";451 content: "Expires December 14, 2013"; 452 452 } 453 453 @bottom-right { … … 494 494 <meta name="dct.creator" content="Reschke, J. F."> 495 495 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest"> 496 <meta name="dct.issued" scheme="ISO8601" content="2013-06- 09">496 <meta name="dct.issued" scheme="ISO8601" content="2013-06-12"> 497 497 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 498 498 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation."> … … 522 522 <tr> 523 523 <td class="left">Intended status: Standards Track</td> 524 <td class="right">June 9, 2013</td>524 <td class="right">June 12, 2013</td> 525 525 </tr> 526 526 <tr> 527 <td class="left">Expires: December 1 1, 2013</td>527 <td class="left">Expires: December 14, 2013</td> 528 528 <td class="right"></td> 529 529 </tr> … … 553 553 in progress”. 554 554 </p> 555 <p>This Internet-Draft will expire on December 1 1, 2013.</p>555 <p>This Internet-Draft will expire on December 14, 2013.</p> 556 556 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 557 557 <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 1872 1872 quality". 1873 1873 </p> 1874 <p id="rfc.section.5.3.2.p.9">A request without any Accept header field implies that the user agent will accept any media type in response. If an Accept1875 header field is present in a request and none of the available representations for the response have a media type that is1876 listed as acceptable, the origin server <em class="bcp14">MAY</em> either honor the Accept header field by sending a <a href="#status.406" class="smpl">406 (Not Acceptable)</a> response or disregard the Acceptheader field by treating the response as if it is not subject to content negotiation.1874 <p id="rfc.section.5.3.2.p.9">A request without any Accept header field implies that the user agent will accept any media type in response. If the header 1875 field is present in a request and none of the available representations for the response have a media type that is listed 1876 as acceptable, the origin server can either honor the header field by sending a <a href="#status.406" class="smpl">406 (Not Acceptable)</a> response or disregard the header field by treating the response as if it is not subject to content negotiation. 1877 1877 </p> 1878 1878 <p id="rfc.section.5.3.2.p.10">A more elaborate example is</p> … … 1957 1957 </p> 1958 1958 <p id="rfc.section.5.3.3.p.7">If an Accept-Charset header field is present in a request and none of the available representations for the response has a 1959 charset that is listed as acceptable, the origin server <em class="bcp14">MAY</em> either honor the Accept-Charset header field, by sending a <a href="#status.406" class="smpl">406 (Not Acceptable)</a> response, or disregard the Accept-Charsetheader field by treating the resource as if it is not subject to content negotiation.1959 charset that is listed as acceptable, the origin server can either honor the header field, by sending a <a href="#status.406" class="smpl">406 (Not Acceptable)</a> response, or disregard the header field by treating the resource as if it is not subject to content negotiation. 1960 1960 </p> 1961 1961 <div id="rfc.iref.a.3"></div> … … 2012 2012 <div id="rfc.figure.u.33"></div><pre class="text"> Accept-Language: da, en-gb;q=0.8, en;q=0.7 2013 2013 </pre><p id="rfc.section.5.3.5.p.5">would mean: "I prefer Danish, but will accept British English and other types of English".</p> 2014 <p id="rfc.section.5.3.5.p.6">Note that some recipients treat the order in which language tags are listed as an indication of descending priority, particularly 2014 <p id="rfc.section.5.3.5.p.6">A request without any Accept-Language header field implies that the user agent will accept any language in response. If the 2015 header field is present in a request and none of the available representations for the response have a matching language tag, 2016 the origin server can either disregard the header field by treating the response as if it is not subject to content negotiation, 2017 or honor the header field by sending a <a href="#status.406" class="smpl">406 (Not Acceptable)</a> response. However, the latter is not encouraged, as doing so can prevent users from accessing content that they might be able 2018 to use (with translation software, for example). 2019 </p> 2020 <p id="rfc.section.5.3.5.p.7">Note that some recipients treat the order in which language tags are listed as an indication of descending priority, particularly 2015 2021 for tags that are assigned equal quality values (no value is the same as q=1). However, this behavior cannot be relied upon. 2016 2022 For consistency and to maximize interoperability, many user agents assign each language tag a unique quality value while also 2017 2023 listing them in order of decreasing quality. Additional discussion of language priority lists can be found in <a href="http://tools.ietf.org/html/rfc4647#section-2.3">Section 2.3</a> of <a href="#RFC4647" id="rfc.xref.RFC4647.2"><cite title="Matching of Language Tags">[RFC4647]</cite></a>. 2018 2024 </p> 2019 <p id="rfc.section.5.3.5.p. 7">For matching, <a href="http://tools.ietf.org/html/rfc4647#section-3">Section 3</a> of <a href="#RFC4647" id="rfc.xref.RFC4647.3"><cite title="Matching of Language Tags">[RFC4647]</cite></a> defines several matching schemes. Implementations can offer the most appropriate matching scheme for their requirements. The2025 <p id="rfc.section.5.3.5.p.8">For matching, <a href="http://tools.ietf.org/html/rfc4647#section-3">Section 3</a> of <a href="#RFC4647" id="rfc.xref.RFC4647.3"><cite title="Matching of Language Tags">[RFC4647]</cite></a> defines several matching schemes. Implementations can offer the most appropriate matching scheme for their requirements. The 2020 2026 "Basic Filtering" scheme (<a href="#RFC4647" id="rfc.xref.RFC4647.4"><cite title="Matching of Language Tags">[RFC4647]</cite></a>, <a href="http://tools.ietf.org/html/rfc4647#section-3.3.1">Section 3.3.1</a>) is identical to the matching scheme that was previously defined for HTTP in <a href="http://tools.ietf.org/html/rfc2616#section-14.4">Section 14.4</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>. 2021 2027 </p> 2022 <p id="rfc.section.5.3.5.p. 8">It might be contrary to the privacy expectations of the user to send an Accept-Language header field with the complete linguistic2028 <p id="rfc.section.5.3.5.p.9">It might be contrary to the privacy expectations of the user to send an Accept-Language header field with the complete linguistic 2023 2029 preferences of the user in every request (<a href="#fingerprinting" title="Browser Fingerprinting">Section 9.6</a>). 2024 2030 </p> 2025 <p id="rfc.section.5.3.5.p. 9">Since intelligibility is highly dependent on the individual user, user agents need to allow user control over the linguistic2031 <p id="rfc.section.5.3.5.p.10">Since intelligibility is highly dependent on the individual user, user agents need to allow user control over the linguistic 2026 2032 preference. A user agent that does not provide such control to the user <em class="bcp14">MUST NOT</em> send an Accept-Language header field. 2027 2033 </p> 2028 <div class="note" id="rfc.section.5.3.5.p.1 0">2034 <div class="note" id="rfc.section.5.3.5.p.11"> 2029 2035 <p> <b>Note:</b> User agents ought to provide guidance to users when setting a preference, since users are rarely familiar with the details 2030 2036 of language matching as described above. For example, users might assume that on selecting "en-gb", they will be served any … … 4498 4504 <ul> 4499 4505 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/436">http://tools.ietf.org/wg/httpbis/trac/ticket/436</a>>: "explain list expansion in ABNF appendices" 4506 </li> 4507 <li> <<a href="http://trac.tools.ietf.org/wg/httpbis/trac/ticket/448">http://trac.tools.ietf.org/wg/httpbis/trac/ticket/448</a>>: "Fallback for Accept-Language" 4500 4508 </li> 4501 4509 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/449">http://tools.ietf.org/wg/httpbis/trac/ticket/449</a>>: "Receiving a higher minor HTTP version number" -
draft-ietf-httpbis/latest/p2-semantics.xml
r2288 r2291 2127 2127 <t> 2128 2128 A request without any Accept header field implies that the user agent 2129 will accept any media type in response. 2130 If an Accept header field is present in a request and none of the 2131 available representations for the response have a media type that is 2132 listed as acceptable, the origin server &MAY; either honor the Accept 2133 header field by sending a <x:ref>406 (Not Acceptable)</x:ref> response 2134 or disregard the Accept header field by treating the response as if 2135 it is not subject to content negotiation. 2129 will accept any media type in response. If the header field is present in a 2130 request and none of the available representations for the response have a 2131 media type that is listed as acceptable, the origin server can either honor 2132 the header field by sending a <x:ref>406 (Not Acceptable)</x:ref> response 2133 or disregard the header field by treating the response as if it is not 2134 subject to content negotiation. 2136 2135 </t> 2137 2136 <t> … … 2225 2224 <t> 2226 2225 A request without any Accept-Charset header field implies that the user 2227 agent will accept any charset in response. 2228 Most general-purpose user agents do not send Accept-Charset, unless2229 specifically configured to do so, because a detailed list of supported2230 charsets makes it easier for a server to identify an individual by virtue2231 of the user agent's request characteristics(<xref target="fingerprinting"/>).2226 agent will accept any charset in response. Most general-purpose user agents 2227 do not send Accept-Charset, unless specifically configured to do so, because 2228 a detailed list of supported charsets makes it easier for a server to 2229 identify an individual by virtue of the user agent's request characteristics 2230 (<xref target="fingerprinting"/>). 2232 2231 </t> 2233 2232 <t> 2234 2233 If an Accept-Charset header field is present in a request and none of the 2235 2234 available representations for the response has a charset that is listed as 2236 acceptable, the origin server &MAY; either honor the Accept-Charset header 2237 field, by sending a <x:ref>406 (Not Acceptable)</x:ref> response, or 2238 disregard the Accept-Charset header field by treating the resource as if 2239 it is not subject to content negotiation. 2235 acceptable, the origin server can either honor the header field, by sending a 2236 <x:ref>406 (Not Acceptable)</x:ref> response, or disregard the header field by 2237 treating the resource as if it is not subject to content negotiation. 2240 2238 </t> 2241 2239 </section> … … 2340 2338 would mean: "I prefer Danish, but will accept British English and 2341 2339 other types of English". 2340 </t> 2341 <t> 2342 A request without any Accept-Language header field implies that the user 2343 agent will accept any language in response. If the header field is present 2344 in a request and none of the available representations for the response have 2345 a matching language tag, the origin server can either disregard the header 2346 field by treating the response as if it is not subject to content 2347 negotiation, or honor the header field by sending a <x:ref>406 (Not Acceptable)</x:ref> 2348 response. However, the latter is not encouraged, as doing so can prevent 2349 users from accessing content that they might be able to use (with 2350 translation software, for example). 2342 2351 </t> 2343 2352 <t> … … 6344 6353 </t> 6345 6354 <t> 6355 <eref target="http://trac.tools.ietf.org/wg/httpbis/trac/ticket/448"/>: 6356 "Fallback for Accept-Language" 6357 </t> 6358 <t> 6346 6359 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/449"/>: 6347 6360 "Receiving a higher minor HTTP version number"
Note: See TracChangeset
for help on using the changeset viewer.