Changeset 756 for draft-ietf-httpbis/latest
- Timestamp:
- 02/02/10 12:04:50 (12 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 12 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r754 r756 404 404 <meta name="dct.creator" content="Reschke, J. F."> 405 405 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest"> 406 <meta name="dct.issued" scheme="ISO8601" content="2010-02-0 1">406 <meta name="dct.issued" scheme="ISO8601" content="2010-02-02"> 407 407 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 408 408 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 1 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 1 provides an overview of HTTP and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the generic message syntax and parsing requirements for HTTP message frames, and describes general security concerns for implementations."> … … 435 435 </tr> 436 436 <tr> 437 <td class="left">Expires: August 5, 2010</td>437 <td class="left">Expires: August 6, 2010</td> 438 438 <td class="right">HP</td> 439 439 </tr> … … 488 488 <tr> 489 489 <td class="left"></td> 490 <td class="right">February 1, 2010</td>490 <td class="right">February 2, 2010</td> 491 491 </tr> 492 492 </tbody> … … 520 520 <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>. 521 521 </p> 522 <p>This Internet-Draft will expire in August 5, 2010.</p>522 <p>This Internet-Draft will expire in August 6, 2010.</p> 523 523 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 524 524 <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 1169 1169 </p> 1170 1170 <div class="note" id="rfc.section.3.2.p.7"> 1171 <p> <b>Note:</b> the "Set-Cookie" header as implemented in practice (as opposed to how it is specified in <a href="#RFC2109" id="rfc.xref.RFC2109.1"><cite title="HTTP State Management Mechanism">[RFC2109]</cite></a>) can occur multiple times, but does not use the list syntax, and thus cannot be combined into a single line. (See Appendix1171 <p> <b>Note:</b> The "Set-Cookie" header as implemented in practice (as opposed to how it is specified in <a href="#RFC2109" id="rfc.xref.RFC2109.1"><cite title="HTTP State Management Mechanism">[RFC2109]</cite></a>) can occur multiple times, but does not use the list syntax, and thus cannot be combined into a single line. (See Appendix 1172 1172 A.2.3 of <a href="#Kri2001" id="rfc.xref.Kri2001.1"><cite title="HTTP Cookies: Standards, Privacy, and Politics">[Kri2001]</cite></a> for details.) Also note that the Set-Cookie2 header specified in <a href="#RFC2965" id="rfc.xref.RFC2965.1"><cite title="HTTP State Management Mechanism">[RFC2965]</cite></a> does not share this problem. 1173 1173 </p> -
draft-ietf-httpbis/latest/p1-messaging.xml
r754 r756 1168 1168 <x:note> 1169 1169 <t> 1170 <x:h>Note:</x:h> the "Set-Cookie" header as implemented in1170 <x:h>Note:</x:h> The "Set-Cookie" header as implemented in 1171 1171 practice (as opposed to how it is specified in <xref target="RFC2109"/>) 1172 1172 can occur multiple times, but does not use the list syntax, and thus cannot -
draft-ietf-httpbis/latest/p2-semantics.html
r754 r756 403 403 <meta name="dct.creator" content="Reschke, J. F."> 404 404 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest"> 405 <meta name="dct.issued" scheme="ISO8601" content="2010-02-0 1">405 <meta name="dct.issued" scheme="ISO8601" content="2010-02-02"> 406 406 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 407 407 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 2 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 2 defines the semantics of HTTP messages as expressed by request methods, request-header fields, response status codes, and response-header fields."> … … 434 434 </tr> 435 435 <tr> 436 <td class="left">Expires: August 5, 2010</td>436 <td class="left">Expires: August 6, 2010</td> 437 437 <td class="right">HP</td> 438 438 </tr> … … 487 487 <tr> 488 488 <td class="left"></td> 489 <td class="right">February 1, 2010</td>489 <td class="right">February 2, 2010</td> 490 490 </tr> 491 491 </tbody> … … 518 518 <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>. 519 519 </p> 520 <p>This Internet-Draft will expire in August 5, 2010.</p>520 <p>This Internet-Draft will expire in August 6, 2010.</p> 521 521 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 522 522 <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 1211 1211 </p> 1212 1212 <div class="note" id="rfc.section.8.3.p.2"> 1213 <p> <b>Note:</b> an earlier version of this specification recommended a maximum of five redirections (<a href="#RFC2068" id="rfc.xref.RFC2068.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, <a href="http://tools.ietf.org/html/rfc2068#section-10.3">Section 10.3</a>). Content developers should be aware that there might be clients that implement such a fixed limitation.1213 <p> <b>Note:</b> An earlier version of this specification recommended a maximum of five redirections (<a href="#RFC2068" id="rfc.xref.RFC2068.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, <a href="http://tools.ietf.org/html/rfc2068#section-10.3">Section 10.3</a>). Content developers should be aware that there might be clients that implement such a fixed limitation. 1214 1214 </p> 1215 1215 </div> -
draft-ietf-httpbis/latest/p2-semantics.xml
r754 r756 1287 1287 <x:note> 1288 1288 <t> 1289 <x:h>Note:</x:h> an earlier version of this specification recommended a1289 <x:h>Note:</x:h> An earlier version of this specification recommended a 1290 1290 maximum of five redirections (<xref target="RFC2068" x:fmt="," x:sec="10.3"/>). 1291 1291 Content developers should be aware that there might be clients that -
draft-ietf-httpbis/latest/p3-payload.html
r754 r756 401 401 <meta name="dct.creator" content="Reschke, J. F."> 402 402 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p3-payload-latest"> 403 <meta name="dct.issued" scheme="ISO8601" content="2010-02-0 1">403 <meta name="dct.issued" scheme="ISO8601" content="2010-02-02"> 404 404 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 405 405 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 3 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 3 defines HTTP message content, metadata, and content negotiation."> … … 427 427 </tr> 428 428 <tr> 429 <td class="left">Expires: August 5, 2010</td>429 <td class="left">Expires: August 6, 2010</td> 430 430 <td class="right">J. Mogul</td> 431 431 </tr> … … 484 484 <tr> 485 485 <td class="left"></td> 486 <td class="right">February 1, 2010</td>486 <td class="right">February 2, 2010</td> 487 487 </tr> 488 488 </tbody> … … 514 514 <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>. 515 515 </p> 516 <p>This Internet-Draft will expire in August 5, 2010.</p>516 <p>This Internet-Draft will expire in August 6, 2010.</p> 517 517 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 518 518 <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 1194 1194 </p> 1195 1195 <div class="note" id="rfc.section.5.4.p.7"> 1196 <p> <b>Note:</b> the "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 in <a href="http://tools.ietf.org/html/rfc2616#section-14.4">Section 14.4</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>.1196 <p> <b>Note:</b> The "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 in <a href="http://tools.ietf.org/html/rfc2616#section-14.4">Section 14.4</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>. 1197 1197 </p> 1198 1198 </div> … … 1312 1312 </p> 1313 1313 <div class="note" id="rfc.section.5.8.p.9"> 1314 <p> <b>Note:</b> while the definition of Content-MD5 is exactly the same for HTTP as in RFC 1864 for MIME entity-bodies, there are several1314 <p> <b>Note:</b> While the definition of Content-MD5 is exactly the same for HTTP as in RFC 1864 for MIME entity-bodies, there are several 1315 1315 ways in which the application of Content-MD5 to HTTP entity-bodies differs from its application to MIME entity-bodies. One 1316 1316 is that HTTP, unlike MIME, does not use Content-Transfer-Encoding, and does use Transfer-Encoding and Content-Encoding. Another -
draft-ietf-httpbis/latest/p3-payload.xml
r754 r756 1270 1270 <x:note> 1271 1271 <t> 1272 <x:h>Note:</x:h> the "Basic Filtering" scheme (<xref target="RFC4647"1272 <x:h>Note:</x:h> The "Basic Filtering" scheme (<xref target="RFC4647" 1273 1273 x:fmt="," x:sec="3.3.1"/>) is identical to the matching scheme that was 1274 1274 previously defined in <xref target="RFC2616" x:fmt="of" x:sec="14.4"/>. … … 1517 1517 <x:note> 1518 1518 <t> 1519 <x:h>Note:</x:h> while the definition of Content-MD5 is exactly the same for1519 <x:h>Note:</x:h> While the definition of Content-MD5 is exactly the same for 1520 1520 HTTP as in RFC 1864 for MIME entity-bodies, there are several ways 1521 1521 in which the application of Content-MD5 to HTTP entity-bodies -
draft-ietf-httpbis/latest/p4-conditional.html
r755 r756 400 400 <meta name="dct.creator" content="Reschke, J. F."> 401 401 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-latest"> 402 <meta name="dct.issued" scheme="ISO8601" content="2010-02-0 1">402 <meta name="dct.issued" scheme="ISO8601" content="2010-02-02"> 403 403 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 404 404 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 4 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 4 defines request header fields for indicating conditional requests and the rules for constructing responses to those requests."> … … 426 426 </tr> 427 427 <tr> 428 <td class="left">Expires: August 5, 2010</td>428 <td class="left">Expires: August 6, 2010</td> 429 429 <td class="right">J. Mogul</td> 430 430 </tr> … … 483 483 <tr> 484 484 <td class="left"></td> 485 <td class="right">February 1, 2010</td>485 <td class="right">February 2, 2010</td> 486 486 </tr> 487 487 </tbody> … … 513 513 <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>. 514 514 </p> 515 <p>This Internet-Draft will expire in August 5, 2010.</p>515 <p>This Internet-Draft will expire in August 6, 2010.</p> 516 516 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 517 517 <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 819 819 </p> 820 820 <div class="note" id="rfc.section.5.p.5"> 821 <p> <b>Note:</b> in order to provide semantically transparent caching, an origin server must avoid reusing a specific strong entity tag value821 <p> <b>Note:</b> In order to provide semantically transparent caching, an origin server must avoid reusing a specific strong entity tag value 822 822 for two different entities, or reusing a specific weak entity tag value for two semantically different entities. Cache entries 823 823 might persist for arbitrarily long periods, regardless of expiration times, so it might be inappropriate to expect that a -
draft-ietf-httpbis/latest/p4-conditional.xml
r755 r756 607 607 <x:note> 608 608 <t> 609 <x:h>Note:</x:h> in order to provide semantically transparent caching, an609 <x:h>Note:</x:h> In order to provide semantically transparent caching, an 610 610 origin server must avoid reusing a specific strong entity tag 611 611 value for two different entities, or reusing a specific weak -
draft-ietf-httpbis/latest/p5-range.html
r754 r756 400 400 <meta name="dct.creator" content="Reschke, J. F."> 401 401 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p5-range-latest"> 402 <meta name="dct.issued" scheme="ISO8601" content="2010-02-0 1">402 <meta name="dct.issued" scheme="ISO8601" content="2010-02-02"> 403 403 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 404 404 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 5 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 5 defines range-specific requests and the rules for constructing and combining responses to those requests."> … … 426 426 </tr> 427 427 <tr> 428 <td class="left">Expires: August 5, 2010</td>428 <td class="left">Expires: August 6, 2010</td> 429 429 <td class="right">J. Mogul</td> 430 430 </tr> … … 483 483 <tr> 484 484 <td class="left"></td> 485 <td class="right">February 1, 2010</td>485 <td class="right">February 2, 2010</td> 486 486 </tr> 487 487 </tbody> … … 513 513 <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>. 514 514 </p> 515 <p>This Internet-Draft will expire in August 5, 2010.</p>515 <p>This Internet-Draft will expire in August 6, 2010.</p> 516 516 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 517 517 <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 788 788 </p> 789 789 <div class="note" id="rfc.section.5.2.p.15"> 790 <p> <b>Note:</b> clients cannot depend on servers to send a 416 (Requested range not satisfiable) response instead of a 200 (OK) response for790 <p> <b>Note:</b> Clients cannot depend on servers to send a 416 (Requested range not satisfiable) response instead of a 200 (OK) response for 791 791 an unsatisfiable Range request-header, since not all servers implement this request-header. 792 792 </p> -
draft-ietf-httpbis/latest/p5-range.xml
r754 r756 632 632 <x:note> 633 633 <t> 634 <x:h>Note:</x:h> clients cannot depend on servers to send a 416 (Requested634 <x:h>Note:</x:h> Clients cannot depend on servers to send a 416 (Requested 635 635 range not satisfiable) response instead of a 200 (OK) response for 636 636 an unsatisfiable Range request-header, since not all servers -
draft-ietf-httpbis/latest/p6-cache.html
r754 r756 402 402 <meta name="dct.creator" content="Reschke, J. F."> 403 403 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest"> 404 <meta name="dct.issued" scheme="ISO8601" content="2010-02-0 1">404 <meta name="dct.issued" scheme="ISO8601" content="2010-02-02"> 405 405 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 406 406 <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 "HTTP/1.1" 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."> … … 428 428 </tr> 429 429 <tr> 430 <td class="left">Expires: August 5, 2010</td>430 <td class="left">Expires: August 6, 2010</td> 431 431 <td class="right">J. Mogul</td> 432 432 </tr> … … 489 489 <tr> 490 490 <td class="left"></td> 491 <td class="right">February 1, 2010</td>491 <td class="right">February 2, 2010</td> 492 492 </tr> 493 493 </tbody> … … 519 519 <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>. 520 520 </p> 521 <p>This Internet-Draft will expire in August 5, 2010.</p>521 <p>This Internet-Draft will expire in August 6, 2010.</p> 522 522 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 523 523 <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 1230 1230 <p>For example</p> <pre class="text"> Expires: Thu, 01 Dec 1994 16:00:00 GMT 1231 1231 </pre><div class="note" id="rfc.section.3.3.p.6"> 1232 <p> <b>Note:</b> if a response includes a Cache-Control field with the max-age directive (see <a href="#cache-response-directive" title="Response Cache-Control Directives">Section 3.2.2</a>), that directive overrides the Expires field. Likewise, the s-maxage directive overrides Expires in shared caches.1232 <p> <b>Note:</b> If a response includes a Cache-Control field with the max-age directive (see <a href="#cache-response-directive" title="Response Cache-Control Directives">Section 3.2.2</a>), that directive overrides the Expires field. Likewise, the s-maxage directive overrides Expires in shared caches. 1233 1233 </p> 1234 1234 </div> … … 1252 1252 </p> 1253 1253 <div class="note" id="rfc.section.3.4.p.4"> 1254 <p> <b>Note:</b> because the meaning of "Pragma: no-cache" as a response-header field is not actually specified, it does not provide a reliable1254 <p> <b>Note:</b> Because the meaning of "Pragma: no-cache" as a response-header field is not actually specified, it does not provide a reliable 1255 1255 replacement for "Cache-Control: no-cache" in a response. 1256 1256 </p> … … 1385 1385 <p id="rfc.section.4.p.4">This is not to be construed to prohibit the history mechanism from telling the user that a view might be stale.</p> 1386 1386 <div class="note" id="rfc.section.4.p.5"> 1387 <p> <b>Note:</b> if history list mechanisms unnecessarily prevent users from viewing stale resources, this will tend to force service authors1387 <p> <b>Note:</b> If history list mechanisms unnecessarily prevent users from viewing stale resources, this will tend to force service authors 1388 1388 to avoid using HTTP expiration controls and cache controls when they would otherwise like to. Service authors may consider 1389 1389 it important that users not be presented with error messages or warning messages when they use navigation controls (such as -
draft-ietf-httpbis/latest/p6-cache.xml
r754 r756 1295 1295 <x:note> 1296 1296 <t> 1297 <x:h>Note:</x:h> if a response includes a Cache-Control field with the max-age1297 <x:h>Note:</x:h> If a response includes a Cache-Control field with the max-age 1298 1298 directive (see <xref target="cache-response-directive" />), that directive overrides 1299 1299 the Expires field. Likewise, the s-maxage directive overrides Expires in shared caches. … … 1339 1339 <x:note> 1340 1340 <t> 1341 <x:h>Note:</x:h> because the meaning of "Pragma: no-cache" as a response-header field1341 <x:h>Note:</x:h> Because the meaning of "Pragma: no-cache" as a response-header field 1342 1342 is not actually specified, it does not provide a reliable replacement for 1343 1343 "Cache-Control: no-cache" in a response. … … 1561 1561 <x:note> 1562 1562 <t> 1563 <x:h>Note:</x:h> if history list mechanisms unnecessarily prevent users from viewing1563 <x:h>Note:</x:h> If history list mechanisms unnecessarily prevent users from viewing 1564 1564 stale resources, this will tend to force service authors to avoid using HTTP expiration 1565 1565 controls and cache controls when they would otherwise like to. Service authors may
Note: See TracChangeset
for help on using the changeset viewer.