Source: http://trac.tools.ietf.org/wg/httpbis/trac/changeset/771
Timestamp: 2016-02-12 07:42:20
Document Index: 177312457

Matched Legal Cases: ['art 6', 'art 6', 'art1', 'art1', 'art 1', 'art1', 'art1', 'art1', 'art 1', 'art1']

Changeset 771 – httpbis
2010-03-05 02:05:58
402402 <meta name="dct.creator" content="Reschke, J. F."> 403403 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest"> 404 <meta name="dct.issued" scheme="ISO8601" content="2010-03-04"> 404 <meta name="dct.issued" scheme="ISO8601" content="2010-03-05"> 405405 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 406406 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. This document is Part 6 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 6 defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages."> …
428428 </tr> 429429 <tr> 430 <td class="left">Expires: September 5, 2010</td> 430 <td class="left">Expires: September 6, 2010</td> 431431 <td class="right">J. Mogul</td> 432432 </tr> …
489489 <tr> 490490 <td class="left"></td> 491 <td class="right">March 4, 2010</td> 491 <td class="right">March 5, 2010</td> 492492 </tr> 493493 </tbody> …
519519 <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>. 520520 </p> 521 <p>This Internet-Draft will expire in September 5, 2010.</p> 521 <p>This Internet-Draft will expire in September 6, 2010.</p> 522522 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 523523 <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p> …
952952 (i.e., that associated with the stored response), and the presented request. 953953 </p> 954 <p id="rfc.section.2.6.p.2">The selecting request-headers from two requests are defined to match if and only if the selecting request-headers in the first 955 request can be transformed to the selecting request-headers in the second request by adding or removing linear white space <span class="comment" id="TODO-missing-ref">[<a href="#TODO-missing-ref" class="smpl">TODO-missing-ref</a>: [ref]]</span> at places where this is allowed by the corresponding ABNF, and/or combining multiple message-header fields with the same field 956 name following the rules about header fields in <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. 957 </p> 958 <p id="rfc.section.2.6.p.3">If a header field is absent from a request, it can only match another request if it is also absent there.</p> 954 <p id="rfc.section.2.6.p.2">The selecting request-headers from two requests are defined to match if and only if those in the first request can be transformed 955 to those in the second request by applying any of the following: 956 </p> 957 <ul> 958 <li>adding or removing whitespace, where allowed in the header's syntax</li> 959 <li>combining multiple message-header fields with the same field name (see <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) 960 </li> 961 <li>normalizing both header values in a way that is known to have identical semantics, according to the header's specification 962 (e.g., re-ordering field values when order is not significant; case-normalization, where values are defined to be case-insensitive) 963 </li> 964 </ul> 965 <p id="rfc.section.2.6.p.3">If (after any normalisation that may take place) a header field is absent from a request, it can only match another request 966 if it is also absent there. 967 </p> 959968 <p id="rfc.section.2.6.p.4">A Vary header field-value of "*" always fails to match, and subsequent requests to that resource can only be properly interpreted 960969 by the origin server. …
17351744 <p id="rfc.section.C.10.p.1">Closed issues: </p> 17361745 <ul> 1746 <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/147">http://tools.ietf.org/wg/httpbis/trac/ticket/147</a>&gt;: "serving negotiated responses from cache: header-specific canonicalization" 1747 </li> 17371748 <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/197">http://tools.ietf.org/wg/httpbis/trac/ticket/197</a>&gt;: "Effect of CC directives on history lists" 17381749 </li> draft-ietf-httpbis/latest/p6-cache.xml
822822</t> 823823<t> 824 The selecting request-headers from two requests are defined to match if and only if the 825 selecting request-headers in the first request can be transformed to the selecting 826 request-headers in the second request by adding or removing linear white space 827 <cref anchor="TODO-missing-ref">[ref]</cref> at places where this is allowed by the corresponding ABNF, and/or 828 combining multiple message-header fields with the same field name following the rules 829 about header fields in &header-fields;. 830 </t> 831 <t> 832 If a header field is absent from a request, it can only match another request 833 if it is also absent there. 824 The selecting request-headers from two requests are defined to match 825 if and only if those in the first request can be transformed to those in the 826 second request by applying any of the following: 827 <list style="symbols"> 828 <t> 829 adding or removing whitespace, where allowed in the header's syntax 830 </t> 831 <t> 832 combining multiple message-header fields with the same field name (see 833 &header-fields;) 834 </t> 835 <t> 836 normalizing both header values in a way that is known to have identical 837 semantics, according to the header's specification (e.g., re-ordering field values 838 when order is not significant; case-normalization, where values are defined to be 839 case-insensitive) 840 </t> 841 </list> 842</t> 843<t> 844 If (after any normalisation that may take place) a header field is absent 845 from a request, it can only match another request if it is also absent there. 834846</t> 835847<t> …
22692281 <list style="symbols"> 22702282 <t> 2283 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/147" />: 2284 "serving negotiated responses from cache: header-specific canonicalization" 2285 </t> 2286 <t> 22712287 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/197" />: 22722288 "Effect of CC directives on history lists" Note: See TracChangeset