Changeset 2084 for draft-ietf-httpbis/latest
- Timestamp:
- 05/01/13 08:21:45 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r2083 r2084 449 449 } 450 450 @bottom-center { 451 content: "Expires July 8, 2013";451 content: "Expires July 9, 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-01-0 4">496 <meta name="dct.issued" scheme="ISO8601" content="2013-01-05"> 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">January 4, 2013</td>524 <td class="right">January 5, 2013</td> 525 525 </tr> 526 526 <tr> 527 <td class="left">Expires: July 8, 2013</td>527 <td class="left">Expires: July 9, 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 July 8, 2013.</p>555 <p>This Internet-Draft will expire on July 9, 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> … … 1931 1931 <div id="rfc.figure.u.30"></div><pre class="inline"><span id="rfc.iref.g.30"></span><span id="rfc.iref.g.31"></span> <a href="#header.accept-encoding" class="smpl">Accept-Encoding</a> = #( <a href="#header.accept-encoding" class="smpl">codings</a> [ <a href="#quality.values" class="smpl">weight</a> ] ) 1932 1932 <a href="#header.accept-encoding" class="smpl">codings</a> = <a href="#content.codings" class="smpl">content-coding</a> / "identity" / "*" 1933 </pre><p id="rfc.section.5.3.4.p.3">Each codings value <em class="bcp14">MAY</em> be given an associated quality value representing the preference for that encoding, as defined in <a href="#quality.values" title="Quality Values">Section 5.3.1</a>. 1933 </pre><p id="rfc.section.5.3.4.p.3">Each codings value <em class="bcp14">MAY</em> be given an associated quality value representing the preference for that encoding, as defined in <a href="#quality.values" title="Quality Values">Section 5.3.1</a>. The asterisk "*" symbol in an Accept-Encoding field matches any available content-coding not explicitly listed in the header 1934 field. 1934 1935 </p> 1935 1936 <p id="rfc.section.5.3.4.p.4">For example,</p> … … 1939 1940 Accept-Encoding: compress;q=0.5, gzip;q=1.0 1940 1941 Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0 1941 </pre><p id="rfc.section.5.3.4.p.6">A server tests whether a content-coding for a given representation is acceptable, according to an Accept-Encoding field, using 1942 these rules: 1943 </p> 1942 </pre><p id="rfc.section.5.3.4.p.6">A request without an Accept-Encoding header field implies that the user agent has no preferences regarding content-codings. 1943 Although this allows the server to use any content-coding in a response, it does not imply that the user agent will be able 1944 to correctly process all encodings. 1945 </p> 1946 <p id="rfc.section.5.3.4.p.7">A server tests whether a content-coding for a given representation is acceptable using these rules: </p> 1944 1947 <ol> 1945 <li>The special "*" symbol in an Accept-Encoding field matches any available content-coding not explicitly listed in the header 1946 field. 1947 </li> 1948 <li>If no Accept-Encoding field is in the request, any content-coding is considered acceptable by the user agent.</li> 1948 1949 <li>If the representation has no content-coding, then it is acceptable by default unless specifically excluded by the Accept-Encoding 1949 1950 field stating either "identity;q=0" or "*;q=0" without a more specific entry for "identity". … … 1954 1955 <li>If multiple content-codings are acceptable, then the acceptable content-coding with the highest non-zero qvalue is preferred.</li> 1955 1956 </ol> 1956 <p id="rfc.section.5.3.4.p. 7">An Accept-Encoding header field with a combined field-value that is empty implies that the user agent does not want any content-coding1957 <p id="rfc.section.5.3.4.p.8">An Accept-Encoding header field with a combined field-value that is empty implies that the user agent does not want any content-coding 1957 1958 in response. If an Accept-Encoding header field is present in a request and none of the available representations for the 1958 1959 response have a content-coding that is listed as acceptable, the origin server <em class="bcp14">SHOULD</em> send a response without any content-coding. 1959 1960 </p> 1960 <p id="rfc.section.5.3.4.p.8">A request without an Accept-Encoding header field implies that the user agent will accept any content-coding in response.</p>1961 1961 <div class="note" id="rfc.section.5.3.4.p.9"> 1962 <p> <b>Note:</b> Most HTTP/1.0 applications do not recognize or obey qvalues associated with content-codings. This means that qvalues will1962 <p> <b>Note:</b> Most HTTP/1.0 applications do not recognize or obey qvalues associated with content-codings. This means that qvalues might 1963 1963 not work and are not permitted with x-gzip or x-compress. 1964 1964 </p> -
draft-ietf-httpbis/latest/p2-semantics.xml
r2083 r2084 2195 2195 Each codings value &MAY; be given an associated quality value 2196 2196 representing the preference for that encoding, as defined in &qvalue;. 2197 The asterisk "*" symbol in an Accept-Encoding field matches any available 2198 content-coding not explicitly listed in the header field. 2197 2199 </t> 2198 2200 <t> … … 2207 2209 </artwork></figure> 2208 2210 <t> 2211 A request without an Accept-Encoding header field implies that the user 2212 agent has no preferences regarding content-codings. Although this allows 2213 the server to use any content-coding in a response, it does not imply that 2214 the user agent will be able to correctly process all encodings. 2215 </t> 2216 <t> 2209 2217 A server tests whether a content-coding for a given representation is 2210 acceptable , according to an Accept-Encoding field,using these rules:2218 acceptable using these rules: 2211 2219 <list style="numbers"> 2212 <t>The special "*" symbol in an Accept-Encoding field matches any 2213 available content-coding not explicitly listed in the header 2214 field.</t> 2220 <t>If no Accept-Encoding field is in the request, any content-coding is 2221 considered acceptable by the user agent.</t> 2215 2222 2216 2223 <t>If the representation has no content-coding, then it is acceptable … … 2236 2243 without any content-coding. 2237 2244 </t> 2238 <t>2239 A request without an Accept-Encoding header field implies that the user2240 agent will accept any content-coding in response.2241 </t>2242 2245 <x:note> 2243 2246 <t> 2244 2247 &Note; Most HTTP/1.0 applications do not recognize or obey qvalues 2245 associated with content-codings. This means that qvalues willnot2248 associated with content-codings. This means that qvalues might not 2246 2249 work and are not permitted with x-gzip or x-compress. 2247 2250 </t>
Note: See TracChangeset
for help on using the changeset viewer.