Source: https://trac.ietf.org/trac/httpbis/changeset/561/draft-ietf-httpbis/latest
Timestamp: 2020-02-22 19:30:28
Document Index: 615166615

Matched Legal Cases: ['art 1', 'art1', 'art1', 'art 1', 'art1', 'art1', 'art1', 'art 1', 'art1', 'art1', 'art1', 'art 1', 'art1', 'art3', 'art3', 'art 3', 'art3', 'art5', 'art5', 'art 5', 'art5', 'art1', 'art1', 'art 1', 'art1', 'art3', 'art3', 'art 3', 'art3', 'art5', 'art5', 'art 5', 'art5']

Changeset 561 for draft-ietf-httpbis/latest – Hypertext Transfer Protocol Wiki
Changeset 561 for draft-ietf-httpbis/latest
12/03/09 12:14:29 (11 years ago)
Expand the comment about Request-URI not being defined anymore in Part 1.
p6-cache.html (modified) (14 diffs)
<li>The presented Request-URI and that of the stored response match (see <span class="comment" id="rfc.comment.1">[<a href="#rfc.comment.1" class="smpl">rfc.comment.1</a>: TBD]</span>), and
<p id="rfc.section.2.2.p.2"> <span class="comment" id="rfc.comment.2">[<a href="#rfc.comment.2" class="smpl">rfc.comment.2</a>: TODO: define method cacheability for GET, HEAD and POST in p2-semantics.]</span>
<p id="rfc.section.2.2.p.3">When a stored response is used to satisfy a request, caches <em class="bcp14">MUST</em> include a single Age header field <a href="#header.age" id="rfc.xref.header.age.1" title="Age">Section&nbsp;3.1</a> in the response with a value equal to the stored response's current_age; see <a href="#age.calculations" title="Calculating Age">Section&nbsp;2.3.2</a>. <span class="comment" id="rfc.comment.3">[<a href="#rfc.comment.3" class="smpl">rfc.comment.3</a>: DISCUSS: this currently includes successfully validated responses.]</span>
<p id="rfc.section.2.2.p.2"> <span class="comment" id="rfc.comment.1">[<a href="#rfc.comment.1" class="smpl">rfc.comment.1</a>: TODO: define method cacheability for GET, HEAD and POST in p2-semantics.]</span>
<p id="rfc.section.2.2.p.3">When a stored response is used to satisfy a request, caches <em class="bcp14">MUST</em> include a single Age header field <a href="#header.age" id="rfc.xref.header.age.1" title="Age">Section&nbsp;3.1</a> in the response with a value equal to the stored response's current_age; see <a href="#age.calculations" title="Calculating Age">Section&nbsp;2.3.2</a>. <span class="comment" id="rfc.comment.2">[<a href="#rfc.comment.2" class="smpl">rfc.comment.2</a>: DISCUSS: this currently includes successfully validated responses.]</span>
<p id="rfc.section.2.2.p.7"> <span class="comment" id="rfc.comment.4">[<a href="#rfc.comment.4" class="smpl">rfc.comment.4</a>: TODO: end-to-end and hop-by-hop headers, non-modifiable headers removed; re-spec in p1]</span>
<p id="rfc.section.2.2.p.7"> <span class="comment" id="rfc.comment.3">[<a href="#rfc.comment.3" class="smpl">rfc.comment.3</a>: TODO: end-to-end and hop-by-hop headers, non-modifiable headers removed; re-spec in p1]</span>
This means that the response is always stale, so that caches should validate it before using it for subsequent requests. <span class="comment" id="rfc.comment.5">[<a href="#rfc.comment.5" class="smpl">rfc.comment.5</a>: This wording may cause confusion, because the response may still be served stale.]</span>
This means that the response is always stale, so that caches should validate it before using it for subsequent requests. <span class="comment" id="rfc.comment.4">[<a href="#rfc.comment.4" class="smpl">rfc.comment.4</a>: This wording may cause confusion, because the response may still be served stale.]</span>
<p id="rfc.section.2.3.p.8"> <span class="comment" id="rfc.comment.6">[<a href="#rfc.comment.6" class="smpl">rfc.comment.6</a>: ISSUE: there are not requirements directly applying to cache-request-directives and freshness.]</span>
<p id="rfc.section.2.3.p.8"> <span class="comment" id="rfc.comment.5">[<a href="#rfc.comment.5" class="smpl">rfc.comment.5</a>: ISSUE: there are not requirements directly applying to cache-request-directives and freshness.]</span>
<p id="rfc.section.2.3.1.1.p.4"> <span class="comment" id="rfc.comment.7">[<a href="#rfc.comment.7" class="smpl">rfc.comment.7</a>: REVIEW: took away HTTP/1.0 query string heuristic uncacheability.]</span>
<p id="rfc.section.2.3.1.1.p.4"> <span class="comment" id="rfc.comment.6">[<a href="#rfc.comment.6" class="smpl">rfc.comment.6</a>: REVIEW: took away HTTP/1.0 query string heuristic uncacheability.]</span>
the stored response. <span class="comment" id="rfc.comment.8">[<a href="#rfc.comment.8" class="smpl">rfc.comment.8</a>: Should there be a requirement here?]</span>
the stored response. <span class="comment" id="rfc.comment.7">[<a href="#rfc.comment.7" class="smpl">rfc.comment.7</a>: Should there be a requirement here?]</span>
<p id="rfc.section.2.5.p.4"> <span class="comment" id="rfc.comment.9">[<a href="#rfc.comment.9" class="smpl">rfc.comment.9</a>: TODO: "host part" needs to be specified better.]</span>
<p id="rfc.section.2.5.p.4"> <span class="comment" id="rfc.comment.8">[<a href="#rfc.comment.8" class="smpl">rfc.comment.8</a>: TODO: "host part" needs to be specified better.]</span>
<p id="rfc.section.2.5.p.8"> <span class="comment" id="rfc.comment.10">[<a href="#rfc.comment.10" class="smpl">rfc.comment.10</a>: TODO: specify that only successful (2xx, 3xx?) responses invalidate.]</span>
<p id="rfc.section.2.5.p.8"> <span class="comment" id="rfc.comment.9">[<a href="#rfc.comment.9" class="smpl">rfc.comment.9</a>: TODO: specify that only successful (2xx, 3xx?) responses invalidate.]</span>
request can be transformed to the selecting request-headers in the second request by adding or removing linear white space <span class="comment" id="rfc.comment.11">[<a href="#rfc.comment.11" class="smpl">rfc.comment.11</a>: [ref]]</span> at places where this is allowed by the corresponding ABNF, and/or combining multiple message-header fields with the same field
name following the rules about message headers in <a href="p1-messaging.html#message.headers" title="Message Headers">Section 4.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>. <span class="comment" id="rfc.comment.12">[<a href="#rfc.comment.12" class="smpl">rfc.comment.12</a>: DISCUSS: header-specific canonicalisation]</span>
request can be transformed to the selecting request-headers in the second request by adding or removing linear white space <span class="comment" id="rfc.comment.10">[<a href="#rfc.comment.10" class="smpl">rfc.comment.10</a>: [ref]]</span> at places where this is allowed by the corresponding ABNF, and/or combining multiple message-header fields with the same field
name following the rules about message headers in <a href="p1-messaging.html#message.headers" title="Message Headers">Section 4.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>. <span class="comment" id="rfc.comment.11">[<a href="#rfc.comment.11" class="smpl">rfc.comment.11</a>: DISCUSS: header-specific canonicalisation]</span>
of the existing response, the existing response <em class="bcp14">SHOULD NOT</em> be returned in response to future requests and <em class="bcp14">SHOULD</em> be deleted from the cache.<span class="comment" id="rfc.comment.13">[<a href="#rfc.comment.13" class="smpl">rfc.comment.13</a>: DISCUSS: Not sure if this is necessary.]</span>
of the existing response, the existing response <em class="bcp14">SHOULD NOT</em> be returned in response to future requests and <em class="bcp14">SHOULD</em> be deleted from the cache.<span class="comment" id="rfc.comment.12">[<a href="#rfc.comment.12" class="smpl">rfc.comment.12</a>: DISCUSS: Not sure if this is necessary.]</span>
<p id="rfc.section.2.7.p.5"> <span class="comment" id="rfc.comment.14">[<a href="#rfc.comment.14" class="smpl">rfc.comment.14</a>: ISSUE: discuss how to handle HEAD updates]</span>
<p id="rfc.section.2.7.p.5"> <span class="comment" id="rfc.comment.13">[<a href="#rfc.comment.13" class="smpl">rfc.comment.13</a>: ISSUE: discuss how to handle HEAD updates]</span>
a stale response of any age. <span class="comment" id="rfc.comment.15">[<a href="#rfc.comment.15" class="smpl">rfc.comment.15</a>: of any staleness? --mnot]</span></dd>
computed. (see also <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a> and <a href="#Part5" id="rfc.xref.Part5.4"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>) <span class="comment" id="rfc.comment.16">[<a href="#rfc.comment.16" class="smpl">rfc.comment.16</a>: This used to refer to the text about non-modifiable headers, and will have to be updated later on. --jre]</span>
<p id="rfc.section.A.1.p.3">Proxies should be able to add Content-Length when appropriate. <span class="comment" id="rfc.comment.17">[<a href="#rfc.comment.17" class="smpl">rfc.comment.17</a>: This used to refer to the text about non-modifiable headers, and will have to be updated later on. --jre]</span>
computed. (see also <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a> and <a href="#Part5" id="rfc.xref.Part5.4"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>) <span class="comment" id="rfc.comment.15">[<a href="#rfc.comment.15" class="smpl">rfc.comment.15</a>: This used to refer to the text about non-modifiable headers, and will have to be updated later on. --jre]</span>