Changeset 2291


Ignore:
Timestamp:
Jun 12, 2013, 1:26:28 AM (6 years ago)
Author:
julian.reschke@…
Message:

Add fallback discussion for Accept-Language (see #448). Also tune the statements for other Accept-* header fields (MAY->can).

Location:
draft-ietf-httpbis/latest
Files:
2 edited

Legend:

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

    r2288 r2291  
    449449  }
    450450  @bottom-center {
    451        content: "Expires December 11, 2013";
     451       content: "Expires December 14, 2013";
    452452  }
    453453  @bottom-right {
     
    494494      <meta name="dct.creator" content="Reschke, J. F.">
    495495      <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">
    497497      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    498498      <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.">
     
    522522            <tr>
    523523               <td class="left">Intended status: Standards Track</td>
    524                <td class="right">June 9, 2013</td>
     524               <td class="right">June 12, 2013</td>
    525525            </tr>
    526526            <tr>
    527                <td class="left">Expires: December 11, 2013</td>
     527               <td class="left">Expires: December 14, 2013</td>
    528528               <td class="right"></td>
    529529            </tr>
     
    553553         in progress”.
    554554      </p>
    555       <p>This Internet-Draft will expire on December 11, 2013.</p>
     555      <p>This Internet-Draft will expire on December 14, 2013.</p>
    556556      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    557557      <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    18721872         quality".
    18731873      </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 Accept
    1875          header field is present in a request and none of the available representations for the response have a media type that is
    1876          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 Accept header 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.
    18771877      </p>
    18781878      <p id="rfc.section.5.3.2.p.10">A more elaborate example is</p>
     
    19571957      </p>
    19581958      <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-Charset header 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.
    19601960      </p>
    19611961      <div id="rfc.iref.a.3"></div>
     
    20122012      <div id="rfc.figure.u.33"></div><pre class="text">  Accept-Language: da, en-gb;q=0.8, en;q=0.7
    20132013</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
    20152021         for tags that are assigned equal quality values (no value is the same as q=1). However, this behavior cannot be relied upon.
    20162022         For consistency and to maximize interoperability, many user agents assign each language tag a unique quality value while also
    20172023         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>.
    20182024      </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. The
     2025      <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
    20202026         "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>.
    20212027      </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 linguistic
     2028      <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
    20232029         preferences of the user in every request (<a href="#fingerprinting" title="Browser Fingerprinting">Section&nbsp;9.6</a>).
    20242030      </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 linguistic
     2031      <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
    20262032         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.
    20272033      </p>
    2028       <div class="note" id="rfc.section.5.3.5.p.10">
     2034      <div class="note" id="rfc.section.5.3.5.p.11">
    20292035         <p> <b>Note:</b> User agents ought to provide guidance to users when setting a preference, since users are rarely familiar with the details
    20302036            of language matching as described above. For example, users might assume that on selecting "en-gb", they will be served any
     
    44984504      <ul>
    44994505         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/436">http://tools.ietf.org/wg/httpbis/trac/ticket/436</a>&gt;: "explain list expansion in ABNF appendices"
     4506         </li>
     4507         <li> &lt;<a href="http://trac.tools.ietf.org/wg/httpbis/trac/ticket/448">http://trac.tools.ietf.org/wg/httpbis/trac/ticket/448</a>&gt;: "Fallback for Accept-Language"
    45004508         </li>
    45014509         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/449">http://tools.ietf.org/wg/httpbis/trac/ticket/449</a>&gt;: "Receiving a higher minor HTTP version number"
  • draft-ietf-httpbis/latest/p2-semantics.xml

    r2288 r2291  
    21272127<t>
    21282128   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.
    21362135</t>
    21372136<t>
     
    22252224<t>
    22262225   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, unless
    2229    specifically configured to do so, because a detailed list of supported
    2230    charsets makes it easier for a server to identify an individual by virtue
    2231    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"/>).
    22322231</t>
    22332232<t>
    22342233   If an Accept-Charset header field is present in a request and none of the
    22352234   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.
    22402238</t>
    22412239</section>
     
    23402338   would mean: "I prefer Danish, but will accept British English and
    23412339   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).
    23422351</t>
    23432352<t>
     
    63446353    </t>
    63456354    <t>
     6355      <eref target="http://trac.tools.ietf.org/wg/httpbis/trac/ticket/448"/>:
     6356      "Fallback for Accept-Language"
     6357    </t>
     6358    <t>
    63466359      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/449"/>:
    63476360      "Receiving a higher minor HTTP version number"
Note: See TracChangeset for help on using the changeset viewer.