Changeset 978 for draft-ietf-httpbis/orig
- Timestamp:
- 04/08/10 15:03:20 (12 years ago)
- Location:
- draft-ietf-httpbis/orig
- Files:
-
- 9 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/orig/rfc2145.html
r598 r978 47 47 } 48 48 49 dl.empty dd { 49 ul.empty { 50 list-style-type: none; 51 } 52 ul.empty li { 50 53 margin-top: .5em; 51 54 } … … 128 131 } 129 132 table.header { 133 border-spacing: 1px; 130 134 width: 95%; 131 135 font-size: 10pt; … … 139 143 white-space: nowrap; 140 144 } 141 t d.header{145 table.header td { 142 146 background-color: gray; 143 147 width: 50%; … … 315 319 <link rel="Alternate" title="Authorative ASCII Version" href="http://www.ietf.org/rfc/rfc2145.txt"> 316 320 <link rel="Help" title="Additional Information on tools.ietf.org" href="http://tools.ietf.org/html/rfc2145"> 317 <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1. 438, 2009-05-27 13:34:05, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/">321 <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.520, 2010-07-14 12:36:35, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/"> 318 322 <meta name="keywords" content="HTTP, hypertext transfer protocol"> 319 <link rel="schema.DC" href="http://purl.org/dc/elements/1.1/"> 320 <meta name="DC.Creator" content="Mogul, J. C."> 321 <meta name="DC.Creator" content="Fielding, R. T."> 322 <meta name="DC.Creator" content="Gettys, J."> 323 <meta name="DC.Creator" content="Frystyk, H."> 324 <meta name="DC.Identifier" content="urn:ietf:rfc:2145"> 325 <meta name="DC.Date.Issued" scheme="ISO8601" content="1997-05"> 326 <meta name="DC.Description.Abstract" content="HTTP request and response messages include an HTTP protocol version number. Some confusion exists concerning the proper use and interpretation of HTTP version numbers, and concerning interoperability of HTTP implementations of different protocol versions. This document is an attempt to clarify the situation. It is not a modification of the intended meaning of the existing HTTP/1.0 and HTTP/1.1 documents, but it does describe the intention of the authors of those documents, and can be considered definitive when there is any ambiguity in those documents concerning HTTP version numbers, for all versions of HTTP."> 327 <meta name="DC.isPartOf" content="urn:ISSN:2070-1721"> 323 <link rel="schema.dct" href="http://purl.org/dc/terms/"> 324 <meta name="dct.creator" content="Mogul, J. C."> 325 <meta name="dct.creator" content="Fielding, R. T."> 326 <meta name="dct.creator" content="Gettys, J."> 327 <meta name="dct.creator" content="Frystyk, H."> 328 <meta name="dct.identifier" content="urn:ietf:rfc:2145"> 329 <meta name="dct.issued" scheme="ISO8601" content="1997-05"> 330 <meta name="dct.abstract" content="HTTP request and response messages include an HTTP protocol version number. Some confusion exists concerning the proper use and interpretation of HTTP version numbers, and concerning interoperability of HTTP implementations of different protocol versions. This document is an attempt to clarify the situation. It is not a modification of the intended meaning of the existing HTTP/1.0 and HTTP/1.1 documents, but it does describe the intention of the authors of those documents, and can be considered definitive when there is any ambiguity in those documents concerning HTTP version numbers, for all versions of HTTP."> 331 <meta name="dct.isPartOf" content="urn:issn:2070-1721"> 332 <meta name="description" content="HTTP request and response messages include an HTTP protocol version number. Some confusion exists concerning the proper use and interpretation of HTTP version numbers, and concerning interoperability of HTTP implementations of different protocol versions. This document is an attempt to clarify the situation. It is not a modification of the intended meaning of the existing HTTP/1.0 and HTTP/1.1 documents, but it does describe the intention of the authors of those documents, and can be considered definitive when there is any ambiguity in those documents concerning HTTP version numbers, for all versions of HTTP."> 328 333 </head> 329 334 <body> 330 <table summary="header information" class="header" border="0" cellpadding="1" cellspacing="1"> 331 <tr> 332 <td class="header left">Network Working Group</td> 333 <td class="header right">J. C. Mogul</td> 334 </tr> 335 <tr> 336 <td class="header left">Request for Comments: 2145</td> 337 <td class="header right">DEC</td> 338 </tr> 339 <tr> 340 <td class="header left">Category: Informational</td> 341 <td class="header right">R. T. Fielding</td> 342 </tr> 343 <tr> 344 <td class="header left"></td> 345 <td class="header right">UC Irvine</td> 346 </tr> 347 <tr> 348 <td class="header left"></td> 349 <td class="header right">J. Gettys</td> 350 </tr> 351 <tr> 352 <td class="header left"></td> 353 <td class="header right">DEC</td> 354 </tr> 355 <tr> 356 <td class="header left"></td> 357 <td class="header right">H. Frystyk</td> 358 </tr> 359 <tr> 360 <td class="header left"></td> 361 <td class="header right">MIT/LCS</td> 362 </tr> 363 <tr> 364 <td class="header left"></td> 365 <td class="header right">May 1997</td> 366 </tr> 335 <table class="header"> 336 <tbody> 337 <tr> 338 <td class="left">Network Working Group</td> 339 <td class="right">J. Mogul</td> 340 </tr> 341 <tr> 342 <td class="left">Request for Comments: 2145</td> 343 <td class="right">DEC</td> 344 </tr> 345 <tr> 346 <td class="left">Category: Informational</td> 347 <td class="right">R. Fielding</td> 348 </tr> 349 <tr> 350 <td class="left"></td> 351 <td class="right">UC Irvine</td> 352 </tr> 353 <tr> 354 <td class="left"></td> 355 <td class="right">J. Gettys</td> 356 </tr> 357 <tr> 358 <td class="left"></td> 359 <td class="right">DEC</td> 360 </tr> 361 <tr> 362 <td class="left"></td> 363 <td class="right">H. Frystyk</td> 364 </tr> 365 <tr> 366 <td class="left"></td> 367 <td class="right">MIT/LCS</td> 368 </tr> 369 <tr> 370 <td class="left"></td> 371 <td class="right">May 1997</td> 372 </tr> 373 </tbody> 367 374 </table> 368 375 <p class="title">Use and Interpretation of HTTP Version Numbers</p> … … 452 459 <p id="rfc.section.2.p.1">We start by restating the language quoted above from section <a href="http://tools.ietf.org/html/rfc2068#section-3.1">3.1</a> of the HTTP/1.1 specification <a href="#RFC2068"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[2]</cite></a>: 453 460 </p> 454 < dl class="empty">455 < dd>It is, and has always been, the explicit intent of the HTTP specification that the interpretation of an HTTP message header461 <ul class="empty"> 462 <li>It is, and has always been, the explicit intent of the HTTP specification that the interpretation of an HTTP message header 456 463 does not change between minor versions of the same major version. 457 </ dd>458 < dd>It is, and has always been, the explicit intent of the HTTP specification that an implementation receiving a message header464 </li> 465 <li>It is, and has always been, the explicit intent of the HTTP specification that an implementation receiving a message header 459 466 that it does not understand <em class="bcp14">MUST</em> ignore that header. (The word "ignore" has a special meaning for proxies; see section <a href="#proxy.behavior" title="Proxy behavior">2.1</a> below.) 460 </ dd>461 </ dl>467 </li> 468 </ul> 462 469 <p id="rfc.section.2.p.2">To make this as clear as possible: The major version sent in a message <em class="bcp14">MAY</em> indicate the interpretation of other header fields. The minor version sent in a message <em class="bcp14">MUST NOT</em> indicate the interpretation of other header fields. This reflects the principle that the minor version labels the capability 463 470 of the sender, not the interpretation of the message. 464 471 </p> 465 <div class="note" >472 <div class="note" id="rfc.section.2.p.3"> 466 473 <p>Note: In a future version of HTTP, we may introduce a mechanism that explicitly requires a receiving implementation to reject 467 474 a message if it does not understand certain headers. For example, this might be implemented by means of a header that lists … … 520 527 <h1 class="np" id="rfc.references"><a href="#rfc.section.4" id="rfc.section.4">4.</a> References 521 528 </h1> 522 <table summary="References">529 <table> 523 530 <tr> 524 531 <td class="reference"><b id="RFC1945">[1]</b></td> 525 <td class="top"><a href="mailto:timbl@w3.org" title="MIT, Laboratory for Computer Science">Berners-Lee, T.</a>, <a href="mailto:fielding@ics.uci.edu" title="University of California, Irvine, Department of Information and Computer Science">Fielding, R. T.</a>, and <a href="mailto:frystyk@w3.org" title="W3 Consortium, MIT Laboratory for Computer Science">H.F. Nielsen</a>, “<a href="http://tools.ietf.org/html/rfc1945">Hypertext Transfer Protocol -- HTTP/1.0</a>”, RFC 1945, May 1996.532 <td class="top"><a href="mailto:timbl@w3.org" title="MIT, Laboratory for Computer Science">Berners-Lee, T.</a>, <a href="mailto:fielding@ics.uci.edu" title="University of California, Irvine, Department of Information and Computer Science">Fielding, R.</a>, and <a href="mailto:frystyk@w3.org" title="W3 Consortium, MIT Laboratory for Computer Science">H. Nielsen</a>, “<a href="http://tools.ietf.org/html/rfc1945">Hypertext Transfer Protocol -- HTTP/1.0</a>”, RFC 1945, May 1996. 526 533 </td> 527 534 </tr> … … 543 550 </table> 544 551 <hr class="noprint"> 545 <h1 id="rfc.authors" class="np"><a href="#rfc.section.5" id="rfc.section.5">5.</a> <a href="#rfc.authors">Authors' Addresses</a></h1> 546 <address class="vcard"><span class="vcardline"><span class="fn">Jeffrey C. Mogul</span><span class="n hidden"><span class="family-name">Mogul</span><span class="given-name">Jeffrey C.</span></span></span><span class="org vcardline">Western Research Laboratory</span><span class="adr"><span class="street-address vcardline">Digital Equipment Corporation</span><span class="street-address vcardline">250 University Avenue</span><span class="vcardline"><span class="locality">Palo Alto</span>, <span class="region">California</span> <span class="postal-code">94305</span></span><span class="country-name vcardline">USA</span></span><span class="vcardline">EMail: <a href="mailto:mogul@wrl.dec.com"><span class="email">mogul@wrl.dec.com</span></a></span></address> 547 <address class="vcard"><span class="vcardline"><span class="fn">Roy T. Fielding</span><span class="n hidden"><span class="family-name">Fielding</span><span class="given-name">Roy T.</span></span></span><span class="org vcardline">Department of Information and Computer Science</span><span class="adr"><span class="street-address vcardline">University of California</span><span class="vcardline"><span class="locality">Irvine</span>, <span class="region">CA</span> <span class="postal-code">92717-3425</span></span><span class="country-name vcardline">USA</span></span><span class="vcardline tel"><span class="type">Fax</span>: <a href="fax:+1(714)824-4056"><span class="value">+1 (714) 824-4056</span></a></span><span class="vcardline">EMail: <a href="mailto:fielding@ics.uci.edu"><span class="email">fielding@ics.uci.edu</span></a></span></address> 548 <address class="vcard"><span class="vcardline"><span class="fn">Jim Gettys</span><span class="n hidden"><span class="family-name">Gettys</span><span class="given-name">Jim</span></span></span><span class="org vcardline">MIT Laboratory for Computer Science</span><span class="adr"><span class="street-address vcardline">545 Technology Square</span><span class="vcardline"><span class="locality">Cambridge</span>, <span class="region">MA</span> <span class="postal-code">02139</span></span><span class="country-name vcardline">USA</span></span><span class="vcardline tel"><span class="type">Fax</span>: <a href="fax:+1(617)2588682"><span class="value">+1 (617) 258 8682</span></a></span><span class="vcardline">EMail: <a href="mailto:jg@w3.org"><span class="email">jg@w3.org</span></a></span></address> 549 <address class="vcard"><span class="vcardline"><span class="fn">Henrik Frystyk Nielsen</span><span class="n hidden"><span class="family-name">Frystyk</span></span></span><span class="org vcardline">W3 Consortium</span><span class="adr"><span class="street-address vcardline">MIT Laboratory for Computer Science</span><span class="street-address vcardline">545 Technology Square</span><span class="vcardline"><span class="locality">Cambridge</span>, <span class="region">MA</span> <span class="postal-code">02139</span></span><span class="country-name vcardline">USA</span></span><span class="vcardline tel"><span class="type">Fax</span>: <a href="fax:+1(617)2588682"><span class="value">+1 (617) 258 8682</span></a></span><span class="vcardline">EMail: <a href="mailto:frystyk@w3.org"><span class="email">frystyk@w3.org</span></a></span></address> 552 <div class="avoidbreak"> 553 <h1 id="rfc.authors" class="np"><a href="#rfc.section.5" id="rfc.section.5">5.</a> <a href="#rfc.authors">Authors' Addresses</a></h1> 554 <address class="vcard"><span class="vcardline"><span class="fn">Jeffrey C. Mogul</span><span class="n hidden"><span class="family-name">Mogul</span><span class="given-name">Jeffrey C.</span></span></span><span class="org vcardline">Western Research Laboratory</span><span class="adr"><span class="street-address vcardline">Digital Equipment Corporation</span><span class="street-address vcardline">250 University Avenue</span><span class="vcardline"><span class="locality">Palo Alto</span>, <span class="region">California</span> <span class="postal-code">94305</span></span><span class="country-name vcardline">USA</span></span><span class="vcardline">EMail: <a href="mailto:mogul@wrl.dec.com"><span class="email">mogul@wrl.dec.com</span></a></span></address> 555 <address class="vcard"><span class="vcardline"><span class="fn">Roy T. Fielding</span><span class="n hidden"><span class="family-name">Fielding</span><span class="given-name">Roy T.</span></span></span><span class="org vcardline">Department of Information and Computer Science</span><span class="adr"><span class="street-address vcardline">University of California</span><span class="vcardline"><span class="locality">Irvine</span>, <span class="region">CA</span> <span class="postal-code">92717-3425</span></span><span class="country-name vcardline">USA</span></span><span class="vcardline tel"><span class="type">Fax</span>: <a href="fax:+1(714)824-4056"><span class="value">+1 (714) 824-4056</span></a></span><span class="vcardline">EMail: <a href="mailto:fielding@ics.uci.edu"><span class="email">fielding@ics.uci.edu</span></a></span></address> 556 <address class="vcard"><span class="vcardline"><span class="fn">Jim Gettys</span><span class="n hidden"><span class="family-name">Gettys</span><span class="given-name">Jim</span></span></span><span class="org vcardline">MIT Laboratory for Computer Science</span><span class="adr"><span class="street-address vcardline">545 Technology Square</span><span class="vcardline"><span class="locality">Cambridge</span>, <span class="region">MA</span> <span class="postal-code">02139</span></span><span class="country-name vcardline">USA</span></span><span class="vcardline tel"><span class="type">Fax</span>: <a href="fax:+1(617)2588682"><span class="value">+1 (617) 258 8682</span></a></span><span class="vcardline">EMail: <a href="mailto:jg@w3.org"><span class="email">jg@w3.org</span></a></span></address> 557 <address class="vcard"><span class="vcardline"><span class="fn">Henrik Frystyk Nielsen</span><span class="n hidden"><span class="family-name">Frystyk</span></span></span><span class="org vcardline">W3 Consortium</span><span class="adr"><span class="street-address vcardline">MIT Laboratory for Computer Science</span><span class="street-address vcardline">545 Technology Square</span><span class="vcardline"><span class="locality">Cambridge</span>, <span class="region">MA</span> <span class="postal-code">02139</span></span><span class="country-name vcardline">USA</span></span><span class="vcardline tel"><span class="type">Fax</span>: <a href="fax:+1(617)2588682"><span class="value">+1 (617) 258 8682</span></a></span><span class="vcardline">EMail: <a href="mailto:frystyk@w3.org"><span class="email">frystyk@w3.org</span></a></span></address> 558 </div> 550 559 <h1><a id="rfc.copyright" href="#rfc.copyright">Full Copyright Statement</a></h1> 551 560 <p>Copyright © The Internet Society (1997). All Rights Reserved.</p> … … 558 567 translate it into languages other than English. 559 568 </p> 560 <p>The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assign ees.</p>569 <p>The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.</p> 561 570 <p>This document and the information contained herein is provided on an “AS IS” basis and THE INTERNET SOCIETY AND THE INTERNET 562 571 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE -
draft-ietf-httpbis/orig/rfc2616-symrefs.html
r598 r978 37 37 } 38 38 39 dl.empty dd { 39 ul.empty { 40 list-style-type: none; 41 } 42 ul.empty li { 40 43 margin-top: .5em; 41 44 } … … 118 121 } 119 122 table.header { 123 border-spacing: 1px; 120 124 width: 95%; 121 125 font-size: 10pt; … … 129 133 white-space: nowrap; 130 134 } 131 t d.header{135 table.header td { 132 136 background-color: gray; 133 137 width: 50%; 134 138 } 135 t d.header a {139 table.header a { 136 140 color: white; 137 141 } … … 188 192 margin-left: 0em; 189 193 margin-right: 0em; 194 } 195 .avoidbreak { 196 page-break-inside: avoid; 190 197 } 191 198 .bcp14 { … … 285 292 @page { 286 293 @top-left { 287 content: "I NTERNET DRAFT";294 content: "Internet-Draft"; 288 295 } 289 296 @top-right { … … 338 345 <link rel="Appendix" title="19 Appendices" href="#rfc.section.19"> 339 346 <link rel="Appendix" title="20 Index" href="#rfc.section.20"> 340 <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.438, 2009-05-27 13:34:05, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/"> 341 <link rel="schema.DC" href="http://purl.org/dc/elements/1.1/"> 342 <meta name="DC.Creator" content="Fielding, R."> 343 <meta name="DC.Creator" content="Gettys, J."> 344 <meta name="DC.Creator" content="Mogul, J."> 345 <meta name="DC.Creator" content="Frystyk, H."> 346 <meta name="DC.Creator" content="Masinter, L."> 347 <meta name="DC.Creator" content="Leach, P."> 348 <meta name="DC.Creator" content="Berners-Lee, T."> 349 <meta name="DC.Identifier" content="urn:ietf:id:rfc2616-symrefs"> 350 <meta name="DC.Date.Issued" scheme="ISO8601" content="1999-06"> 351 <meta name="DC.Relation.Replaces" content="urn:ietf:rfc:2068"> 352 <meta name="DC.Description.Abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, protocol which can be used for many tasks beyond its use for hypertext, such as name servers and distributed object management systems, through extension of its request methods, error codes and headers . A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred. HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as "HTTP/1.1", and is an update to RFC 2068 ."> 347 <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.520, 2010-07-14 12:36:35, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/"> 348 <link rel="schema.dct" href="http://purl.org/dc/terms/"> 349 <meta name="dct.creator" content="Fielding, R."> 350 <meta name="dct.creator" content="Gettys, J."> 351 <meta name="dct.creator" content="Mogul, J."> 352 <meta name="dct.creator" content="Frystyk, H."> 353 <meta name="dct.creator" content="Masinter, L."> 354 <meta name="dct.creator" content="Leach, P."> 355 <meta name="dct.creator" content="Berners-Lee, T."> 356 <meta name="dct.identifier" content="urn:ietf:id:rfc2616-symrefs"> 357 <meta name="dct.issued" scheme="ISO8601" content="1999-06"> 358 <meta name="dct.replaces" content="urn:ietf:rfc:2068"> 359 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, protocol which can be used for many tasks beyond its use for hypertext, such as name servers and distributed object management systems, through extension of its request methods, error codes and headers . A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred. HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as "HTTP/1.1", and is an update to RFC 2068 ."> 360 <meta name="description" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, protocol which can be used for many tasks beyond its use for hypertext, such as name servers and distributed object management systems, through extension of its request methods, error codes and headers . A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred. HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as "HTTP/1.1", and is an update to RFC 2068 ."> 353 361 </head> 354 362 <body> 355 <table summary="header information" class="header" border="0" cellpadding="1" cellspacing="1"> 356 <tr> 357 <td class="header left">Network Working Group</td> 358 <td class="header right">R. Fielding</td> 359 </tr> 360 <tr> 361 <td class="header left">Internet Draft</td> 362 <td class="header right">UC Irvine</td> 363 </tr> 364 <tr> 365 <td class="header left"> 366 <rfc2616-symrefs> 367 368 </td> 369 <td class="header right">J. Gettys</td> 370 </tr> 371 <tr> 372 <td class="header left">Obsoletes: <a href="http://tools.ietf.org/html/rfc2068">2068</a> (if approved) 373 </td> 374 <td class="header right">Compaq/W3C</td> 375 </tr> 376 <tr> 377 <td class="header left">Intended status: Standards Track</td> 378 <td class="header right">J. Mogul</td> 379 </tr> 380 <tr> 381 <td class="header left">Expires: December 1999</td> 382 <td class="header right">Compaq</td> 383 </tr> 384 <tr> 385 <td class="header left"></td> 386 <td class="header right">H. Frystyk</td> 387 </tr> 388 <tr> 389 <td class="header left"></td> 390 <td class="header right">W3C/MIT</td> 391 </tr> 392 <tr> 393 <td class="header left"></td> 394 <td class="header right">L. Masinter</td> 395 </tr> 396 <tr> 397 <td class="header left"></td> 398 <td class="header right">Xerox</td> 399 </tr> 400 <tr> 401 <td class="header left"></td> 402 <td class="header right">P. Leach</td> 403 </tr> 404 <tr> 405 <td class="header left"></td> 406 <td class="header right">Microsoft</td> 407 </tr> 408 <tr> 409 <td class="header left"></td> 410 <td class="header right">T. Berners-Lee</td> 411 </tr> 412 <tr> 413 <td class="header left"></td> 414 <td class="header right">W3C/MIT</td> 415 </tr> 416 <tr> 417 <td class="header left"></td> 418 <td class="header right">June 1999</td> 419 </tr> 363 <table class="header"> 364 <tbody> 365 <tr> 366 <td class="left">Network Working Group</td> 367 <td class="right">R. Fielding</td> 368 </tr> 369 <tr> 370 <td class="left">Internet-Draft</td> 371 <td class="right">UC Irvine</td> 372 </tr> 373 <tr> 374 <td class="left">Obsoletes: <a href="http://tools.ietf.org/html/rfc2068">2068</a> (if approved) 375 </td> 376 <td class="right">J. Gettys</td> 377 </tr> 378 <tr> 379 <td class="left">Intended status: Standards Track</td> 380 <td class="right">Compaq/W3C</td> 381 </tr> 382 <tr> 383 <td class="left">Expires: December 1999</td> 384 <td class="right">J. Mogul</td> 385 </tr> 386 <tr> 387 <td class="left"></td> 388 <td class="right">Compaq</td> 389 </tr> 390 <tr> 391 <td class="left"></td> 392 <td class="right">H. Frystyk</td> 393 </tr> 394 <tr> 395 <td class="left"></td> 396 <td class="right">W3C/MIT</td> 397 </tr> 398 <tr> 399 <td class="left"></td> 400 <td class="right">L. Masinter</td> 401 </tr> 402 <tr> 403 <td class="left"></td> 404 <td class="right">Xerox</td> 405 </tr> 406 <tr> 407 <td class="left"></td> 408 <td class="right">P. Leach</td> 409 </tr> 410 <tr> 411 <td class="left"></td> 412 <td class="right">Microsoft</td> 413 </tr> 414 <tr> 415 <td class="left"></td> 416 <td class="right">T. Berners-Lee</td> 417 </tr> 418 <tr> 419 <td class="left"></td> 420 <td class="right">W3C/MIT</td> 421 </tr> 422 <tr> 423 <td class="left"></td> 424 <td class="right">June 1999</td> 425 </tr> 426 </tbody> 420 427 </table> 421 428 <p class="title">Hypertext Transfer Protocol -- HTTP/1.1<br><span class="filename">rfc2616-symrefs</span></p> … … 432 439 in progress”. 433 440 </p> 434 <p>The list of current Internet-Drafts can be accessed at <<a href="http://www.ietf.org/ietf/1id-abstracts.txt">http://www.ietf.org/ietf/1id-abstracts.txt</a>>.435 </p> 436 <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>>.441 <p>The list of current Internet-Drafts can be accessed at <a href="http://www.ietf.org/ietf/1id-abstracts.txt">http://www.ietf.org/ietf/1id-abstracts.txt</a>. 442 </p> 443 <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>. 437 444 </p> 438 445 <p>This Internet-Draft will expire in December 1999.</p> … … 801 808 </li> 802 809 <li class="tocline0">20. <a href="#rfc.section.20">Index</a></li> 810 <li class="tocline0"><a href="#rfc.index">Index</a></li> 803 811 <li class="tocline0"><a href="#rfc.ipr">Intellectual Property and Copyright Statements</a></li> 804 <li class="tocline0"><a href="#rfc.index">Index</a></li>805 812 </ul> 806 813 <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a> <a id="introduction" href="#introduction">Introduction</a></h1> … … 834 841 <p id="rfc.section.1.3.p.2"> <span id="rfc.iref.c.1"></span> <dfn>connection</dfn> 835 842 </p> 836 < dl class="empty">837 < dd>A transport layer virtual circuit established between two programs for the purpose of communication.</dd>838 </ dl>843 <ul class="empty"> 844 <li>A transport layer virtual circuit established between two programs for the purpose of communication.</li> 845 </ul> 839 846 <p id="rfc.section.1.3.p.3"> <span id="rfc.iref.m.1"></span> <dfn>message</dfn> 840 847 </p> 841 < dl class="empty">842 < dd>The basic unit of HTTP communication, consisting of a structured sequence of octets matching the syntax defined in <a href="#http.message" title="HTTP Message">Section 4</a> and transmitted via the connection.843 </ dd>844 </ dl>848 <ul class="empty"> 849 <li>The basic unit of HTTP communication, consisting of a structured sequence of octets matching the syntax defined in <a href="#http.message" title="HTTP Message">Section 4</a> and transmitted via the connection. 850 </li> 851 </ul> 845 852 <p id="rfc.section.1.3.p.4"> <span id="rfc.iref.r.1"></span> <dfn>request</dfn> 846 853 </p> 847 < dl class="empty">848 < dd>An HTTP request message, as defined in <a href="#request" title="Request">Section 5</a>.849 </ dd>850 </ dl>854 <ul class="empty"> 855 <li>An HTTP request message, as defined in <a href="#request" title="Request">Section 5</a>. 856 </li> 857 </ul> 851 858 <p id="rfc.section.1.3.p.5"> <span id="rfc.iref.r.2"></span> <dfn>response</dfn> 852 859 </p> 853 < dl class="empty">854 < dd>An HTTP response message, as defined in <a href="#response" title="Response">Section 6</a>.855 </ dd>856 </ dl>860 <ul class="empty"> 861 <li>An HTTP response message, as defined in <a href="#response" title="Response">Section 6</a>. 862 </li> 863 </ul> 857 864 <p id="rfc.section.1.3.p.6"> <span id="rfc.iref.r.3"></span> <dfn>resource</dfn> 858 865 </p> 859 < dl class="empty">860 < dd>A network data object or service that can be identified by a URI, as defined in <a href="#uri" title="Uniform Resource Identifiers">Section 3.2</a>. Resources may be available in multiple representations (e.g. multiple languages, data formats, size, and resolutions) or866 <ul class="empty"> 867 <li>A network data object or service that can be identified by a URI, as defined in <a href="#uri" title="Uniform Resource Identifiers">Section 3.2</a>. Resources may be available in multiple representations (e.g. multiple languages, data formats, size, and resolutions) or 861 868 vary in other ways. 862 </ dd>863 </ dl>869 </li> 870 </ul> 864 871 <p id="rfc.section.1.3.p.7"> <span id="rfc.iref.e.1"></span> <dfn>entity</dfn> 865 872 </p> 866 < dl class="empty">867 < dd>The information transferred as the payload of a request or response. An entity consists of metainformation in the form of873 <ul class="empty"> 874 <li>The information transferred as the payload of a request or response. An entity consists of metainformation in the form of 868 875 entity-header fields and content in the form of an entity-body, as described in <a href="#entity" title="Entity">Section 7</a>. 869 </ dd>870 </ dl>876 </li> 877 </ul> 871 878 <p id="rfc.section.1.3.p.8"> <span id="rfc.iref.r.4"></span> <dfn>representation</dfn> 872 879 </p> 873 < dl class="empty">874 < dd>An entity included with a response that is subject to content negotiation, as described in <a href="#content.negotiation" title="Content Negotiation">Section 12</a>. There may exist multiple representations associated with a particular response status.875 </ dd>876 </ dl>880 <ul class="empty"> 881 <li>An entity included with a response that is subject to content negotiation, as described in <a href="#content.negotiation" title="Content Negotiation">Section 12</a>. There may exist multiple representations associated with a particular response status. 882 </li> 883 </ul> 877 884 <p id="rfc.section.1.3.p.9"> <span id="rfc.iref.c.2"></span> <dfn>content negotiation</dfn> 878 885 </p> 879 < dl class="empty">880 < dd>The mechanism for selecting the appropriate representation when servicing a request, as described in <a href="#content.negotiation" title="Content Negotiation">Section 12</a>. The representation of entities in any response can be negotiated (including error responses).881 </ dd>882 </ dl>886 <ul class="empty"> 887 <li>The mechanism for selecting the appropriate representation when servicing a request, as described in <a href="#content.negotiation" title="Content Negotiation">Section 12</a>. The representation of entities in any response can be negotiated (including error responses). 888 </li> 889 </ul> 883 890 <p id="rfc.section.1.3.p.10"> <span id="rfc.iref.v.1"></span> <dfn>variant</dfn> 884 891 </p> 885 < dl class="empty">886 < dd>A resource may have one, or more than one, representation(s) associated with it at any given instant. Each of these representations892 <ul class="empty"> 893 <li>A resource may have one, or more than one, representation(s) associated with it at any given instant. Each of these representations 887 894 is termed a `varriant'. Use of the term `variant' does not necessarily imply that the resource is subject to content negotiation. 888 </ dd>889 </ dl>895 </li> 896 </ul> 890 897 <p id="rfc.section.1.3.p.11"> <span id="rfc.iref.c.3"></span> <dfn>client</dfn> 891 898 </p> 892 < dl class="empty">893 < dd>A program that establishes connections for the purpose of sending requests.</dd>894 </ dl>899 <ul class="empty"> 900 <li>A program that establishes connections for the purpose of sending requests.</li> 901 </ul> 895 902 <p id="rfc.section.1.3.p.12"> <span id="rfc.iref.u.1"></span> <dfn>user agent</dfn> 896 903 </p> 897 < dl class="empty">898 < dd>The client which initiates a request. These are often browsers, editors, spiders (web-traversing robots), or other end user904 <ul class="empty"> 905 <li>The client which initiates a request. These are often browsers, editors, spiders (web-traversing robots), or other end user 899 906 tools. 900 </ dd>901 </ dl>907 </li> 908 </ul> 902 909 <p id="rfc.section.1.3.p.13"> <span id="rfc.iref.s.1"></span> <dfn>server</dfn> 903 910 </p> 904 < dl class="empty">905 < dd>An application program that accepts connections in order to service requests by sending back responses. Any given program911 <ul class="empty"> 912 <li>An application program that accepts connections in order to service requests by sending back responses. Any given program 906 913 may be capable of being both a client and a server; our use of these terms refers only to the role being performed by the 907 914 program for a particular connection, rather than to the program's capabilities in general. Likewise, any server may act as 908 915 an origin server, proxy, gateway, or tunnel, switching behavior based on the nature of each request. 909 </ dd>910 </ dl>916 </li> 917 </ul> 911 918 <p id="rfc.section.1.3.p.14"> <span id="rfc.iref.o.1"></span> <dfn>origin server</dfn> 912 919 </p> 913 < dl class="empty">914 < dd>The server on which a given resource resides or is to be created.</dd>915 </ dl>920 <ul class="empty"> 921 <li>The server on which a given resource resides or is to be created.</li> 922 </ul> 916 923 <p id="rfc.section.1.3.p.15"> <span id="rfc.iref.p.1"></span> <dfn>proxy</dfn> 917 924 </p> 918 < dl class="empty">919 < dd>An intermediary program which acts as both a server and a client for the purpose of making requests on behalf of other clients.925 <ul class="empty"> 926 <li>An intermediary program which acts as both a server and a client for the purpose of making requests on behalf of other clients. 920 927 Requests are serviced internally or by passing them on, with possible translation, to other servers. A proxy <em class="bcp14">MUST</em> implement both the client and server requirements of this specification. A "transparent proxy" is a proxy that does not modify 921 928 the request or response beyond what is required for proxy authentication and identification. A "non-transparent proxy" is … … 923 930 services, media type transformation, protocol reduction, or anonymity filtering. Except where either transparent or non-transparent 924 931 behavior is explicitly stated, the HTTP proxy requirements apply to both types of proxies. 925 </ dd>926 </ dl>932 </li> 933 </ul> 927 934 <p id="rfc.section.1.3.p.16"> <span id="rfc.iref.g.1"></span> <dfn>gateway</dfn> 928 935 </p> 929 < dl class="empty">930 < dd>A server which acts as an intermediary for some other server. Unlike a proxy, a gateway receives requests as if it were the936 <ul class="empty"> 937 <li>A server which acts as an intermediary for some other server. Unlike a proxy, a gateway receives requests as if it were the 931 938 origin server for the requested resource; the requesting client may not be aware that it is communicating with a gateway. 932 </ dd>933 </ dl>939 </li> 940 </ul> 934 941 <p id="rfc.section.1.3.p.17"> <span id="rfc.iref.t.1"></span> <dfn>tunnel</dfn> 935 942 </p> 936 < dl class="empty">937 < dd>An intermediary program which is acting as a blind relay between two connections. Once active, a tunnel is not considered943 <ul class="empty"> 944 <li>An intermediary program which is acting as a blind relay between two connections. Once active, a tunnel is not considered 938 945 a party to the HTTP communication, though the tunnel may have been initiated by an HTTP request. The tunnel ceases to exist 939 946 when both ends of the relayed connections are closed. 940 </ dd>941 </ dl>947 </li> 948 </ul> 942 949 <p id="rfc.section.1.3.p.18"> <span id="rfc.iref.c.4"></span> <dfn>cache</dfn> 943 950 </p> 944 < dl class="empty">945 < dd>A program's local store of response messages and the subsystem that controls its message storage, retrieval, and deletion.951 <ul class="empty"> 952 <li>A program's local store of response messages and the subsystem that controls its message storage, retrieval, and deletion. 946 953 A cache stores cacheable responses in order to reduce the response time and network bandwidth consumption on future, equivalent 947 954 requests. Any client or server may include a cache, though a cache cannot be used by a server that is acting as a tunnel. 948 </ dd>949 </ dl>955 </li> 956 </ul> 950 957 <p id="rfc.section.1.3.p.19"> <span id="rfc.iref.c.5"></span> <dfn>cacheable</dfn> 951 958 </p> 952 < dl class="empty">953 < dd>A response is cacheable if a cache is allowed to store a copy of the response message for use in answering subsequent requests.959 <ul class="empty"> 960 <li>A response is cacheable if a cache is allowed to store a copy of the response message for use in answering subsequent requests. 954 961 The rules for determining the cacheability of HTTP responses are defined in <a href="#caching" title="Caching in HTTP">Section 13</a>. Even if a resource is cacheable, there may be additional constraints on whether a cache can use the cached copy for a particular 955 962 request. 956 </ dd>957 </ dl>963 </li> 964 </ul> 958 965 <p id="rfc.section.1.3.p.20"> <span id="rfc.iref.f.1"></span> <dfn>first-hand</dfn> 959 966 </p> 960 < dl class="empty">961 < dd>A response is first-hand if it comes directly and without unnecessary delay from the origin server, perhaps via one or more967 <ul class="empty"> 968 <li>A response is first-hand if it comes directly and without unnecessary delay from the origin server, perhaps via one or more 962 969 proxies. A response is also first-hand if its validity has just been checked directly with the origin server. 963 </ dd>964 </ dl>970 </li> 971 </ul> 965 972 <p id="rfc.section.1.3.p.21"> <span id="rfc.iref.e.2"></span> <dfn>explicit expiration time</dfn> 966 973 </p> 967 < dl class="empty">968 < dd>The time at which the origin server intends that an entity should no longer be returned by a cache without further validation.</dd>969 </ dl>974 <ul class="empty"> 975 <li>The time at which the origin server intends that an entity should no longer be returned by a cache without further validation.</li> 976 </ul> 970 977 <p id="rfc.section.1.3.p.22"> <span id="rfc.iref.h.1"></span> <dfn>heuristic expiration time</dfn> 971 978 </p> 972 < dl class="empty">973 < dd>An expiration time assigned by a cache when no explicit expiration time is available.</dd>974 </ dl>979 <ul class="empty"> 980 <li>An expiration time assigned by a cache when no explicit expiration time is available.</li> 981 </ul> 975 982 <p id="rfc.section.1.3.p.23"> <span id="rfc.iref.a.1"></span> <dfn>age</dfn> 976 983 </p> 977 < dl class="empty">978 < dd>The age of a response is the time since it was sent by, or successfully validated with, the origin server.</dd>979 </ dl>984 <ul class="empty"> 985 <li>The age of a response is the time since it was sent by, or successfully validated with, the origin server.</li> 986 </ul> 980 987 <p id="rfc.section.1.3.p.24"> <span id="rfc.iref.f.2"></span> <dfn>freshness lifetime</dfn> 981 988 </p> 982 < dl class="empty">983 < dd>The length of time between the generation of a response and its expiration time.</dd>984 </ dl>989 <ul class="empty"> 990 <li>The length of time between the generation of a response and its expiration time.</li> 991 </ul> 985 992 <p id="rfc.section.1.3.p.25"> <span id="rfc.iref.f.3"></span> <dfn>fresh</dfn> 986 993 </p> 987 < dl class="empty">988 < dd>A response is fresh if its age has not yet exceeded its freshness lifetime.</dd>989 </ dl>994 <ul class="empty"> 995 <li>A response is fresh if its age has not yet exceeded its freshness lifetime.</li> 996 </ul> 990 997 <p id="rfc.section.1.3.p.26"> <span id="rfc.iref.s.2"></span> <dfn>stale</dfn> 991 998 </p> 992 < dl class="empty">993 < dd>A response is stale if its age has passed its freshness lifetime.</dd>994 </ dl>999 <ul class="empty"> 1000 <li>A response is stale if its age has passed its freshness lifetime.</li> 1001 </ul> 995 1002 <p id="rfc.section.1.3.p.27"> <span id="rfc.iref.s.3"></span> <dfn>semantically transparent</dfn> 996 1003 </p> 997 < dl class="empty">998 < dd>A cache behaves in a "semantically transparent" manner, with respect to a particular response, when its use affects neither1004 <ul class="empty"> 1005 <li>A cache behaves in a "semantically transparent" manner, with respect to a particular response, when its use affects neither 999 1006 the requesting client nor the origin server, except to improve performance. When a cache is semantically transparent, the 1000 1007 client receives exactly the same response (except for hop-by-hop headers) that it would have received had its request been 1001 1008 handled directly by the origin server. 1002 </ dd>1003 </ dl>1009 </li> 1010 </ul> 1004 1011 <p id="rfc.section.1.3.p.28"> <span id="rfc.iref.v.2"></span> <dfn>validator</dfn> 1005 1012 </p> 1006 < dl class="empty">1007 < dd>A protocol element (e.g., an entity tag or a Last-Modified time) that is used to find out whether a cache entry is an equivalent1013 <ul class="empty"> 1014 <li>A protocol element (e.g., an entity tag or a Last-Modified time) that is used to find out whether a cache entry is an equivalent 1008 1015 copy of an entity. 1009 </ dd>1010 </ dl>1016 </li> 1017 </ul> 1011 1018 <p id="rfc.section.1.3.p.29"> <span id="rfc.iref.u.2"></span> <span id="rfc.iref.d.1"></span> <dfn>upstream</dfn>/<dfn>downstream</dfn> 1012 1019 </p> 1013 < dl class="empty">1014 < dd>Upstream and downstream describe the flow of a message: all messages flow from upstream to downstream.</dd>1015 </ dl>1020 <ul class="empty"> 1021 <li>Upstream and downstream describe the flow of a message: all messages flow from upstream to downstream.</li> 1022 </ul> 1016 1023 <p id="rfc.section.1.3.p.30"> <span id="rfc.iref.i.1"></span> <span id="rfc.iref.o.2"></span> <dfn>inbound</dfn>/<dfn>outbound</dfn> 1017 1024 </p> 1018 < dl class="empty">1019 < dd>Inbound and outbound refer to the request and response paths for messages: "inbound" means "traveling toward the origin server",1025 <ul class="empty"> 1026 <li>Inbound and outbound refer to the request and response paths for messages: "inbound" means "traveling toward the origin server", 1020 1027 and "outbound" means "traveling toward the user agent" 1021 </ dd>1022 </ dl>1028 </li> 1029 </ul> 1023 1030 <h2 id="rfc.section.1.4"><a href="#rfc.section.1.4">1.4</a> <a id="intro.overall.operation" href="#intro.overall.operation">Overall Operation</a></h2> 1024 1031 <p id="rfc.section.1.4.p.1">The HTTP protocol is a request/response protocol. A client sends a request to the server in the form of a request method, … … 1087 1094 </p> 1088 1095 <p id="rfc.section.2.1.p.2">name = definition </p> 1089 < dl class="empty">1090 < dd>The name of a rule is simply the name itself (without any enclosing "<" and ">") and is separated from its definition by the1096 <ul class="empty"> 1097 <li>The name of a rule is simply the name itself (without any enclosing "<" and ">") and is separated from its definition by the 1091 1098 equal "=" character. White space is only significant in that indentation of continuation lines is used to indicate a rule 1092 1099 definition that spans more than one line. Certain basic rules are in uppercase, such as SP, LWS, HT, CRLF, DIGIT, ALPHA, etc. 1093 1100 Angle brackets are used within definitions whenever their presence will facilitate discerning the use of rule names. 1094 </ dd>1095 </ dl>1101 </li> 1102 </ul> 1096 1103 <p id="rfc.section.2.1.p.3">"literal" </p> 1097 < dl class="empty">1098 < dd>Quotation marks surround literal text. Unless stated otherwise, the text is case-insensitive.</dd>1099 </ dl>1104 <ul class="empty"> 1105 <li>Quotation marks surround literal text. Unless stated otherwise, the text is case-insensitive.</li> 1106 </ul> 1100 1107 <p id="rfc.section.2.1.p.4">rule1 | rule2 </p> 1101 < dl class="empty">1102 < dd>Elements separated by a bar ("|") are alternatives, e.g., "yes | no" will accept yes or no.</dd>1103 </ dl>1108 <ul class="empty"> 1109 <li>Elements separated by a bar ("|") are alternatives, e.g., "yes | no" will accept yes or no.</li> 1110 </ul> 1104 1111 <p id="rfc.section.2.1.p.5">(rule1 rule2) </p> 1105 < dl class="empty">1106 < dd>Elements enclosed in parentheses are treated as a single element. Thus, "(elem (foo | bar) elem)" allows the token sequences1112 <ul class="empty"> 1113 <li>Elements enclosed in parentheses are treated as a single element. Thus, "(elem (foo | bar) elem)" allows the token sequences 1107 1114 "elem foo elem" and "elem bar elem". 1108 </ dd>1109 </ dl>1115 </li> 1116 </ul> 1110 1117 <p id="rfc.section.2.1.p.6">*rule </p> 1111 < dl class="empty">1112 < dd>The character "*" preceding an element indicates repetition. The full form is "<n>*<m>element" indicating at least <n> and1118 <ul class="empty"> 1119 <li>The character "*" preceding an element indicates repetition. The full form is "<n>*<m>element" indicating at least <n> and 1113 1120 at most <m> occurrences of element. Default values are 0 and infinity so that "*(element)" allows any number, including zero; 1114 1121 "1*element" requires at least one; and "1*2element" allows one or two. 1115 </ dd>1116 </ dl>1122 </li> 1123 </ul> 1117 1124 <p id="rfc.section.2.1.p.7">[rule] </p> 1118 < dl class="empty">1119 < dd>Square brackets enclose optional elements; "[foo bar]" is equivalent to "*1(foo bar)".</dd>1120 </ dl>1125 <ul class="empty"> 1126 <li>Square brackets enclose optional elements; "[foo bar]" is equivalent to "*1(foo bar)".</li> 1127 </ul> 1121 1128 <p id="rfc.section.2.1.p.8">N rule </p> 1122 < dl class="empty">1123 < dd>Specific repetition: "<n>(element)" is equivalent to "<n>*<n>(element)"; that is, exactly <n> occurrences of (element). Thus1129 <ul class="empty"> 1130 <li>Specific repetition: "<n>(element)" is equivalent to "<n>*<n>(element)"; that is, exactly <n> occurrences of (element). Thus 1124 1131 2DIGIT is a 2-digit number, and 3ALPHA is a string of three alphabetic characters. 1125 </ dd>1126 </ dl>1132 </li> 1133 </ul> 1127 1134 <p id="rfc.section.2.1.p.9">#rule </p> 1128 < dl class="empty">1129 < dd>A construct "#" is defined, similar to "*", for defining lists of elements. The full form is "<n>#<m>element" indicating at1135 <ul class="empty"> 1136 <li>A construct "#" is defined, similar to "*", for defining lists of elements. The full form is "<n>#<m>element" indicating at 1130 1137 least <n> and at most <m> elements, each separated by one or more commas (",") and <em class="bcp14">OPTIONAL</em> linear white space (LWS). This makes the usual form of lists very easy; a rule such as 1131 </ dd>1132 < dd>( *LWS element *( *LWS "," *LWS element ))</dd>1133 < dd>can be shown as</dd>1134 < dd>1#element</dd>1135 < dd>Wherever this construct is used, null elements are allowed, but do not contribute to the count of elements present. That is,1138 </li> 1139 <li>( *LWS element *( *LWS "," *LWS element ))</li> 1140 <li>can be shown as</li> 1141 <li>1#element</li> 1142 <li>Wherever this construct is used, null elements are allowed, but do not contribute to the count of elements present. That is, 1136 1143 "(element), , (element) " is permitted, but counts as only two elements. Therefore, where at least one element is required, 1137 1144 at least one non-null element <em class="bcp14">MUST</em> be present. Default values are 0 and infinity so that "#element" allows any number, including zero; "1#element" requires at 1138 1145 least one; and "1#2element" allows one or two. 1139 </ dd>1140 </ dl>1146 </li> 1147 </ul> 1141 1148 <p id="rfc.section.2.1.p.10">; comment </p> 1142 < dl class="empty">1143 < dd>A semi-colon, set off some distance to the right of rule text, starts a comment that continues to the end of line. This is1149 <ul class="empty"> 1150 <li>A semi-colon, set off some distance to the right of rule text, starts a comment that continues to the end of line. This is 1144 1151 a simple way of including useful notes in parallel with the specifications. 1145 </ dd>1146 </ dl>1152 </li> 1153 </ul> 1147 1154 <p id="rfc.section.2.1.p.11">implied *LWS </p> 1148 < dl class="empty">1149 < dd>The grammar described by this specification is word-based. Except where noted otherwise, linear white space (LWS) can be included1155 <ul class="empty"> 1156 <li>The grammar described by this specification is word-based. Except where noted otherwise, linear white space (LWS) can be included 1150 1157 between any two adjacent words (token or quoted-string), and between adjacent words and separators, without changing the interpretation 1151 1158 of a field. At least one delimiter (LWS and/or separators) <em class="bcp14">MUST</em> exist between any two tokens (for the definition of "token" below), since they would otherwise be interpreted as a single 1152 1159 token. 1153 </ dd>1154 </ dl>1160 </li> 1161 </ul> 1155 1162 <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a> <a id="basic.rules" href="#basic.rules">Basic Rules</a></h2> 1156 1163 <p id="rfc.section.2.2.p.1">The following rules are used throughout this specification to describe basic parsing constructs. The US-ASCII coded character … … 1235 1242 </p> 1236 1243 <p id="rfc.section.3.1.p.9"> </p> 1237 < dl class="empty">1238 < dd> <b>Note:</b> Converting between versions of HTTP may involve modification of header fields required or forbidden by the versions involved.1239 </ dd>1240 </ dl>1244 <ul class="empty"> 1245 <li> <b>Note:</b> Converting between versions of HTTP may involve modification of header fields required or forbidden by the versions involved. 1246 </li> 1247 </ul> 1241 1248 <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a> <a id="uri" href="#uri">Uniform Resource Identifiers</a></h2> 1242 1249 <p id="rfc.section.3.2.p.1">URIs have been known by many names: WWW addresses, Universal Document Identifiers, Universal Resource Identifiers <a href="#RFC1630" id="rfc.xref.RFC1630.2"><cite title="Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World-Wide Web">[RFC1630]</cite></a>, and finally the combination of Uniform Resource Locators (URL) <a href="#RFC1738" id="rfc.xref.RFC1738.2"><cite title="Uniform Resource Locators (URL)">[RFC1738]</cite></a> and Names (URN) <a href="#RFC1737" id="rfc.xref.RFC1737.2"><cite title="Functional Requirements for Uniform Resource Names">[RFC1737]</cite></a>. As far as HTTP is concerned, Uniform Resource Identifiers are simply formatted strings which identify--via name, location, … … 1252 1259 </p> 1253 1260 <p id="rfc.section.3.2.1.p.3"> </p> 1254 < dl class="empty">1255 < dd> <b>Note:</b> Servers ought to be cautious about depending on URI lengths above 255 bytes, because some older client or proxy implementations1261 <ul class="empty"> 1262 <li> <b>Note:</b> Servers ought to be cautious about depending on URI lengths above 255 bytes, because some older client or proxy implementations 1256 1263 might not properly support these lengths. 1257 </ dd>1258 </ dl>1264 </li> 1265 </ul> 1259 1266 <h3 id="rfc.section.3.2.2"><a href="#rfc.section.3.2.2">3.2.2</a> <a id="http.url" href="#http.url">http URL</a></h3> 1260 1267 <p id="rfc.section.3.2.2.p.1">The "http" scheme is used to locate network resources via the HTTP protocol. This section defines the scheme-specific syntax … … 1290 1297 </pre><p id="rfc.section.3.3.1.p.3">The first format is preferred as an Internet standard and represents a fixed-length subset of that defined by RFC 1123 <a href="#RFC1123" id="rfc.xref.RFC1123.1"><cite title="Requirements for Internet Hosts - Application and Support">[RFC1123]</cite></a> (an update to RFC 822 <a href="#RFC822" id="rfc.xref.RFC822.3"><cite title="Standard for the format of ARPA Internet text messages">[RFC822]</cite></a>). The second format is in common use, but is based on the obsolete RFC 850 <a href="#RFC1036" id="rfc.xref.RFC1036.1"><cite title="Standard for interchange of USENET messages">[RFC1036]</cite></a> date format and lacks a four-digit year. HTTP/1.1 clients and servers that parse the date value <em class="bcp14">MUST</em> accept all three formats (for compatibility with HTTP/1.0), though they <em class="bcp14">MUST</em> only generate the RFC 1123 format for representing HTTP-date values in header fields. See <a href="#tolerant.applications" title="Tolerant Applications">Appendix 19.3</a> for further information. 1291 1298 </p> 1292 < dl class="empty">1293 < dd> <b>Note:</b> Recipients of date values are encouraged to be robust in accepting date values that may have been sent by non-HTTP applications,1299 <ul class="empty"> 1300 <li> <b>Note:</b> Recipients of date values are encouraged to be robust in accepting date values that may have been sent by non-HTTP applications, 1294 1301 as is sometimes the case when retrieving or posting messages via proxies/gateways to SMTP or NNTP. 1295 </ dd>1296 </ dl>1302 </li> 1303 </ul> 1297 1304 <p id="rfc.section.3.3.1.p.5">All HTTP date/time stamps <em class="bcp14">MUST</em> be represented in Greenwich Mean Time (GMT), without exception. For the purposes of HTTP, GMT is exactly equal to UTC (Coordinated 1298 1305 Universal Time). This is indicated in the first two formats by the inclusion of "GMT" as the three-letter abbreviation for … … 1336 1343 to determine the exact mapping is not permitted. 1337 1344 </p> 1338 < dl class="empty">1339 < dd> <b>Note:</b> This use of the term "character set" is more commonly referred to as a "character encoding." However, since HTTP and MIME1345 <ul class="empty"> 1346 <li> <b>Note:</b> This use of the term "character set" is more commonly referred to as a "character encoding." However, since HTTP and MIME 1340 1347 share the same registry, it is important that the terminology also be shared. 1341 </ dd>1342 </ dl>1348 </li> 1349 </ul> 1343 1350 <p id="rfc.section.3.4.p.4">HTTP character sets are identified by case-insensitive tokens. The complete set of tokens is defined by the IANA Character 1344 1351 Set registry <a href="#RFC1700" id="rfc.xref.RFC1700.2"><cite title="Assigned Numbers">[RFC1700]</cite></a>. … … 1372 1379 <p id="rfc.section.3.5.p.5">gzip<span id="rfc.iref.g.40"></span> 1373 1380 </p> 1374 < dl class="empty">1375 < dd>An encoding format produced by the file compression program "gzip" (GNU zip) as described in RFC 1952 <a href="#RFC1952" id="rfc.xref.RFC1952.1"><cite title="GZIP file format specification version 4.3">[RFC1952]</cite></a>. This format is a Lempel-Ziv coding (LZ77) with a 32 bit CRC.1376 </ dd>1377 </ dl>1381 <ul class="empty"> 1382 <li>An encoding format produced by the file compression program "gzip" (GNU zip) as described in RFC 1952 <a href="#RFC1952" id="rfc.xref.RFC1952.1"><cite title="GZIP file format specification version 4.3">[RFC1952]</cite></a>. This format is a Lempel-Ziv coding (LZ77) with a 32 bit CRC. 1383 </li> 1384 </ul> 1378 1385 <p id="rfc.section.3.5.p.6">compress<span id="rfc.iref.c.6"></span> 1379 1386 </p> 1380 < dl class="empty">1381 < dd>The encoding format produced by the common UNIX file compression program "compress". This format is an adaptive Lempel-Ziv-Welch1387 <ul class="empty"> 1388 <li>The encoding format produced by the common UNIX file compression program "compress". This format is an adaptive Lempel-Ziv-Welch 1382 1389 coding (LZW). 1383 </ dd>1384 < dd>Use of program names for the identification of encoding formats is not desirable and is discouraged for future encodings.1390 </li> 1391 <li>Use of program names for the identification of encoding formats is not desirable and is discouraged for future encodings. 1385 1392 Their use here is representative of historical practice, not good design. For compatibility with previous implementations 1386 1393 of HTTP, applications <em class="bcp14">SHOULD</em> consider "x-gzip" and "x-compress" to be equivalent to "gzip" and "compress" respectively. 1387 </ dd>1388 </ dl>1394 </li> 1395 </ul> 1389 1396 <p id="rfc.section.3.5.p.7">deflate<span id="rfc.iref.d.2"></span> 1390 1397 </p> 1391 < dl class="empty">1392 < dd>The "zlib" format defined in RFC 1950 <a href="#RFC1950" id="rfc.xref.RFC1950.1"><cite title="ZLIB Compressed Data Format Specification version 3.3">[RFC1950]</cite></a> in combination with the "deflate" compression mechanism described in RFC 1951 <a href="#RFC1951" id="rfc.xref.RFC1951.1"><cite title="DEFLATE Compressed Data Format Specification version 1.3">[RFC1951]</cite></a>.1393 </ dd>1394 </ dl>1398 <ul class="empty"> 1399 <li>The "zlib" format defined in RFC 1950 <a href="#RFC1950" id="rfc.xref.RFC1950.1"><cite title="ZLIB Compressed Data Format Specification version 3.3">[RFC1950]</cite></a> in combination with the "deflate" compression mechanism described in RFC 1951 <a href="#RFC1951" id="rfc.xref.RFC1951.1"><cite title="DEFLATE Compressed Data Format Specification version 1.3">[RFC1951]</cite></a>. 1400 </li> 1401 </ul> 1395 1402 <p id="rfc.section.3.5.p.8">identity<span id="rfc.iref.i.2"></span> 1396 1403 </p> 1397 < dl class="empty">1398 < dd>The default (identity) encoding; the use of no transformation whatsoever. This content-coding is used only in the Accept-Encoding1404 <ul class="empty"> 1405 <li>The default (identity) encoding; the use of no transformation whatsoever. This content-coding is used only in the Accept-Encoding 1399 1406 header, and <em class="bcp14">SHOULD NOT</em> be used in the Content-Encoding header. 1400 </ dd>1401 </ dl>1407 </li> 1408 </ul> 1402 1409 <p id="rfc.section.3.5.p.9">New content-coding value tokens <em class="bcp14">SHOULD</em> be registered; to allow interoperability between clients and servers, specifications of the content coding algorithms needed 1403 1410 to implement a new value <em class="bcp14">SHOULD</em> be publicly available and adequate for independent implementation, and conform to the purpose of content coding defined in … … 1526 1533 an unrecognized multipart subtype, the application <em class="bcp14">MUST</em> treat it as being equivalent to "multipart/mixed". 1527 1534 </p> 1528 < dl class="empty">1529 < dd> <b>Note:</b> The "multipart/form-data" type has been specifically defined for carrying form data suitable for processing via the POST request1535 <ul class="empty"> 1536 <li> <b>Note:</b> The "multipart/form-data" type has been specifically defined for carrying form data suitable for processing via the POST request 1530 1537 method, as described in RFC 1867 <a href="#RFC1867" id="rfc.xref.RFC1867.1"><cite title="Form-based File Upload in HTML">[RFC1867]</cite></a>. 1531 </ dd>1532 </ dl>1538 </li> 1539 </ul> 1533 1540 <h2 id="rfc.section.3.8"><a href="#rfc.section.3.8">3.8</a> <a id="product.tokens" href="#product.tokens">Product Tokens</a></h2> 1534 1541 <p id="rfc.section.3.8.p.1">Product tokens are used to allow communicating applications to identify themselves by software name and version. Most fields … … 1686 1693 can parse multipart/byteranges responses. 1687 1694 </p> 1688 < dl class="empty">1689 < dd>A range header might be forwarded by a 1.0 proxy that does not understand multipart/byteranges; in this case the server <em class="bcp14">MUST</em> delimit the message using methods defined in items 1, 3 or 5 of this section.1690 </ dd>1691 </ dl>1695 <ul class="empty"> 1696 <li>A range header might be forwarded by a 1.0 proxy that does not understand multipart/byteranges; in this case the server <em class="bcp14">MUST</em> delimit the message using methods defined in items 1, 3 or 5 of this section. 1697 </li> 1698 </ul> 1692 1699 </li> 1693 1700 <li> … … 1791 1798 </p> 1792 1799 <p id="rfc.section.5.1.2.p.14"> </p> 1793 < dl class="empty">1794 < dd> <b>Note:</b> The "no rewrite" rule prevents the proxy from changing the meaning of the request when the origin server is improperly using1800 <ul class="empty"> 1801 <li> <b>Note:</b> The "no rewrite" rule prevents the proxy from changing the meaning of the request when the origin server is improperly using 1795 1802 a non-reserved URI character for a reserved purpose. Implementors should be aware that some pre-HTTP/1.1 proxies have been 1796 1803 known to rewrite the Request-URI. 1797 </ dd>1798 </ dl>1804 </li> 1805 </ul> 1799 1806 <h2 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2</a> <a id="the.resource.identified.by.a.request" href="#the.resource.identified.by.a.request">The Resource Identified by a Request</a></h2> 1800 1807 <p id="rfc.section.5.2.p.1">The exact resource identified by an Internet request is determined by examining both the Request-URI and the Host header field.</p> … … 2484 2491 GET or HEAD. A client <em class="bcp14">SHOULD</em> detect infinite redirection loops, since such loops generate network traffic for each redirection. 2485 2492 </p> 2486 < dl class="empty">2487 < dd> <b>Note:</b> previous versions of this specification recommended a maximum of five redirections. Content developers should be aware that2493 <ul class="empty"> 2494 <li> <b>Note:</b> previous versions of this specification recommended a maximum of five redirections. Content developers should be aware that 2488 2495 there might be clients that implement such a fixed limitation. 2489 </ dd>2490 </ dl>2496 </li> 2497 </ul> 2491 2498 <div id="rfc.iref.151"></div> 2492 2499 <div id="rfc.iref.s.13"></div> … … 2513 2520 the request was issued. 2514 2521 </p> 2515 < dl class="empty">2516 < dd> <b>Note:</b> When automatically redirecting a POST request after receiving a 301 status code, some existing HTTP/1.0 user agents will erroneously2522 <ul class="empty"> 2523 <li> <b>Note:</b> When automatically redirecting a POST request after receiving a 301 status code, some existing HTTP/1.0 user agents will erroneously 2517 2524 change it into a GET request. 2518 </ dd>2519 </ dl>2525 </li> 2526 </ul> 2520 2527 <div id="rfc.iref.153"></div> 2521 2528 <div id="rfc.iref.s.15"></div> … … 2530 2537 the request was issued. 2531 2538 </p> 2532 < dl class="empty">2533 < dd> <b>Note:</b> RFC 1945 and RFC 2068 specify that the client is not allowed to change the method on the redirected request. However, most2539 <ul class="empty"> 2540 <li> <b>Note:</b> RFC 1945 and RFC 2068 specify that the client is not allowed to change the method on the redirected request. However, most 2534 2541 existing user agent implementations treat 302 as if it were a 303 response, performing a GET on the Location field-value regardless 2535 2542 of the original request method. The status codes 303 and 307 have been added for servers that wish to make unambiguously clear 2536 2543 which kind of reaction is expected of the client. 2537 </ dd>2538 </ dl>2544 </li> 2545 </ul> 2539 2546 <div id="rfc.iref.154"></div> 2540 2547 <div id="rfc.iref.s.16"></div> … … 2546 2553 <p id="rfc.section.10.3.4.p.2">The different URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. Unless the request method was HEAD, the entity of the response <em class="bcp14">SHOULD</em> contain a short hypertext note with a hyperlink to the new URI(s). 2547 2554 </p> 2548 < dl class="empty">2549 < dd> <b>Note:</b> Many pre-HTTP/1.1 user agents do not understand the 303 status. When interoperability with such clients is a concern, the2555 <ul class="empty"> 2556 <li> <b>Note:</b> Many pre-HTTP/1.1 user agents do not understand the 303 status. When interoperability with such clients is a concern, the 2550 2557 302 status code may be used instead, since most user agents react to a 302 response as described here for 303. 2551 </ dd>2552 </ dl>2558 </li> 2559 </ul> 2553 2560 <div id="rfc.iref.155"></div> 2554 2561 <div id="rfc.iref.s.17"></div> … … 2582 2589 expected to repeat this single request via the proxy. 305 responses <em class="bcp14">MUST</em> only be generated by origin servers. 2583 2590 </p> 2584 < dl class="empty">2585 < dd> <b>Note:</b> RFC 2068 was not clear that 305 was intended to redirect a single request, and to be generated by origin servers only. Not2591 <ul class="empty"> 2592 <li> <b>Note:</b> RFC 2068 was not clear that 305 was intended to redirect a single request, and to be generated by origin servers only. Not 2586 2593 observing these limitations has significant security consequences. 2587 </ dd>2588 </ dl>2594 </li> 2595 </ul> 2589 2596 <div id="rfc.iref.157"></div> 2590 2597 <div id="rfc.iref.s.19"></div> … … 2660 2667 Depending upon the format and the capabilities of the user agent, selection of the most appropriate choice <em class="bcp14">MAY</em> be performed automatically. However, this specification does not define any standard for such automatic selection. 2661 2668 </p> 2662 < dl class="empty">2663 < dd> <b>Note:</b> HTTP/1.1 servers are allowed to return responses which are not acceptable according to the accept headers sent in the request.2669 <ul class="empty"> 2670 <li> <b>Note:</b> HTTP/1.1 servers are allowed to return responses which are not acceptable according to the accept headers sent in the request. 2664 2671 In some cases, this may even be preferable to sending a 406 response. User agents are encouraged to inspect the headers of 2665 2672 an incoming response to determine if it is acceptable. 2666 </ dd>2667 </ dl>2673 </li> 2674 </ul> 2668 2675 <p id="rfc.section.10.4.7.p.3">If the response could be unacceptable, a user agent <em class="bcp14">SHOULD</em> temporarily stop receipt of more data and query the user for a decision on further actions. 2669 2676 </p> … … 2783 2790 is that this is a temporary condition which will be alleviated after some delay. If known, the length of the delay <em class="bcp14">MAY</em> be indicated in a Retry-After header. If no Retry-After is given, the client <em class="bcp14">SHOULD</em> handle the response as it would for a 500 response. 2784 2791 </p> 2785 < dl class="empty">2786 < dd> <b>Note:</b> The existence of the 503 status code does not imply that a server must use it when becoming overloaded. Some servers may wish2792 <ul class="empty"> 2793 <li> <b>Note:</b> The existence of the 503 status code does not imply that a server must use it when becoming overloaded. Some servers may wish 2787 2794 to simply refuse the connection. 2788 </ dd>2789 </ dl>2795 </li> 2796 </ul> 2790 2797 <div id="rfc.iref.181"></div> 2791 2798 <div id="rfc.iref.s.43"></div> … … 2794 2801 URI (e.g. HTTP, FTP, LDAP) or some other auxiliary server (e.g. DNS) it needed to access in attempting to complete the request. 2795 2802 </p> 2796 < dl class="empty">2797 < dd> <b>Note:</b> Note to implementors: some deployed proxies are known to return 400 or 500 when DNS lookups time out.2798 </ dd>2799 </ dl>2803 <ul class="empty"> 2804 <li> <b>Note:</b> Note to implementors: some deployed proxies are known to return 400 or 500 when DNS lookups time out. 2805 </li> 2806 </ul> 2800 2807 <div id="rfc.iref.182"></div> 2801 2808 <div id="rfc.iref.s.44"></div> … … 2817 2824 best representation for a given response when there are multiple representations available. 2818 2825 </p> 2819 < dl class="empty">2820 < dd> <b>Note:</b> This is not called "format negotiation" because the alternate representations may be of the same media type, but use different2826 <ul class="empty"> 2827 <li> <b>Note:</b> This is not called "format negotiation" because the alternate representations may be of the same media type, but use different 2821 2828 capabilities of that type, be in different languages, etc. 2822 </ dd>2823 </ dl>2829 </li> 2830 </ul> 2824 2831 <p id="rfc.section.12.p.2">Any response containing an entity-body <em class="bcp14">MAY</em> be subject to negotiation, including error responses. 2825 2832 </p> … … 2920 2927 </ol> 2921 2928 <p id="rfc.section.13.p.5">A basic principle is that it must be possible for the clients to detect any potential relaxation of semantic transparency. </p> 2922 < dl class="empty">2923 < dd> <b>Note:</b> The server, cache, or client implementor might be faced with design decisions not explicitly discussed in this specification.2929 <ul class="empty"> 2930 <li> <b>Note:</b> The server, cache, or client implementor might be faced with design decisions not explicitly discussed in this specification. 2924 2931 If a decision might affect semantic transparency, the implementor ought to err on the side of maintaining transparency unless 2925 2932 a careful and complete analysis shows significant benefits in breaking transparency. 2926 </ dd>2927 </ dl>2933 </li> 2934 </ul> 2928 2935 <h2 id="rfc.section.13.1"><a href="#rfc.section.13.1">13.1</a> 2929 2936 </h2> … … 3199 3206 either that a method be performed if and only if a validator matches or if and only if no validators match. 3200 3207 </p> 3201 < dl class="empty">3202 < dd> <b>Note:</b> a response that lacks a validator may still be cached, and served from cache until it expires, unless this is explicitly prohibited3208 <ul class="empty"> 3209 <li> <b>Note:</b> a response that lacks a validator may still be cached, and served from cache until it expires, unless this is explicitly prohibited 3203 3210 by a cache-control directive. However, a cache cannot do a conditional retrieval if it does not have a validator for the entity, 3204 3211 which means it will not be refreshable after it expires. 3205 </ dd>3206 </ dl>3212 </li> 3213 </ul> 3207 3214 <h3 id="rfc.section.13.3.1"><a href="#rfc.section.13.3.1">13.3.1</a> <a id="last-modified.dates" href="#last-modified.dates">Last-Modified Dates</a></h3> 3208 3215 <p id="rfc.section.13.3.1.p.1">The Last-Modified entity-header field value is often used as a cache validator. In simple terms, a cache entry is considered … … 3231 3238 entity, while a weak validator is part of an identifier for a set of semantically equivalent entities. 3232 3239 </p> 3233 < dl class="empty">3234 < dd> <b>Note:</b> One example of a strong validator is an integer that is incremented in stable storage every time an entity is changed.3235 </ dd>3236 < dd>An entity's modification time, if represented with one-second resolution, could be a weak validator, since it is possible3240 <ul class="empty"> 3241 <li> <b>Note:</b> One example of a strong validator is an integer that is incremented in stable storage every time an entity is changed. 3242 </li> 3243 <li>An entity's modification time, if represented with one-second resolution, could be a weak validator, since it is possible 3237 3244 that the resource might be modified twice during a single second. 3238 </ dd>3239 < dd>Support for weak validators is optional. However, weak validators allow for more efficient caching of equivalent objects;3245 </li> 3246 <li>Support for weak validators is optional. However, weak validators allow for more efficient caching of equivalent objects; 3240 3247 for example, a hit counter on a site is probably good enough if it is updated every few days or weeks, and any value during 3241 3248 that period is likely "good enough" to be equivalent. 3242 </ dd>3243 </ dl>3249 </li> 3250 </ul> 3244 3251 <p id="rfc.section.13.3.3.p.4">A "use" of a validator is either when a client generates a request and includes the validator in a validating header field, 3245 3252 or when a server compares two validators. … … 3318 3325 <p id="rfc.section.13.3.4.p.4">In order to be legal, a strong entity tag <em class="bcp14">MUST</em> change whenever the associated entity value changes in any way. A weak entity tag <em class="bcp14">SHOULD</em> change whenever the associated entity changes in a semantically significant way. 3319 3326 </p> 3320 < dl class="empty">3321 < dd> <b>Note:</b> in order to provide semantically transparent caching, an origin server must avoid reusing a specific strong entity tag value3327 <ul class="empty"> 3328 <li> <b>Note:</b> in order to provide semantically transparent caching, an origin server must avoid reusing a specific strong entity tag value 3322 3329 for two different entities, or reusing a specific weak entity tag value for two semantically different entities. Cache entries 3323 3330 might persist for arbitrarily long periods, regardless of expiration times, so it might be inappropriate to expect that a 3324 3331 cache will never again attempt to validate an entry using a validator that it obtained at some point in the past. 3325 </ dd>3326 </ dl>3332 </li> 3333 </ul> 3327 3334 <p id="rfc.section.13.3.4.p.5">HTTP/1.1 clients: </p> 3328 3335 <ul> … … 3345 3352 fields in the request. 3346 3353 </p> 3347 < dl class="empty">3348 < dd> <b>Note:</b> The general principle behind these rules is that HTTP/1.1 servers and clients should transmit as much non-redundant information3354 <ul class="empty"> 3355 <li> <b>Note:</b> The general principle behind these rules is that HTTP/1.1 servers and clients should transmit as much non-redundant information 3349 3356 as is available in their responses and requests. HTTP/1.1 systems receiving this information will make the most conservative 3350 3357 assumptions about the validators they receive. 3351 </ dd>3352 < dd>HTTP/1.0 clients and caches will ignore entity tags. Generally, last-modified values received or used by these systems will3358 </li> 3359 <li>HTTP/1.0 clients and caches will ignore entity tags. Generally, last-modified values received or used by these systems will 3353 3360 support transparent and efficient caching, and so HTTP/1.1 origin servers should provide Last-Modified values. In those rare 3354 3361 cases where the use of a Last-Modified value as a validator by an HTTP/1.0 system could result in a serious problem, then 3355 3362 HTTP/1.1 origin servers should not provide one. 3356 </ dd>3357 </ dl>3363 </li> 3364 </ul> 3358 3365 <h3 id="rfc.section.13.3.5"><a href="#rfc.section.13.3.5">13.3.5</a> <a id="non-validating.conditionals" href="#non-validating.conditionals">Non-validating Conditionals</a></h3> 3359 3366 <p id="rfc.section.13.3.5.p.1">The principle behind entity tags is that only the service author knows the semantics of a resource well enough to select an … … 3367 3374 such a response was taken from a cache by comparing the Date header to the current time. 3368 3375 </p> 3369 < dl class="empty">3370 < dd> <b>Note:</b> some HTTP/1.0 caches are known to violate this expectation without providing any Warning.3371 </ dd>3372 </ dl>3376 <ul class="empty"> 3377 <li> <b>Note:</b> some HTTP/1.0 caches are known to violate this expectation without providing any Warning. 3378 </li> 3379 </ul> 3373 3380 <p id="rfc.section.13.4.p.2">However, in some cases it might be inappropriate for a cache to retain an entity, or to return it in response to a subsequent 3374 3381 request. This might be because absolute semantic transparency is deemed necessary by the service author, or because of security … … 3442 3449 <p id="rfc.section.13.5.2.p.6">A non-transparent proxy <em class="bcp14">MAY</em> modify or add these fields to a message that does not include no-transform, but if it does so, it <em class="bcp14">MUST</em> add a Warning 214 (Transformation applied) if one does not already appear in the message (see <a href="#header.warning" id="rfc.xref.header.warning.5" title="Warning">Section 14.46</a>). 3443 3450 </p> 3444 < dl class="empty">3445 < dd>Warning: unnecessary modification of end-to-end headers might cause authentication failures if stronger authentication mechanisms3451 <ul class="empty"> 3452 <li>Warning: unnecessary modification of end-to-end headers might cause authentication failures if stronger authentication mechanisms 3446 3453 are introduced in later versions of HTTP. Such authentication mechanisms <em class="bcp14">MAY</em> rely on the values of header fields not listed here. 3447 </ dd>3448 </ dl>3454 </li> 3455 </ul> 3449 3456 <p id="rfc.section.13.5.2.p.7">The Content-Length field of a request or response is added or deleted according to the rules in <a href="#message.length" title="Message Length">Section 4.4</a>. A transparent proxy <em class="bcp14">MUST</em> preserve the entity-length (<a href="#entity.length" title="Entity Length">Section 7.2.2</a>) of the entity-body, although it <em class="bcp14">MAY</em> change the transfer-length (<a href="#message.length" title="Message Length">Section 4.4</a>). 3450 3457 </p> … … 3473 3480 stored with the cache entry (except for stored Warning headers with warn-code 1xx, which are deleted even if not overridden). 3474 3481 </p> 3475 < dl class="empty">3476 < dd> <b>Note:</b> this rule allows an origin server to use a 304 (Not Modified) or a 206 (Partial Content) response to update any header associated3482 <ul class="empty"> 3483 <li> <b>Note:</b> this rule allows an origin server to use a 304 (Not Modified) or a 206 (Partial Content) response to update any header associated 3477 3484 with a previous response for the same entity or sub-ranges thereof, although it might not always be meaningful or correct 3478 3485 to do so. This rule does not allow an origin server to use a 304 (Not Modified) or a 206 (Partial Content) response to entirely 3479 3486 delete a header that it had provided with a previous response. 3480 </ dd>3481 </ dl>3487 </li> 3488 </ul> 3482 3489 <h3 id="rfc.section.13.5.4"><a href="#rfc.section.13.5.4">13.5.4</a> <a id="combining.byte.ranges" href="#combining.byte.ranges">Combining Byte Ranges</a></h3> 3483 3490 <p id="rfc.section.13.5.4.p.1">A response might transfer only a subrange of the bytes of an entity-body, either because the request included one or more … … 3589 3596 to be returned. If it inserts the new response into cache storage the rules in <a href="#combining.headers" title="Combining Headers">Section 13.5.3</a> apply. 3590 3597 </p> 3591 < dl class="empty">3592 < dd> <b>Note:</b> a new response that has an older Date header value than existing cached responses is not cacheable.3593 </ dd>3594 </ dl>3598 <ul class="empty"> 3599 <li> <b>Note:</b> a new response that has an older Date header value than existing cached responses is not cacheable. 3600 </li> 3601 </ul> 3595 3602 <h2 id="rfc.section.13.13"><a href="#rfc.section.13.13">13.13</a> <a id="history.lists" href="#history.lists">History Lists</a></h2> 3596 3603 <p id="rfc.section.13.13.p.1">User agents often have history mechanisms, such as "Back" buttons and history lists, which can be used to redisplay an entity … … 3604 3611 </p> 3605 3612 <p id="rfc.section.13.13.p.4">This is not to be construed to prohibit the history mechanism from telling the user that a view might be stale. </p> 3606 < dl class="empty">3607 < dd> <b>Note:</b> if history list mechanisms unnecessarily prevent users from viewing stale resources, this will tend to force service authors3613 <ul class="empty"> 3614 <li> <b>Note:</b> if history list mechanisms unnecessarily prevent users from viewing stale resources, this will tend to force service authors 3608 3615 to avoid using HTTP expiration controls and cache controls when they would otherwise like to. Service authors may consider 3609 3616 it important that users not be presented with error messages or warning messages when they use navigation controls (such as … … 3611 3618 user interface considerations may force service authors to resort to other means of preventing caching (e.g. "once-only" URLs) 3612 3619 in order not to suffer the effects of improperly functioning history mechanisms. 3613 </ dd>3614 </ dl>3620 </li> 3621 </ul> 3615 3622 <h1 id="rfc.section.14"><a href="#rfc.section.14">14.</a> <a id="header.fields" href="#header.fields">Header Field Definitions</a></h1> 3616 3623 <p id="rfc.section.14.p.1">This section defines the syntax and semantics of all standard HTTP/1.1 header fields. For entity-header fields, both sender … … 3640 3647 agent to indicate the relative degree of preference for that media-range, using the qvalue scale from 0 to 1 (<a href="#quality.values" title="Quality Values">Section 3.9</a>). The default value is q=1. 3641 3648 </p> 3642 < dl class="empty">3643 < dd> <b>Note:</b> Use of the "q" parameter name to separate media type parameters from Accept extension parameters is due to historical practice.3649 <ul class="empty"> 3650 <li> <b>Note:</b> Use of the "q" parameter name to separate media type parameters from Accept extension parameters is due to historical practice. 3644 3651 Although this prevents any media type parameter named "q" from being used with a media range, such an event is believed to 3645 3652 be unlikely given the lack of any "q" parameters in the IANA media type registry and the rare usage of any media type parameters 3646 3653 in Accept. Future media types are discouraged from registering any parameter named "q". 3647 </ dd>3648 </ dl>3654 </li> 3655 </ul> 3649 3656 <p id="rfc.section.14.1.p.5">The example</p> 3650 3657 <div id="rfc.figure.u.61"></div><pre class="text"> Accept: audio/*; q=0.2, audio/basic … … 3742 3749 client. 3743 3750 </p> 3744 < dl class="empty">3745 < dd> <b>Note:</b> If the request does not include an Accept-Encoding field, and if the "identity" content-coding is unavailable, then content-codings3751 <ul class="empty"> 3752 <li> <b>Note:</b> If the request does not include an Accept-Encoding field, and if the "identity" content-coding is unavailable, then content-codings 3746 3753 commonly understood by HTTP/1.0 clients (i.e., "gzip" and "compress") are preferred; some older clients improperly display 3747 3754 messages sent with other content-codings. The server might also make this decision based on information about the particular 3748 3755 user-agent or client. 3749 </ dd>3750 < dd> <b>Note:</b> Most HTTP/1.0 applications do not recognize or obey qvalues associated with content-codings. This means that qvalues will3756 </li> 3757 <li> <b>Note:</b> Most HTTP/1.0 applications do not recognize or obey qvalues associated with content-codings. This means that qvalues will 3751 3758 not work and are not permitted with x-gzip or x-compress. 3752 </ dd>3753 </ dl>3759 </li> 3760 </ul> 3754 3761 <div id="rfc.iref.a.5"></div> 3755 3762 <div id="rfc.iref.h.6"></div> … … 3770 3777 range present in the Accept-Language field. 3771 3778 </p> 3772 < dl class="empty">3773 < dd> <b>Note:</b> This use of a prefix matching rule does not imply that language tags are assigned to languages in such a way that it is always3779 <ul class="empty"> 3780 <li> <b>Note:</b> This use of a prefix matching rule does not imply that language tags are assigned to languages in such a way that it is always 3774 3781 true that if a user understands a language with a certain tag, then this user will also understand all languages with tags 3775 3782 for which this tag is a prefix. The prefix rule simply allows the use of prefix tags if this is the case. 3776 </ dd>3777 </ dl>3783 </li> 3784 </ul> 3778 3785 <p id="rfc.section.14.4.p.6">The language quality factor assigned to a language-tag by the Accept-Language field is the quality value of the longest language-range 3779 3786 in the field that matches the language-tag. If no language-range in the field matches the tag, the language quality factor … … 3787 3794 of linguistic preference available to the user. If the choice is not made available, then the Accept-Language header field <em class="bcp14">MUST NOT</em> be given in the request. 3788 3795 </p> 3789 < dl class="empty">3790 < dd> <b>Note:</b> When making the choice of linguistic preference available to the user, we remind implementors of the fact that users are not3796 <ul class="empty"> 3797 <li> <b>Note:</b> When making the choice of linguistic preference available to the user, we remind implementors of the fact that users are not 3791 3798 familiar with the details of language matching as described above, and should provide appropriate guidance. As an example, 3792 3799 users might assume that on selecting "en-gb", they will be served any kind of English document if British English is not available. 3793 3800 A user agent might suggest in such a case to add "en" to get the best matching behavior. 3794 </ dd>3795 </ dl>3801 </li> 3802 </ul> 3796 3803 <div id="rfc.iref.a.6"></div> 3797 3804 <div id="rfc.iref.h.7"></div> … … 3871 3878 is to be given in the response. 3872 3879 </p> 3873 < dl class="empty">3874 < dd>Note that HTTP/1.0 caches might not implement Cache-Control and might only implement Pragma: no-cache (see <a href="#header.pragma" id="rfc.xref.header.pragma.2" title="Pragma">Section 14.32</a>).3875 </ dd>3876 </ dl>3880 <ul class="empty"> 3881 <li>Note that HTTP/1.0 caches might not implement Cache-Control and might only implement Pragma: no-cache (see <a href="#header.pragma" id="rfc.xref.header.pragma.2" title="Pragma">Section 14.32</a>). 3882 </li> 3883 </ul> 3877 3884 <p id="rfc.section.14.9.p.2">Cache directives <em class="bcp14">MUST</em> be passed through by a proxy or gateway application, regardless of their significance to that application, since the directives 3878 3885 might be applicable to all recipients along the request/response chain. It is not possible to specify a cache-directive for … … 3928 3935 <p id="rfc.section.14.9.1.p.2"> <span id="rfc.iref.c.9"></span> <span id="rfc.iref.p.4"></span> public 3929 3936 </p> 3930 < dl class="empty">3931 < dd>Indicates that the response <em class="bcp14">MAY</em> be cached by any cache, even if it would normally be non-cacheable or cacheable only within a non-shared cache. (See also3937 <ul class="empty"> 3938 <li>Indicates that the response <em class="bcp14">MAY</em> be cached by any cache, even if it would normally be non-cacheable or cacheable only within a non-shared cache. (See also 3932 3939 Authorization, <a href="#header.authorization" id="rfc.xref.header.authorization.4" title="Authorization">Section 14.8</a>, for additional details.) 3933 </ dd>3934 </ dl>3940 </li> 3941 </ul> 3935 3942 <p id="rfc.section.14.9.1.p.3"> <span id="rfc.iref.c.10"></span> <span id="rfc.iref.p.5"></span> private 3936 3943 </p> 3937 < dl class="empty">3938 < dd>Indicates that all or part of the response message is intended for a single user and <em class="bcp14">MUST NOT</em> be cached by a shared cache. This allows an origin server to state that the specified parts of the response are intended for3944 <ul class="empty"> 3945 <li>Indicates that all or part of the response message is intended for a single user and <em class="bcp14">MUST NOT</em> be cached by a shared cache. This allows an origin server to state that the specified parts of the response are intended for 3939 3946 only one user and are not a valid response for requests by other users. A private (non-shared) cache <em class="bcp14">MAY</em> cache the response. 3940 </ dd>3941 < dd> <b>Note:</b> This usage of the word private only controls where the response may be cached, and cannot ensure the privacy of the message3947 </li> 3948 <li> <b>Note:</b> This usage of the word private only controls where the response may be cached, and cannot ensure the privacy of the message 3942 3949 content. 3943 </ dd>3944 </ dl>3950 </li> 3951 </ul> 3945 3952 <p id="rfc.section.14.9.1.p.4"> <span id="rfc.iref.c.11"></span> <span id="rfc.iref.n.1"></span> no-cache 3946 3953 </p> 3947 < dl class="empty">3948 < dd>If the no-cache directive does not specify a field-name, then a cache <em class="bcp14">MUST NOT</em> use the response to satisfy a subsequent request without successful revalidation with the origin server. This allows an origin3954 <ul class="empty"> 3955 <li>If the no-cache directive does not specify a field-name, then a cache <em class="bcp14">MUST NOT</em> use the response to satisfy a subsequent request without successful revalidation with the origin server. This allows an origin 3949 3956 server to prevent caching even by caches that have been configured to return stale responses to client requests. 3950 </ dd>3951 < dd>If the no-cache directive does specify one or more field-names, then a cache <em class="bcp14">MAY</em> use the response to satisfy a subsequent request, subject to any other restrictions on caching. However, the specified field-name(s) <em class="bcp14">MUST NOT</em> be sent in the response to a subsequent request without successful revalidation with the origin server. This allows an origin3957 </li> 3958 <li>If the no-cache directive does specify one or more field-names, then a cache <em class="bcp14">MAY</em> use the response to satisfy a subsequent request, subject to any other restrictions on caching. However, the specified field-name(s) <em class="bcp14">MUST NOT</em> be sent in the response to a subsequent request without successful revalidation with the origin server. This allows an origin 3952 3959 server to prevent the re-use of certain header fields in a response, while still allowing caching of the rest of the response. 3953 < dl class="empty">3954 < dd> <b>Note:</b> Most HTTP/1.0 caches will not recognize or obey this directive.3955 </ dd>3956 </ dl>3957 </ dd>3958 </ dl>3960 <ul class="empty"> 3961 <li> <b>Note:</b> Most HTTP/1.0 caches will not recognize or obey this directive. 3962 </li> 3963 </ul> 3964 </li> 3965 </ul> 3959 3966 <h3 id="rfc.section.14.9.2"><a href="#rfc.section.14.9.2">14.9.2</a> <a id="what.may.be.stored.by.caches" href="#what.may.be.stored.by.caches">What May be Stored by Caches</a></h3> 3960 3967 <p id="rfc.section.14.9.2.p.1"> <span id="rfc.iref.c.12"></span> <span id="rfc.iref.n.2"></span> no-store 3961 3968 </p> 3962 < dl class="empty">3963 < dd>The purpose of the no-store directive is to prevent the inadvertent release or retention of sensitive information (for example,3969 <ul class="empty"> 3970 <li>The purpose of the no-store directive is to prevent the inadvertent release or retention of sensitive information (for example, 3964 3971 on backup tapes). The no-store directive applies to the entire message, and <em class="bcp14">MAY</em> be sent either in a response or in a request. If sent in a request, a cache <em class="bcp14">MUST NOT</em> store any part of either this request or any response to it. If sent in a response, a cache <em class="bcp14">MUST NOT</em> store any part of either this response or the request that elicited it. This directive applies to both non-shared and shared 3965 3972 caches. "<em class="bcp14">MUST NOT</em> store" in this context means that the cache <em class="bcp14">MUST NOT</em> intentionally store the information in non-volatile storage, and <em class="bcp14">MUST</em> make a best-effort attempt to remove the information from volatile storage as promptly as possible after forwarding it. 3966 </ dd>3967 < dd>Even when this directive is associated with a response, users might explicitly store such a response outside of the caching3973 </li> 3974 <li>Even when this directive is associated with a response, users might explicitly store such a response outside of the caching 3968 3975 system (e.g., with a "Save As" dialog). History buffers <em class="bcp14">MAY</em> store such responses as part of their normal operation. 3969 </ dd>3970 < dd>The purpose of this directive is to meet the stated requirements of certain users and service authors who are concerned about3976 </li> 3977 <li>The purpose of this directive is to meet the stated requirements of certain users and service authors who are concerned about 3971 3978 accidental releases of information via unanticipated accesses to cache data structures. While the use of this directive might 3972 3979 improve privacy in some cases, we caution that it is NOT in any way a reliable or sufficient mechanism for ensuring privacy. 3973 3980 In particular, malicious or compromised caches might not recognize or obey this directive, and communications networks might 3974 3981 be vulnerable to eavesdropping. 3975 </ dd>3976 </ dl>3982 </li> 3983 </ul> 3977 3984 <h3 id="rfc.section.14.9.3"><a href="#rfc.section.14.9.3">14.9.3</a> <a id="modifications.of.the.basic.expiration.mechanism" href="#modifications.of.the.basic.expiration.mechanism">Modifications of the Basic Expiration Mechanism</a></h3> 3978 3985 <p id="rfc.section.14.9.3.p.1">The expiration time of an entity <em class="bcp14">MAY</em> be specified by the origin server using the Expires header (see <a href="#header.expires" id="rfc.xref.header.expires.3" title="Expires">Section 14.21</a>). Alternatively, it <em class="bcp14">MAY</em> be specified using the max-age directive in a response. When the max-age cache-control directive is present in a cached response, … … 3990 3997 does not include a Cache-Control header field, it <em class="bcp14">SHOULD</em> consider the response to be non-cacheable in order to retain compatibility with HTTP/1.0 servers. 3991 3998 </p> 3992 < dl class="empty">3993 < dd> <b>Note:</b> An origin server might wish to use a relatively new HTTP cache control feature, such as the "private" directive, on a network3999 <ul class="empty"> 4000 <li> <b>Note:</b> An origin server might wish to use a relatively new HTTP cache control feature, such as the "private" directive, on a network 3994 4001 including older caches that do not understand that feature. The origin server will need to combine the new feature with an 3995 4002 Expires field whose value is less than or equal to the Date value. This will prevent older caches from improperly caching 3996 4003 the response. 3997 </ dd>3998 </ dl>4004 </li> 4005 </ul> 3999 4006 <p id="rfc.section.14.9.3.p.4"> <span id="rfc.iref.c.13"></span> <span id="rfc.iref.s.45"></span> s-maxage 4000 4007 </p> 4001 < dl class="empty">4002 < dd>If a response includes an s-maxage directive, then for a shared cache (but not for a private cache), the maximum age specified4008 <ul class="empty"> 4009 <li>If a response includes an s-maxage directive, then for a shared cache (but not for a private cache), the maximum age specified 4003 4010 by this directive overrides the maximum age specified by either the max-age directive or the Expires header. The s-maxage 4004 4011 directive also implies the semantics of the proxy-revalidate directive (see <a href="#cache.revalidation.and.reload.controls" title="Cache Revalidation and Reload Controls">Section 14.9.4</a>), i.e., that the shared cache must not use the entry after it becomes stale to respond to a subsequent request without first 4005 4012 revalidating it with the origin server. The s-maxage directive is always ignored by a private cache. 4006 </ dd>4007 </ dl>4013 </li> 4014 </ul> 4008 4015 <p id="rfc.section.14.9.3.p.5">Note that most older caches, not compliant with this specification, do not implement any cache-control directives. An origin 4009 4016 server wishing to use a cache-control directive that restricts, but does not prevent, caching by an HTTP/1.1-compliant cache <em class="bcp14">MAY</em> exploit the requirement that the max-age directive overrides the Expires header, and the fact that pre-HTTP/1.1-compliant … … 4014 4021 <p id="rfc.section.14.9.3.p.7"> <span id="rfc.iref.c.14"></span> <span id="rfc.iref.m.10"></span> max-age 4015 4022 </p> 4016 < dl class="empty">4017 < dd>Indicates that the client is willing to accept a response whose age is no greater than the specified time in seconds. Unless4023 <ul class="empty"> 4024 <li>Indicates that the client is willing to accept a response whose age is no greater than the specified time in seconds. Unless 4018 4025 max-stale directive is also included, the client is not willing to accept a stale response. 4019 </ dd>4020 </ dl>4026 </li> 4027 </ul> 4021 4028 <p id="rfc.section.14.9.3.p.8"> <span id="rfc.iref.c.15"></span> <span id="rfc.iref.m.11"></span> min-fresh 4022 4029 </p> 4023 < dl class="empty">4024 < dd>Indicates that the client is willing to accept a response whose freshness lifetime is no less than its current age plus the4030 <ul class="empty"> 4031 <li>Indicates that the client is willing to accept a response whose freshness lifetime is no less than its current age plus the 4025 4032 specified time in seconds. That is, the client wants a response that will still be fresh for at least the specified number 4026 4033 of seconds. 4027 </ dd>4028 </ dl>4034 </li> 4035 </ul> 4029 4036 <p id="rfc.section.14.9.3.p.9"> <span id="rfc.iref.c.16"></span> <span id="rfc.iref.m.12"></span> max-stale 4030 4037 </p> 4031 < dl class="empty">4032 < dd>Indicates that the client is willing to accept a response that has exceeded its expiration time. If max-stale is assigned4038 <ul class="empty"> 4039 <li>Indicates that the client is willing to accept a response that has exceeded its expiration time. If max-stale is assigned 4033 4040 a value, then the client is willing to accept a response that has exceeded its expiration time by no more than the specified 4034 4041 number of seconds. If no value is assigned to max-stale, then the client is willing to accept a stale response of any age. 4035 </ dd>4036 </ dl>4042 </li> 4043 </ul> 4037 4044 <p id="rfc.section.14.9.3.p.10">If a cache returns a stale response, either because of a max-stale directive on a request, or because the cache is configured 4038 4045 to override the expiration time of a response, the cache <em class="bcp14">MUST</em> attach a Warning header to the stale response, using Warning 110 (Response is stale). … … 4056 4063 <p id="rfc.section.14.9.4.p.3">The client can specify these three kinds of action using Cache-Control request directives:</p> 4057 4064 <p id="rfc.section.14.9.4.p.4">End-to-end reload </p> 4058 < dl class="empty">4059 < dd>The request includes a "no-cache" cache-control directive or, for compatibility with HTTP/1.0 clients, "Pragma: no-cache".4065 <ul class="empty"> 4066 <li>The request includes a "no-cache" cache-control directive or, for compatibility with HTTP/1.0 clients, "Pragma: no-cache". 4060 4067 Field names <em class="bcp14">MUST NOT</em> be included with the no-cache directive in a request. The server <em class="bcp14">MUST NOT</em> use a cached copy when responding to such a request. 4061 </ dd>4062 </ dl>4068 </li> 4069 </ul> 4063 4070 <p id="rfc.section.14.9.4.p.5">Specific end-to-end revalidation </p> 4064 < dl class="empty">4065 < dd>The request includes a "max-age=0" cache-control directive, which forces each cache along the path to the origin server to4071 <ul class="empty"> 4072 <li>The request includes a "max-age=0" cache-control directive, which forces each cache along the path to the origin server to 4066 4073 revalidate its own entry, if any, with the next cache or server. The initial request includes a cache-validating conditional 4067 4074 with the client's current validator. 4068 </ dd>4069 </ dl>4075 </li> 4076 </ul> 4070 4077 <p id="rfc.section.14.9.4.p.6">Unspecified end-to-end revalidation </p> 4071 < dl class="empty">4072 < dd>The request includes "max-age=0" cache-control directive, which forces each cache along the path to the origin server to revalidate4078 <ul class="empty"> 4079 <li>The request includes "max-age=0" cache-control directive, which forces each cache along the path to the origin server to revalidate 4073 4080 its own entry, if any, with the next cache or server. The initial request does not include a cache-validating conditional; 4074 4081 the first cache along the path (if any) that holds a cache entry for this resource includes a cache-validating conditional 4075 4082 with its current validator. 4076 </ dd>4077 </ dl>4083 </li> 4084 </ul> 4078 4085 <p id="rfc.section.14.9.4.p.7"> <span id="rfc.iref.c.17"></span> <span id="rfc.iref.m.13"></span> max-age 4079 4086 </p> 4080 < dl class="empty">4081 < dd>When an intermediate cache is forced, by means of a max-age=0 directive, to revalidate its own cache entry, and the client4087 <ul class="empty"> 4088 <li>When an intermediate cache is forced, by means of a max-age=0 directive, to revalidate its own cache entry, and the client 4082 4089 has supplied its own validator in the request, the supplied validator might differ from the validator currently stored with 4083 4090 the cache entry. In this case, the cache <em class="bcp14">MAY</em> use either validator in making its own request without affecting semantic transparency. 4084 </ dd>4085 < dd>However, the choice of validator might affect performance. The best approach is for the intermediate cache to use its own4091 </li> 4092 <li>However, the choice of validator might affect performance. The best approach is for the intermediate cache to use its own 4086 4093 validator when making its request. If the server replies with 304 (Not Modified), then the cache can return its now validated 4087 4094 copy to the client with a 200 (OK) response. If the server replies with a new entity and cache validator, however, the intermediate … … 4089 4096 If the client's validator is equal to the origin server's, then the intermediate cache simply returns 304 (Not Modified). 4090 4097 Otherwise, it returns the new entity with a 200 (OK) response. 4091 </ dd>4092 < dd>If a request includes the no-cache directive, it <em class="bcp14">SHOULD NOT</em> include min-fresh, max-stale, or max-age.4093 </ dd>4094 </ dl>4098 </li> 4099 <li>If a request includes the no-cache directive, it <em class="bcp14">SHOULD NOT</em> include min-fresh, max-stale, or max-age. 4100 </li> 4101 </ul> 4095 4102 <p id="rfc.section.14.9.4.p.8"> <span id="rfc.iref.c.18"></span> <span id="rfc.iref.o.4"></span> only-if-cached 4096 4103 </p> 4097 < dl class="empty">4098 < dd>In some cases, such as times of extremely poor network connectivity, a client may want a cache to return only those responses4104 <ul class="empty"> 4105 <li>In some cases, such as times of extremely poor network connectivity, a client may want a cache to return only those responses 4099 4106 that it currently has stored, and not to reload or revalidate with the origin server. To do this, the client may include the 4100 4107 only-if-cached directive in a request. If it receives this directive, a cache <em class="bcp14">SHOULD</em> either respond using a cached entry that is consistent with the other constraints of the request, or respond with a 504 (Gateway 4101 4108 Timeout) status. However, if a group of caches is being operated as a unified system with good internal connectivity, such 4102 4109 a request <em class="bcp14">MAY</em> be forwarded within that group of caches. 4103 </ dd>4104 </ dl>4110 </li> 4111 </ul> 4105 4112 <p id="rfc.section.14.9.4.p.9"> <span id="rfc.iref.c.19"></span> <span id="rfc.iref.m.14"></span> must-revalidate 4106 4113 </p> 4107 < dl class="empty">4108 < dd>Because a cache <em class="bcp14">MAY</em> be configured to ignore a server's specified expiration time, and because a client request <em class="bcp14">MAY</em> include a max-stale directive (which has a similar effect), the protocol also includes a mechanism for the origin server to4114 <ul class="empty"> 4115 <li>Because a cache <em class="bcp14">MAY</em> be configured to ignore a server's specified expiration time, and because a client request <em class="bcp14">MAY</em> include a max-stale directive (which has a similar effect), the protocol also includes a mechanism for the origin server to 4109 4116 require revalidation of a cache entry on any subsequent use. When the must-revalidate directive is present in a response received 4110 4117 by a cache, that cache <em class="bcp14">MUST NOT</em> use the entry after it becomes stale to respond to a subsequent request without first revalidating it with the origin server. 4111 4118 (I.e., the cache <em class="bcp14">MUST</em> do an end-to-end revalidation every time, if, based solely on the origin server's Expires or max-age value, the cached response 4112 4119 is stale.) 4113 </ dd>4114 < dd>The must-revalidate directive is necessary to support reliable operation for certain protocol features. In all circumstances4120 </li> 4121 <li>The must-revalidate directive is necessary to support reliable operation for certain protocol features. In all circumstances 4115 4122 an HTTP/1.1 cache <em class="bcp14">MUST</em> obey the must-revalidate directive; in particular, if the cache cannot reach the origin server for any reason, it <em class="bcp14">MUST</em> generate a 504 (Gateway Timeout) response. 4116 </ dd>4117 < dd>Servers <em class="bcp14">SHOULD</em> send the must-revalidate directive if and only if failure to revalidate a request on the entity could result in incorrect4123 </li> 4124 <li>Servers <em class="bcp14">SHOULD</em> send the must-revalidate directive if and only if failure to revalidate a request on the entity could result in incorrect 4118 4125 operation, such as a silently unexecuted financial transaction. Recipients <em class="bcp14">MUST NOT</em> take any automated action that violates this directive, and <em class="bcp14">MUST NOT</em> automatically provide an unvalidated copy of the entity if revalidation fails. 4119 </ dd>4120 < dd>Although this is not recommended, user agents operating under severe connectivity constraints <em class="bcp14">MAY</em> violate this directive but, if so, <em class="bcp14">MUST</em> explicitly warn the user that an unvalidated response has been provided. The warning <em class="bcp14">MUST</em> be provided on each unvalidated access, and <em class="bcp14">SHOULD</em> require explicit user confirmation.4121 </ dd>4122 </ dl>4126 </li> 4127 <li>Although this is not recommended, user agents operating under severe connectivity constraints <em class="bcp14">MAY</em> violate this directive but, if so, <em class="bcp14">MUST</em> explicitly warn the user that an unvalidated response has been provided. The warning <em class="bcp14">MUST</em> be provided on each unvalidated access, and <em class="bcp14">SHOULD</em> require explicit user confirmation. 4128 </li> 4129 </ul> 4123 4130 <p id="rfc.section.14.9.4.p.10"> <span id="rfc.iref.c.20"></span> <span id="rfc.iref.p.6"></span> proxy-revalidate 4124 4131 </p> 4125 < dl class="empty">4126 < dd>The proxy-revalidate directive has the same meaning as the must-revalidate directive, except that it does not apply to non-shared4132 <ul class="empty"> 4133 <li>The proxy-revalidate directive has the same meaning as the must-revalidate directive, except that it does not apply to non-shared 4127 4134 user agent caches. It can be used on a response to an authenticated request to permit the user's cache to store and later 4128 4135 return the response without needing to revalidate it (since it has already been authenticated once by that user), while still … … 4130 4137 Note that such authenticated responses also need the public cache control directive in order to allow them to be cached at 4131 4138 all. 4132 </ dd>4133 </ dl>4139 </li> 4140 </ul> 4134 4141 <h3 id="rfc.section.14.9.5"><a href="#rfc.section.14.9.5">14.9.5</a> <a id="no-transform.directive" href="#no-transform.directive">No-Transform Directive</a></h3> 4135 4142 <p id="rfc.section.14.9.5.p.1"> <span id="rfc.iref.c.21"></span> <span id="rfc.iref.n.3"></span> no-transform 4136 4143 </p> 4137 < dl class="empty">4138 < dd>Implementors of intermediate caches (proxies) have found it useful to convert the media type of certain entity bodies. A non-transparent4144 <ul class="empty"> 4145 <li>Implementors of intermediate caches (proxies) have found it useful to convert the media type of certain entity bodies. A non-transparent 4139 4146 proxy might, for example, convert between image formats in order to save cache space or to reduce the amount of traffic on 4140 4147 a slow link. 4141 </ dd>4142 < dd>Serious operational problems occur, however, when these transformations are applied to entity bodies intended for certain4148 </li> 4149 <li>Serious operational problems occur, however, when these transformations are applied to entity bodies intended for certain 4143 4150 kinds of applications. For example, applications for medical imaging, scientific data analysis and those using end-to-end 4144 4151 authentication, all depend on receiving an entity body that is bit for bit identical to the original entity-body. 4145 </ dd>4146 < dd>Therefore, if a message includes the no-transform directive, an intermediate cache or proxy <em class="bcp14">MUST NOT</em> change those headers that are listed in <a href="#non-modifiable.headers" title="Non-modifiable Headers">Section 13.5.2</a> as being subject to the no-transform directive. This implies that the cache or proxy <em class="bcp14">MUST NOT</em> change any aspect of the entity-body that is specified by these headers, including the value of the entity-body itself.4147 </ dd>4148 </ dl>4152 </li> 4153 <li>Therefore, if a message includes the no-transform directive, an intermediate cache or proxy <em class="bcp14">MUST NOT</em> change those headers that are listed in <a href="#non-modifiable.headers" title="Non-modifiable Headers">Section 13.5.2</a> as being subject to the no-transform directive. This implies that the cache or proxy <em class="bcp14">MUST NOT</em> change any aspect of the entity-body that is specified by these headers, including the value of the entity-body itself. 4154 </li> 4155 </ul> 4149 4156 <h3 id="rfc.section.14.9.6"><a href="#rfc.section.14.9.6">14.9.6</a> <a id="cache.control.extensions" href="#cache.control.extensions">Cache Control Extensions</a></h3> 4150 4157 <p id="rfc.section.14.9.6.p.1">The Cache-Control header field can be extended through the use of one or more cache-extension tokens, each with an optional … … 4311 4318 <p id="rfc.section.14.15.p.8">Conversion of all line breaks to CRLF <em class="bcp14">MUST NOT</em> be done before computing or checking the digest: the line break convention used in the text actually transmitted <em class="bcp14">MUST</em> be left unaltered when computing the digest. 4312 4319 </p> 4313 < dl class="empty">4314 < dd> <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 several4320 <ul class="empty"> 4321 <li> <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 4315 4322 ways in which the application of Content-MD5 to HTTP entity-bodies differs from its application to MIME entity-bodies. One 4316 4323 is that HTTP, unlike MIME, does not use Content-Transfer-Encoding, and does use Transfer-Encoding and Content-Encoding. Another … … 4318 4325 used to compute the digest is the transmission byte order defined for the type. Lastly, HTTP allows transmission of text types 4319 4326 with any of several line break conventions and not just the canonical form using CRLF. 4320 </ dd>4321 </ dl>4327 </li> 4328 </ul> 4322 4329 <div id="rfc.iref.c.28"></div> 4323 4330 <div id="rfc.iref.h.18"></div> … … 4387 4394 resource), it <em class="bcp14">SHOULD</em> return a response code of 416 (Requested range not satisfiable) (<a href="#status.416" id="rfc.xref.status.416.2" title="416 Requested Range Not Satisfiable">Section 10.4.17</a>). 4388 4395 </p> 4389 < dl class="empty">4390 < dd> <b>Note:</b> clients cannot depend on servers to send a 416 (Requested range not satisfiable) response instead of a 200 (OK) response for4396 <ul class="empty"> 4397 <li> <b>Note:</b> clients cannot depend on servers to send a 416 (Requested range not satisfiable) response instead of a 200 (OK) response for 4391 4398 an unsatisfiable Range request-header, since not all servers implement this request-header. 4392 </ dd>4393 </ dl>4399 </li> 4400 </ul> 4394 4401 <div id="rfc.iref.c.29"></div> 4395 4402 <div id="rfc.iref.h.19"></div> … … 4492 4499 <div id="rfc.figure.u.107"></div><pre class="text"> Expires: Thu, 01 Dec 1994 16:00:00 GMT 4493 4500 </pre><p id="rfc.section.14.21.p.7"> </p> 4494 < dl class="empty">4495 < dd> <b>Note:</b> if a response includes a Cache-Control field with the max-age directive (see <a href="#modifications.of.the.basic.expiration.mechanism" title="Modifications of the Basic Expiration Mechanism">Section 14.9.3</a>), that directive overrides the Expires field.4496 </ dd>4497 </ dl>4501 <ul class="empty"> 4502 <li> <b>Note:</b> if a response includes a Cache-Control field with the max-age directive (see <a href="#modifications.of.the.basic.expiration.mechanism" title="Modifications of the Basic Expiration Mechanism">Section 14.9.3</a>), that directive overrides the Expires field. 4503 </li> 4504 </ul> 4498 4505 <p id="rfc.section.14.21.p.8">HTTP/1.1 clients and caches <em class="bcp14">MUST</em> treat other invalid date formats, especially including the value "0", as in the past (i.e., "already expired"). 4499 4506 </p> … … 4604 4611 </ol> 4605 4612 <p id="rfc.section.14.25.p.6">The purpose of this feature is to allow efficient updates of cached information with a minimum amount of transaction overhead. </p> 4606 < dl class="empty">4607 < dd> <b>Note:</b> The Range request-header field modifies the meaning of If-Modified-Since; see <a href="#header.range" id="rfc.xref.header.range.6" title="Range">Section 14.35</a> for full details.4608 </ dd>4609 < dd> <b>Note:</b> If-Modified-Since times are interpreted by the server, whose clock might not be synchronized with the client.4610 </ dd>4611 < dd> <b>Note:</b> When handling an If-Modified-Since header field, some servers will use an exact date comparison function, rather than a less-than4613 <ul class="empty"> 4614 <li> <b>Note:</b> The Range request-header field modifies the meaning of If-Modified-Since; see <a href="#header.range" id="rfc.xref.header.range.6" title="Range">Section 14.35</a> for full details. 4615 </li> 4616 <li> <b>Note:</b> If-Modified-Since times are interpreted by the server, whose clock might not be synchronized with the client. 4617 </li> 4618 <li> <b>Note:</b> When handling an If-Modified-Since header field, some servers will use an exact date comparison function, rather than a less-than 4612 4619 function, for deciding whether to send a 304 (Not Modified) response. To get best results when sending an If-Modified-Since 4613 4620 header field for cache validation, clients are advised to use the exact date string received in a previous Last-Modified header 4614 4621 field whenever possible. 4615 </ dd>4616 < dd> <b>Note:</b> If a client uses an arbitrary date in the If-Modified-Since header instead of a date taken from the Last-Modified header for4622 </li> 4623 <li> <b>Note:</b> If a client uses an arbitrary date in the If-Modified-Since header instead of a date taken from the Last-Modified header for 4617 4624 the same request, the client should be aware of the fact that this date is interpreted in the server's understanding of time. 4618 4625 The client should consider unsynchronized clocks and rounding problems due to the different encodings of time between the … … 4621 4628 If-Modified-Since date is derived from the client's clock without correction to the server's clock. Corrections for different 4622 4629 time bases between client and server are at best approximate due to network latency. 4623 </ dd>4624 </ dl>4630 </li> 4631 </ul> 4625 4632 <p id="rfc.section.14.25.p.7">The result of a request having both an If-Modified-Since header field and either an If-Match or an If-Unmodified-Since header 4626 4633 fields is undefined by this specification. … … 4732 4739 <div id="rfc.figure.u.124"></div><pre class="text"> Location: http://www.w3.org/pub/WWW/People.html 4733 4740 </pre><p id="rfc.section.14.30.p.5"> </p> 4734 < dl class="empty">4735 < dd> <b>Note:</b> The Content-Location header field (<a href="#header.content-location" id="rfc.xref.header.content-location.2" title="Content-Location">Section 14.14</a>) differs from Location in that the Content-Location identifies the original location of the entity enclosed in the request.4741 <ul class="empty"> 4742 <li> <b>Note:</b> The Content-Location header field (<a href="#header.content-location" id="rfc.xref.header.content-location.2" title="Content-Location">Section 14.14</a>) differs from Location in that the Content-Location identifies the original location of the entity enclosed in the request. 4736 4743 It is therefore possible for a response to contain header fields for both Location and Content-Location. Also see <a href="#invalidation.after.updates.or.deletions" title="Invalidation After Updates or Deletions">Section 13.10</a> for cache requirements of some methods. 4737 </ dd>4738 </ dl>4744 </li> 4745 </ul> 4739 4746 <div id="rfc.iref.m.15"></div> 4740 4747 <div id="rfc.iref.h.34"></div> … … 4770 4777 HTTP. 4771 4778 </p> 4772 < dl class="empty">4773 < dd> <b>Note:</b> because the meaning of "Pragma: no-cache as a response header field is not actually specified, it does not provide a reliable4779 <ul class="empty"> 4780 <li> <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 4774 4781 replacement for "Cache-Control: no-cache" in a response 4775 </ dd>4776 </ dl>4782 </li> 4783 </ul> 4777 4784 <div id="rfc.iref.p.8"></div> 4778 4785 <div id="rfc.iref.h.36"></div> … … 4908 4915 </pre><p id="rfc.section.14.38.p.5">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the Server response-header. Instead, it <em class="bcp14">SHOULD</em> include a Via field (as described in <a href="#header.via" id="rfc.xref.header.via.3" title="Via">Section 14.45</a>). 4909 4916 </p> 4910 < dl class="empty">4911 < dd> <b>Note:</b> Revealing the specific software version of the server might allow the server machine to become more vulnerable to attacks4917 <ul class="empty"> 4918 <li> <b>Note:</b> Revealing the specific software version of the server might allow the server machine to become more vulnerable to attacks 4912 4919 against software that is known to contain security holes. Server implementors are encouraged to make this field a configurable 4913 4920 option. 4914 </ dd>4915 </ dl>4921 </li> 4922 </ul> 4916 4923 <div id="rfc.iref.t.3"></div> 4917 4924 <div id="rfc.iref.h.42"></div> … … 5148 5155 </p> 5149 5156 <p id="rfc.section.14.46.p.12">110 Response is stale </p> 5150 < dl class="empty">5151 < dd> <em class="bcp14">MUST</em> be included whenever the returned response is stale.5152 </ dd>5153 </ dl>5157 <ul class="empty"> 5158 <li> <em class="bcp14">MUST</em> be included whenever the returned response is stale. 5159 </li> 5160 </ul> 5154 5161 <p id="rfc.section.14.46.p.13">111 Revalidation failed </p> 5155 < dl class="empty">5156 < dd> <em class="bcp14">MUST</em> be included if a cache returns a stale response because an attempt to revalidate the response failed, due to an inability5162 <ul class="empty"> 5163 <li> <em class="bcp14">MUST</em> be included if a cache returns a stale response because an attempt to revalidate the response failed, due to an inability 5157 5164 to reach the server. 5158 </ dd>5159 </ dl>5165 </li> 5166 </ul> 5160 5167 <p id="rfc.section.14.46.p.14">112 Disconnected operation </p> 5161 < dl class="empty">5162 < dd> <em class="bcp14">SHOULD</em> be included if the cache is intentionally disconnected from the rest of the network for a period of time.5163 </ dd>5164 </ dl>5168 <ul class="empty"> 5169 <li> <em class="bcp14">SHOULD</em> be included if the cache is intentionally disconnected from the rest of the network for a period of time. 5170 </li> 5171 </ul> 5165 5172 <p id="rfc.section.14.46.p.15">113 Heuristic expiration </p> 5166 < dl class="empty">5167 < dd> <em class="bcp14">MUST</em> be included if the cache heuristically chose a freshness lifetime greater than 24 hours and the response's age is greater5173 <ul class="empty"> 5174 <li> <em class="bcp14">MUST</em> be included if the cache heuristically chose a freshness lifetime greater than 24 hours and the response's age is greater 5168 5175 than 24 hours. 5169 </ dd>5170 </ dl>5176 </li> 5177 </ul> 5171 5178 <p id="rfc.section.14.46.p.16">199 Miscellaneous warning </p> 5172 < dl class="empty">5173 < dd>The warning text <em class="bcp14">MAY</em> include arbitrary information to be presented to a human user, or logged. A system receiving this warning <em class="bcp14">MUST NOT</em> take any automated action, besides presenting the warning to the user.5174 </ dd>5175 </ dl>5179 <ul class="empty"> 5180 <li>The warning text <em class="bcp14">MAY</em> include arbitrary information to be presented to a human user, or logged. A system receiving this warning <em class="bcp14">MUST NOT</em> take any automated action, besides presenting the warning to the user. 5181 </li> 5182 </ul> 5176 5183 <p id="rfc.section.14.46.p.17">214 Transformation applied </p> 5177 < dl class="empty">5178 < dd> <em class="bcp14">MUST</em> be added by an intermediate cache or proxy if it applies any transformation changing the content-coding (as specified in the5184 <ul class="empty"> 5185 <li> <em class="bcp14">MUST</em> be added by an intermediate cache or proxy if it applies any transformation changing the content-coding (as specified in the 5179 5186 Content-Encoding header) or media-type (as specified in the Content-Type header) of the response, or the entity-body of the 5180 5187 response, unless this Warning code already appears in the response. 5181 </ dd>5182 </ dl>5188 </li> 5189 </ul> 5183 5190 <p id="rfc.section.14.46.p.18">299 Miscellaneous persistent warning </p> 5184 < dl class="empty">5185 < dd>The warning text <em class="bcp14">MAY</em> include arbitrary information to be presented to a human user, or logged. A system receiving this warning <em class="bcp14">MUST NOT</em> take any automated action.5186 </ dd>5187 </ dl>5191 <ul class="empty"> 5192 <li>The warning text <em class="bcp14">MAY</em> include arbitrary information to be presented to a human user, or logged. A system receiving this warning <em class="bcp14">MUST NOT</em> take any automated action. 5193 </li> 5194 </ul> 5188 5195 <p id="rfc.section.14.46.p.19">If an implementation sends a message with one or more Warning headers whose version is HTTP/1.0 or lower, then the sender <em class="bcp14">MUST</em> include in each warning-value a warn-date that matches the date in the response. 5189 5196 </p> … … 5415 5422 <h1 id="rfc.references"><a href="#rfc.section.17" id="rfc.section.17">17.</a> References 5416 5423 </h1> 5417 <table summary="References">5424 <table> 5418 5425 <tr> 5419 5426 <td class="reference"><b id="ISO-8859">[ISO-8859]</b></td> 5420 <td class="top">International Organization for Standardization, “Information technology - 8-bit single byte coded graphic - character sets” 5421 <!--WARNING: date/@year should be a number: '1987-1990' in reference 'ISO-8859'-->, 1987-1990.<br>Part 1: Latin alphabet No. 1, ISO-8859-1:1987. Part 2: Latin alphabet No. 2, ISO-8859-2, 1987. Part 3: Latin alphabet No. 5427 <td class="top">International Organization for Standardization, “Information technology - 8-bit single byte coded graphic - character sets”, 1987-1990.<br>Part 1: Latin alphabet No. 1, ISO-8859-1:1987. Part 2: Latin alphabet No. 2, ISO-8859-2, 1987. Part 3: Latin alphabet No. 5422 5428 3, ISO-8859-3, 1988. Part 4: Latin alphabet No. 4, ISO-8859-4, 1988. Part 5: Latin/Cyrillic alphabet, ISO-8859-5, 1988. Part 5423 5429 6: Latin/Arabic alphabet, ISO-8859-6, 1987. Part 7: Latin/Greek alphabet, ISO-8859-7, 1987. Part 8: Latin/Hebrew alphabet, … … 5431 5437 <tr> 5432 5438 <td class="reference"><b id="Nie1997">[Nie1997]</b></td> 5433 <td class="top">Nielsen, H. F.., Gettys, J., Prud'hommeaux, E., Lie, H., and C. Lilley, “Network Performance Effects of HTTP/1.1, CSS1, and PNG”, Proceedings of ACM SIGCOMM '97, Cannes France, Sep 1997.</td>5439 <td class="top">Nielsen, H., Gettys, J., Prud'hommeaux, E., Lie, H., and C. Lilley, “Network Performance Effects of HTTP/1.1, CSS1, and PNG”, Proceedings of ACM SIGCOMM '97, Cannes France, Sep 1997.</td> 5434 5440 </tr> 5435 5441 <tr> 5436 5442 <td class="reference"><b id="Pad1995">[Pad1995]</b></td> 5437 <td class="top">Padmanabhan, V. N. and J.C. Mogul, “Improving HTTP Latency”, Computer Networks and ISDN Systems v. 28, pp. 25-35, Dec 1995.<br>Slightly revised version of paper in Proc. 2nd International WWW Conference '94: Mosaic and the Web, Oct. 1994, which is available5443 <td class="top">Padmanabhan, V. and J. Mogul, “Improving HTTP Latency”, Computer Networks and ISDN Systems v. 28, pp. 25-35, Dec 1995.<br>Slightly revised version of paper in Proc. 2nd International WWW Conference '94: Mosaic and the Web, Oct. 1994, which is available 5438 5444 at <<a href="http://www.ncsa.uiuc.edu/SDG/IT94/Proceedings/DDay/mogul/HTTPLatency.html">http://www.ncsa.uiuc.edu/SDG/IT94/Proceedings/DDay/mogul/HTTPLatency.html</a>>. 5439 5445 </td> … … 5446 5452 <tr> 5447 5453 <td class="reference"><b id="RFC1123">[RFC1123]</b></td> 5448 <td class="top"><a title="University of Southern California (USC), Information Sciences Institute">Braden, R.</a>, “<a href="http://tools.ietf.org/html/rfc1123">Requirements for Internet Hosts - Application and Support</a>”, STD 3, RFC 1123, October 1989.5454 <td class="top"><a href="mailto:Braden@ISI.EDU" title="University of Southern California (USC), Information Sciences Institute">Braden, R.</a>, “<a href="http://tools.ietf.org/html/rfc1123">Requirements for Internet Hosts - Application and Support</a>”, STD 3, RFC 1123, October 1989. 5449 5455 </td> 5450 5456 </tr> 5451 5457 <tr> 5452 5458 <td class="reference"><b id="RFC1305">[RFC1305]</b></td> 5453 <td class="top"><a title="University of Delaware, Electrical Engineering Department">Mills, D.</a>, “<a href="http://tools.ietf.org/html/rfc1305">Network Time Protocol (Version 3) Specification, Implementation</a>”, RFC 1305, March 1992.5459 <td class="top"><a href="mailto:mills@udel.edu" title="University of Delaware, Electrical Engineering Department">Mills, D.</a>, “<a href="http://tools.ietf.org/html/rfc1305">Network Time Protocol (Version 3) Specification, Implementation</a>”, RFC 1305, March 1992. 5454 5460 </td> 5455 5461 </tr> 5456 5462 <tr> 5457 5463 <td class="reference"><b id="RFC1436">[RFC1436]</b></td> 5458 <td class="top"><a title="University of Minnesota, Computer and Information Services">Anklesaria, F.</a>, <a title="University of Minnesota, Computer and Information Services">McCahill, M.</a>, <a title="University of Minnesota, Computer and Information Services">Lindner, P.</a>, <a title="University of Minnesota, Computer and Information Services">Johnson, D.</a>, <a title="University of Minnesota, Computer and Information Services">Torrey, D.</a>, and <atitle="University of Minnesota, Computer and Information Services">B. Alberti</a>, “<a href="http://tools.ietf.org/html/rfc1436">The Internet Gopher Protocol (a distributed document search and retrieval protocol)</a>”, RFC 1436, March 1993.5464 <td class="top"><a href="mailto:fxa@boombox.micro.umn.edu" title="University of Minnesota, Computer and Information Services">Anklesaria, F.</a>, <a href="mailto:mpm@boombox.micro.umn.edu" title="University of Minnesota, Computer and Information Services">McCahill, M.</a>, <a href="mailto:lindner@boombox.micro.umn.edu" title="University of Minnesota, Computer and Information Services">Lindner, P.</a>, <a href="mailto:dmj@boombox.micro.umn.edu" title="University of Minnesota, Computer and Information Services">Johnson, D.</a>, <a href="mailto:daniel@boombox.micro.umn.edu" title="University of Minnesota, Computer and Information Services">Torrey, D.</a>, and <a href="mailto:alberti@boombox.micro.umn.edu" title="University of Minnesota, Computer and Information Services">B. Alberti</a>, “<a href="http://tools.ietf.org/html/rfc1436">The Internet Gopher Protocol (a distributed document search and retrieval protocol)</a>”, RFC 1436, March 1993. 5459 5465 </td> 5460 5466 </tr> 5461 5467 <tr> 5462 5468 <td class="reference"><b id="RFC1590">[RFC1590]</b></td> 5463 <td class="top"><a title="USC/Information Sciences Institute">Postel, J.</a>, “<a href="http://tools.ietf.org/html/rfc1590">Media Type Registration Procedure</a>”, RFC 1590, November 1996.5469 <td class="top"><a href="mailto:Postel@ISI.EDU" title="USC/Information Sciences Institute">Postel, J.</a>, “<a href="http://tools.ietf.org/html/rfc1590">Media Type Registration Procedure</a>”, RFC 1590, November 1996. 5464 5470 </td> 5465 5471 </tr> 5466 5472 <tr> 5467 5473 <td class="reference"><b id="RFC1630">[RFC1630]</b></td> 5468 <td class="top"><a title="CERN, World-Wide Web project">Berners-Lee, T.</a>, “<a href="http://tools.ietf.org/html/rfc1630">Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network5474 <td class="top"><a href="mailto:timbl@info.cern.ch" title="CERN, World-Wide Web project">Berners-Lee, T.</a>, “<a href="http://tools.ietf.org/html/rfc1630">Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network 5469 5475 as used in the World-Wide Web</a>”, RFC 1630, June 1994. 5470 5476 </td> … … 5472 5478 <tr> 5473 5479 <td class="reference"><b id="RFC1700">[RFC1700]</b></td> 5474 <td class="top"><a title="USC/Information Sciences Institute">Reynolds, J.</a> and <atitle="USC/Information Sciences Institute">J. Postel</a>, “<a href="http://tools.ietf.org/html/rfc1700">Assigned Numbers</a>”, STD 2, RFC 1700, October 1994.5480 <td class="top"><a href="mailto:jkrey@isi.edu" title="USC/Information Sciences Institute">Reynolds, J.</a> and <a href="mailto:postel@isi.edu" title="USC/Information Sciences Institute">J. Postel</a>, “<a href="http://tools.ietf.org/html/rfc1700">Assigned Numbers</a>”, STD 2, RFC 1700, October 1994. 5475 5481 </td> 5476 5482 </tr> 5477 5483 <tr> 5478 5484 <td class="reference"><b id="RFC1737">[RFC1737]</b></td> 5479 <td class="top"><a title="Xerox Palo Alto Research Center">Masinter, L.</a> and <atitle="MIT Laboratory for Computer Science">K. Sollins</a>, “<a href="http://tools.ietf.org/html/rfc1737">Functional Requirements for Uniform Resource Names</a>”, RFC 1737, December 1994.5485 <td class="top"><a href="mailto:masinter@parc.xerox.com" title="Xerox Palo Alto Research Center">Masinter, L.</a> and <a href="mailto:sollins@lcs.mit.edu" title="MIT Laboratory for Computer Science">K. Sollins</a>, “<a href="http://tools.ietf.org/html/rfc1737">Functional Requirements for Uniform Resource Names</a>”, RFC 1737, December 1994. 5480 5486 </td> 5481 5487 </tr> 5482 5488 <tr> 5483 5489 <td class="reference"><b id="RFC1738">[RFC1738]</b></td> 5484 <td class="top"><a title="CERN, World-Wide Web project">Berners-Lee, T.</a>, <a title="Xerox PARC">Masinter, L.</a>, and <atitle="University of Minnesota, Computer and Information Services">M. McCahill</a>, “<a href="http://tools.ietf.org/html/rfc1738">Uniform Resource Locators (URL)</a>”, RFC 1738, December 1994.5490 <td class="top"><a href="mailto:timbl@info.cern.ch" title="CERN, World-Wide Web project">Berners-Lee, T.</a>, <a href="mailto:masinter@parc.xerox.com" title="Xerox PARC">Masinter, L.</a>, and <a href="mailto:mpm@boombox.micro.umn.edu" title="University of Minnesota, Computer and Information Services">M. McCahill</a>, “<a href="http://tools.ietf.org/html/rfc1738">Uniform Resource Locators (URL)</a>”, RFC 1738, December 1994. 5485 5491 </td> 5486 5492 </tr> 5487 5493 <tr> 5488 5494 <td class="reference"><b id="RFC1766">[RFC1766]</b></td> 5489 <td class="top"><a title="UNINETT">Alvestrand, H.</a>, “<a href="http://tools.ietf.org/html/rfc1766">Tags for the Identification of Languages</a>”, RFC 1766, March 1995.5495 <td class="top"><a href="mailto:Harald.T.Alvestrand@uninett.no" title="UNINETT">Alvestrand, H.</a>, “<a href="http://tools.ietf.org/html/rfc1766">Tags for the Identification of Languages</a>”, RFC 1766, March 1995. 5490 5496 </td> 5491 5497 </tr> 5492 5498 <tr> 5493 5499 <td class="reference"><b id="RFC1806">[RFC1806]</b></td> 5494 <td class="top"><a title="New Century Systems">Troost, R.</a> and <atitle="QUALCOMM Incorporated">S. Dorner</a>, “<a href="http://tools.ietf.org/html/rfc1806">Communicating Presentation Information in Internet Messages: The Content-Disposition Header</a>”, RFC 1806, June 1995.5500 <td class="top"><a href="mailto:rens@century.com" title="New Century Systems">Troost, R.</a> and <a href="mailto:sdorner@qualcomm.com" title="QUALCOMM Incorporated">S. Dorner</a>, “<a href="http://tools.ietf.org/html/rfc1806">Communicating Presentation Information in Internet Messages: The Content-Disposition Header</a>”, RFC 1806, June 1995. 5495 5501 </td> 5496 5502 </tr> 5497 5503 <tr> 5498 5504 <td class="reference"><b id="RFC1808">[RFC1808]</b></td> 5499 <td class="top"><a title="University of California Irvine, Department of Information and Computer Science">Fielding, R.</a>, “<a href="http://tools.ietf.org/html/rfc1808">Relative Uniform Resource Locators</a>”, RFC 1808, June 1995.5505 <td class="top"><a href="mailto:fielding@ics.uci.edu" title="University of California Irvine, Department of Information and Computer Science">Fielding, R.</a>, “<a href="http://tools.ietf.org/html/rfc1808">Relative Uniform Resource Locators</a>”, RFC 1808, June 1995. 5500 5506 </td> 5501 5507 </tr> 5502 5508 <tr> 5503 5509 <td class="reference"><b id="RFC1864">[RFC1864]</b></td> 5504 <td class="top"><a title="Carnegie Mellon University">Myers, J.</a> and <atitle="Dover Beach Consulting, Inc.">M. Rose</a>, “<a href="http://tools.ietf.org/html/rfc1864">The Content-MD5 Header Field</a>”, RFC 1864, October 1995.5510 <td class="top"><a href="mailto:jgm+@cmu.edu" title="Carnegie Mellon University">Myers, J.</a> and <a href="mailto:mrose@dbc.mtview.ca.us" title="Dover Beach Consulting, Inc.">M. Rose</a>, “<a href="http://tools.ietf.org/html/rfc1864">The Content-MD5 Header Field</a>”, RFC 1864, October 1995. 5505 5511 </td> 5506 5512 </tr> 5507 <!--WARNING: unused reference 'RFC1866'-->5508 5513 <tr> 5509 5514 <td class="reference"><b id="RFC1866">[RFC1866]</b></td> 5510 <td class="top"><a title="MIT Laboratory for Computer Science">Berners-Lee, T.</a> and <a title="MIT Laboratory for Computer Science, W3 Consortium">D.W. Connolly</a>, “<a href="http://tools.ietf.org/html/rfc1866">Hypertext Markup Language - 2.0</a>”, RFC 1866, November 1995.5515 <td class="top"><a href="mailto:timbl@w3.org" title="MIT Laboratory for Computer Science">Berners-Lee, T.</a> and <a href="mailto:connolly@w3.org" title="MIT Laboratory for Computer Science, W3 Consortium">D. Connolly</a>, “<a href="http://tools.ietf.org/html/rfc1866">Hypertext Markup Language - 2.0</a>”, RFC 1866, November 1995. 5511 5516 </td> 5512 5517 </tr> 5513 5518 <tr> 5514 5519 <td class="reference"><b id="RFC1867">[RFC1867]</b></td> 5515 <td class="top"><a title="Xerox Palo Alto Research Center">Masinter, L.</a> and <atitle="XSoft, Xerox Corporation">E. Nebel</a>, “<a href="http://tools.ietf.org/html/rfc1867">Form-based File Upload in HTML</a>”, RFC 1867, November 1995.5520 <td class="top"><a href="mailto:masinter@parc.xerox.com" title="Xerox Palo Alto Research Center">Masinter, L.</a> and <a href="mailto:nebel@xsoft.sd.xerox.com" title="XSoft, Xerox Corporation">E. Nebel</a>, “<a href="http://tools.ietf.org/html/rfc1867">Form-based File Upload in HTML</a>”, RFC 1867, November 1995. 5516 5521 </td> 5517 5522 </tr> 5518 5523 <tr> 5519 5524 <td class="reference"><b id="RFC1900">[RFC1900]</b></td> 5520 <td class="top"><a title="CERN, Computing and Networks Division">Carpenter, B.</a> and <atitle="cisco Systems">Y. Rekhter</a>, “<a href="http://tools.ietf.org/html/rfc1900">Renumbering Needs Work</a>”, RFC 1900, February 1996.5525 <td class="top"><a href="mailto:brian@dxcoms.cern.ch" title="CERN, Computing and Networks Division">Carpenter, B.</a> and <a href="mailto:yakov@cisco.com" title="cisco Systems">Y. Rekhter</a>, “<a href="http://tools.ietf.org/html/rfc1900">Renumbering Needs Work</a>”, RFC 1900, February 1996. 5521 5526 </td> 5522 5527 </tr> 5523 5528 <tr> 5524 5529 <td class="reference"><b id="RFC1945">[RFC1945]</b></td> 5525 <td class="top"><a title="MIT, Laboratory for Computer Science">Berners-Lee, T.</a>, <a title="University of California, Irvine, Department of Information and Computer Science">Fielding, R.T.</a>, and <a title="W3 Consortium, MIT Laboratory for Computer Science">H.F. Nielsen</a>, “<a href="http://tools.ietf.org/html/rfc1945">Hypertext Transfer Protocol -- HTTP/1.0</a>”, RFC 1945, May 1996.5530 <td class="top"><a href="mailto:timbl@w3.org" title="MIT, Laboratory for Computer Science">Berners-Lee, T.</a>, <a href="mailto:fielding@ics.uci.edu" title="University of California, Irvine, Department of Information and Computer Science">Fielding, R.</a>, and <a href="mailto:frystyk@w3.org" title="W3 Consortium, MIT Laboratory for Computer Science">H. Nielsen</a>, “<a href="http://tools.ietf.org/html/rfc1945">Hypertext Transfer Protocol -- HTTP/1.0</a>”, RFC 1945, May 1996. 5526 5531 </td> 5527 5532 </tr> 5528 5533 <tr> 5529 5534 <td class="reference"><b id="RFC1950">[RFC1950]</b></td> 5530 <td class="top"><a title="Aladdin Enterprises">Deutsch, L.P.</a> and J-L. Gailly, “<a href="http://tools.ietf.org/html/rfc1950">ZLIB Compressed Data Format Specification version 3.3</a>”, RFC 1950, May 1996.5535 <td class="top"><a href="mailto:ghost@aladdin.com" title="Aladdin Enterprises">Deutsch, L.</a> and J-L. Gailly, “<a href="http://tools.ietf.org/html/rfc1950">ZLIB Compressed Data Format Specification version 3.3</a>”, RFC 1950, May 1996. 5531 5536 </td> 5532 5537 </tr> 5533 5538 <tr> 5534 5539 <td class="reference"><b id="RFC1951">[RFC1951]</b></td> 5535 <td class="top"><a title="Aladdin Enterprises">Deutsch, P.</a>, “<a href="http://tools.ietf.org/html/rfc1951">DEFLATE Compressed Data Format Specification version 1.3</a>”, RFC 1951, May 1996.5540 <td class="top"><a href="mailto:ghost@aladdin.com" title="Aladdin Enterprises">Deutsch, P.</a>, “<a href="http://tools.ietf.org/html/rfc1951">DEFLATE Compressed Data Format Specification version 1.3</a>”, RFC 1951, May 1996. 5536 5541 </td> 5537 5542 </tr> 5538 5543 <tr> 5539 5544 <td class="reference"><b id="RFC1952">[RFC1952]</b></td> 5540 <td class="top"><a title="Aladdin Enterprises">Deutsch, P.</a>, <a>Gailly, J-L.</a>, <a>Adler, M.</a>, <a>Deutsch, L.P.</a>, and <a>G. Randers-Pehrson</a>, “<a href="http://tools.ietf.org/html/rfc1952">GZIP file format specification version 4.3</a>”, RFC 1952, May 1996.5545 <td class="top"><a href="mailto:ghost@aladdin.com" title="Aladdin Enterprises">Deutsch, P.</a>, <a href="mailto:gzip@prep.ai.mit.edu">Gailly, J-L.</a>, <a href="mailto:madler@alumni.caltech.edu">Adler, M.</a>, <a href="mailto:ghost@aladdin.com">Deutsch, L.</a>, and <a href="mailto:randeg@alumni.rpi.edu">G. Randers-Pehrson</a>, “<a href="http://tools.ietf.org/html/rfc1952">GZIP file format specification version 4.3</a>”, RFC 1952, May 1996. 5541 5546 </td> 5542 5547 </tr> 5543 <!--WARNING: unused reference 'RFC2026'-->5544 5548 <tr> 5545 5549 <td class="reference"><b id="RFC2026">[RFC2026]</b></td> 5546 <td class="top"><a title="Harvard University">Bradner, S.</a>, “<a href="http://tools.ietf.org/html/rfc2026">The Internet Standards Process -- Revision 3</a>”, BCP 9, RFC 2026, October 1996.5550 <td class="top"><a href="mailto:sob@harvard.edu" title="Harvard University">Bradner, S.</a>, “<a href="http://tools.ietf.org/html/rfc2026">The Internet Standards Process -- Revision 3</a>”, BCP 9, RFC 2026, October 1996. 5547 5551 </td> 5548 5552 </tr> 5549 5553 <tr> 5550 5554 <td class="reference"><b id="RFC2045">[RFC2045]</b></td> 5551 <td class="top"><a title="Innosoft International, Inc.">Freed, N.</a> and <a title="First Virtual Holdings">N.S. Borenstein</a>, “<a href="http://tools.ietf.org/html/rfc2045">Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies</a>”, RFC 2045, November 1996.5555 <td class="top"><a href="mailto:ned@innosoft.com" title="Innosoft International, Inc.">Freed, N.</a> and <a href="mailto:nsb@nsb.fv.com" title="First Virtual Holdings">N. Borenstein</a>, “<a href="http://tools.ietf.org/html/rfc2045">Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies</a>”, RFC 2045, November 1996. 5552 5556 </td> 5553 5557 </tr> 5554 5558 <tr> 5555 5559 <td class="reference"><b id="RFC2046">[RFC2046]</b></td> 5556 <td class="top"><a title="Innosoft International, Inc.">Freed, N.</a> and <atitle="First Virtual Holdings">N. Borenstein</a>, “<a href="http://tools.ietf.org/html/rfc2046">Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types</a>”, RFC 2046, November 1996.5560 <td class="top"><a href="mailto:ned@innosoft.com" title="Innosoft International, Inc.">Freed, N.</a> and <a href="mailto:nsb@nsb.fv.com" title="First Virtual Holdings">N. Borenstein</a>, “<a href="http://tools.ietf.org/html/rfc2046">Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types</a>”, RFC 2046, November 1996. 5557 5561 </td> 5558 5562 </tr> 5559 5563 <tr> 5560 5564 <td class="reference"><b id="RFC2047">[RFC2047]</b></td> 5561 <td class="top"><a title="University of Tennessee">Moore, K.</a>, “<a href="http://tools.ietf.org/html/rfc2047">MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text</a>”, RFC 2047, November 1996.5565 <td class="top"><a href="mailto:moore@cs.utk.edu" title="University of Tennessee">Moore, K.</a>, “<a href="http://tools.ietf.org/html/rfc2047">MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text</a>”, RFC 2047, November 1996. 5562 5566 </td> 5563 5567 </tr> 5564 5568 <tr> 5565 5569 <td class="reference"><b id="RFC2049">[RFC2049]</b></td> 5566 <td class="top"><a title="Innosoft International, Inc.">Freed, N.</a> and <a title="First Virtual Holdings">N.S. Borenstein</a>, “<a href="http://tools.ietf.org/html/rfc2049">Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples</a>”, RFC 2049, November 1996.5570 <td class="top"><a href="mailto:ned@innosoft.com" title="Innosoft International, Inc.">Freed, N.</a> and <a href="mailto:nsb@nsb.fv.com" title="First Virtual Holdings">N. Borenstein</a>, “<a href="http://tools.ietf.org/html/rfc2049">Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples</a>”, RFC 2049, November 1996. 5567 5571 </td> 5568 5572 </tr> 5569 5573 <tr> 5570 5574 <td class="reference"><b id="RFC2068">[RFC2068]</b></td> 5571 <td class="top"><a title="University of California, Irvine, Department of Information and Computer Science">Fielding, R.</a>, <a title="MIT Laboratory for Computer Science">Gettys, J.</a>, <a title="Digital Equipment Corporation, Western Research Laboratory">Mogul, J.</a>, <a title="MIT Laboratory for Computer Science">Nielsen, H.</a>, and <atitle="MIT Laboratory for Computer Science">T. Berners-Lee</a>, “<a href="http://tools.ietf.org/html/rfc2068">Hypertext Transfer Protocol -- HTTP/1.1</a>”, RFC 2068, January 1997.5575 <td class="top"><a href="mailto:fielding@ics.uci.edu" title="University of California, Irvine, Department of Information and Computer Science">Fielding, R.</a>, <a href="mailto:jg@w3.org" title="MIT Laboratory for Computer Science">Gettys, J.</a>, <a href="mailto:mogul@wrl.dec.com" title="Digital Equipment Corporation, Western Research Laboratory">Mogul, J.</a>, <a href="mailto:frystyk@w3.org" title="MIT Laboratory for Computer Science">Nielsen, H.</a>, and <a href="mailto:timbl@w3.org" title="MIT Laboratory for Computer Science">T. Berners-Lee</a>, “<a href="http://tools.ietf.org/html/rfc2068">Hypertext Transfer Protocol -- HTTP/1.1</a>”, RFC 2068, January 1997. 5572 5576 </td> 5573 5577 </tr> 5574 <!--WARNING: unused reference 'RFC2069'-->5575 5578 <tr> 5576 5579 <td class="reference"><b id="RFC2069">[RFC2069]</b></td> 5577 <td class="top"><a title="Northwestern University, Department of Mathematics">Franks, J.</a>, <a title="CERN">Hallam-Baker, P.</a>, <a title="Spyglass, Inc.">Hostetler, J.</a>, <a title="Microsoft Corporation">Leach, P.</a>, <a title="Netscape Communications Corporation">Luotonen, A.</a>, <a title="Spyglass, Inc.">Sink, E.</a>, and <atitle="Open Market, Inc.">L. Stewart</a>, “<a href="http://tools.ietf.org/html/rfc2069">An Extension to HTTP : Digest Access Authentication</a>”, RFC 2069, January 1997.5580 <td class="top"><a href="mailto:john@math.nwu.edu" title="Northwestern University, Department of Mathematics">Franks, J.</a>, <a href="mailto:hallam@w3.org" title="CERN">Hallam-Baker, P.</a>, <a href="mailto:jeff@spyglass.com" title="Spyglass, Inc.">Hostetler, J.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, <a href="mailto:luotonen@netscape.com" title="Netscape Communications Corporation">Luotonen, A.</a>, <a href="mailto:eric@spyglass.com" title="Spyglass, Inc.">Sink, E.</a>, and <a href="mailto:stewart@OpenMarket.com" title="Open Market, Inc.">L. Stewart</a>, “<a href="http://tools.ietf.org/html/rfc2069">An Extension to HTTP : Digest Access Authentication</a>”, RFC 2069, January 1997. 5578 5581 </td> 5579 5582 </tr> 5580 5583 <tr> 5581 5584 <td class="reference"><b id="RFC2076">[RFC2076]</b></td> 5582 <td class="top"><a title="Stockholm University/KTH">Palme, J.</a>, “<a href="http://tools.ietf.org/html/rfc2076">Common Internet Message Headers</a>”, RFC 2076, February 1997.5585 <td class="top"><a href="mailto:jpalme@dsv.su.se" title="Stockholm University/KTH">Palme, J.</a>, “<a href="http://tools.ietf.org/html/rfc2076">Common Internet Message Headers</a>”, RFC 2076, February 1997. 5583 5586 </td> 5584 5587 </tr> 5585 5588 <tr> 5586 5589 <td class="reference"><b id="RFC2110">[RFC2110]</b></td> 5587 <td class="top"><a title="Stockholm University and KTH">Palme, J.</a> and <atitle="Microsoft Corporation">A. Hopmann</a>, “<a href="http://tools.ietf.org/html/rfc2110">MIME E-mail Encapsulation of Aggregate Documents, such as HTML (MHTML)</a>”, RFC 2110, March 1997.5590 <td class="top"><a href="mailto:jpalme@dsv.su.se" title="Stockholm University and KTH">Palme, J.</a> and <a href="mailto:alexhop@microsoft.com" title="Microsoft Corporation">A. Hopmann</a>, “<a href="http://tools.ietf.org/html/rfc2110">MIME E-mail Encapsulation of Aggregate Documents, such as HTML (MHTML)</a>”, RFC 2110, March 1997. 5588 5591 </td> 5589 5592 </tr> 5590 5593 <tr> 5591 5594 <td class="reference"><b id="RFC2119">[RFC2119]</b></td> 5592 <td class="top"><a title="Harvard University">Bradner, S.</a>, “<a href="http://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a>”, BCP 14, RFC 2119, March 1997.5595 <td class="top"><a href="mailto:-" title="Harvard University">Bradner, S.</a>, “<a href="http://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a>”, BCP 14, RFC 2119, March 1997. 5593 5596 </td> 5594 5597 </tr> 5595 5598 <tr> 5596 5599 <td class="reference"><b id="RFC2145">[RFC2145]</b></td> 5597 <td class="top"><a title="Western Research Laboratory">Mogul, J.C.</a>, <a title="Department of Information and Computer Science">Fielding, R.T.</a>, <a title="MIT Laboratory for Computer Science">Gettys, J.</a>, and <a title="W3 Consortium">H.F. Nielsen</a>, “<a href="http://tools.ietf.org/html/rfc2145">Use and Interpretation of HTTP Version Numbers</a>”, RFC 2145, May 1997.5600 <td class="top"><a href="mailto:mogul@wrl.dec.com" title="Western Research Laboratory">Mogul, J.</a>, <a href="mailto:fielding@ics.uci.edu" title="Department of Information and Computer Science">Fielding, R.</a>, <a href="mailto:jg@w3.org" title="MIT Laboratory for Computer Science">Gettys, J.</a>, and <a href="mailto:frystyk@w3.org" title="W3 Consortium">H. Nielsen</a>, “<a href="http://tools.ietf.org/html/rfc2145">Use and Interpretation of HTTP Version Numbers</a>”, RFC 2145, May 1997. 5598 5601 </td> 5599 5602 </tr> 5600 5603 <tr> 5601 5604 <td class="reference"><b id="RFC2183">[RFC2183]</b></td> 5602 <td class="top"><a title="New Century Systems">Troost, R.</a>, <a title="QUALCOMM Incorporated">Dorner, S.</a>, and <atitle="Department of Computer Science">K. Moore</a>, “<a href="http://tools.ietf.org/html/rfc2183">Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field</a>”, RFC 2183, August 1997.5605 <td class="top"><a href="mailto:rens@century.com" title="New Century Systems">Troost, R.</a>, <a href="mailto:sdorner@qualcomm.com" title="QUALCOMM Incorporated">Dorner, S.</a>, and <a href="mailto:moore@cs.utk.edu" title="Department of Computer Science">K. Moore</a>, “<a href="http://tools.ietf.org/html/rfc2183">Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field</a>”, RFC 2183, August 1997. 5603 5606 </td> 5604 5607 </tr> 5605 5608 <tr> 5606 5609 <td class="reference"><b id="RFC2277">[RFC2277]</b></td> 5607 <td class="top"><a title="UNINETT">Alvestrand, H.T.</a>, “<a href="http://tools.ietf.org/html/rfc2277">IETF Policy on Character Sets and Languages</a>”, BCP 18, RFC 2277, January 1998.5610 <td class="top"><a href="mailto:Harald.T.Alvestrand@uninett.no" title="UNINETT">Alvestrand, H.</a>, “<a href="http://tools.ietf.org/html/rfc2277">IETF Policy on Character Sets and Languages</a>”, BCP 18, RFC 2277, January 1998. 5608 5611 </td> 5609 5612 </tr> 5610 5613 <tr> 5611 5614 <td class="reference"><b id="RFC2279">[RFC2279]</b></td> 5612 <td class="top"><a title="Alis Technologies">Yergeau, F.</a>, “<a href="http://tools.ietf.org/html/rfc2279">UTF-8, a transformation format of ISO 10646</a>”, RFC 2279, January 1998.5615 <td class="top"><a href="mailto:fyergeau@alis.com" title="Alis Technologies">Yergeau, F.</a>, “<a href="http://tools.ietf.org/html/rfc2279">UTF-8, a transformation format of ISO 10646</a>”, RFC 2279, January 1998. 5613 5616 </td> 5614 5617 </tr> 5615 5618 <tr> 5616 5619 <td class="reference"><b id="RFC2324">[RFC2324]</b></td> 5617 <td class="top"><a title="Xerox Palo Alto Research Center">Masinter, L.</a>, “<a href="http://tools.ietf.org/html/rfc2324">Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)</a>”, RFC 2324, April 1998.5620 <td class="top"><a href="mailto:masinter@parc.xerox.com" title="Xerox Palo Alto Research Center">Masinter, L.</a>, “<a href="http://tools.ietf.org/html/rfc2324">Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)</a>”, RFC 2324, April 1998. 5618 5621 </td> 5619 5622 </tr> 5620 5623 <tr> 5621 5624 <td class="reference"><b id="RFC2396">[RFC2396]</b></td> 5622 <td class="top"><a title="World Wide Web Consortium">Berners-Lee, T.</a>, <a title="Department of Information and Computer Science">Fielding, R.T.</a>, and <atitle="Xerox PARC">L. Masinter</a>, “<a href="http://tools.ietf.org/html/rfc2396">Uniform Resource Identifiers (URI): Generic Syntax</a>”, RFC 2396, August 1998.5625 <td class="top"><a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</a>, <a href="mailto:fielding@ics.uci.edu" title="Department of Information and Computer Science">Fielding, R.</a>, and <a href="mailto:masinter@parc.xerox.com" title="Xerox PARC">L. Masinter</a>, “<a href="http://tools.ietf.org/html/rfc2396">Uniform Resource Identifiers (URI): Generic Syntax</a>”, RFC 2396, August 1998. 5623 5626 </td> 5624 5627 </tr> 5625 5628 <tr> 5626 5629 <td class="reference"><b id="RFC2617">[RFC2617]</b></td> 5627 <td class="top"><a title="Northwestern University, Department of Mathematics">Franks, J.</a>, <a title="Verisign Inc.">Hallam-Baker, P.M.</a>, <a title="AbiSource, Inc.">Hostetler, J.L.</a>, <a title="Agranat Systems, Inc.">Lawrence, S.D.</a>, <a title="Microsoft Corporation">Leach, P.J.</a>, Luotonen, A., and <atitle="Open Market, Inc.">L. Stewart</a>, “<a href="http://tools.ietf.org/html/rfc2617">HTTP Authentication: Basic and Digest Access Authentication</a>”, RFC 2617, June 1999.5630 <td class="top"><a href="mailto:john@math.nwu.edu" title="Northwestern University, Department of Mathematics">Franks, J.</a>, <a href="mailto:pbaker@verisign.com" title="Verisign Inc.">Hallam-Baker, P.</a>, <a href="mailto:jeff@AbiSource.com" title="AbiSource, Inc.">Hostetler, J.</a>, <a href="mailto:lawrence@agranat.com" title="Agranat Systems, Inc.">Lawrence, S.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, Luotonen, A., and <a href="mailto:stewart@OpenMarket.com" title="Open Market, Inc.">L. Stewart</a>, “<a href="http://tools.ietf.org/html/rfc2617">HTTP Authentication: Basic and Digest Access Authentication</a>”, RFC 2617, June 1999. 5628 5631 </td> 5629 5632 </tr> 5630 5633 <tr> 5631 5634 <td class="reference"><b id="RFC821">[RFC821]</b></td> 5632 <td class="top">Postel, J. B., “<a href="http://tools.ietf.org/html/rfc821">Simple Mail Transfer Protocol</a>”, STD 10, RFC 821, August 1982.5635 <td class="top">Postel, J., “<a href="http://tools.ietf.org/html/rfc821">Simple Mail Transfer Protocol</a>”, STD 10, RFC 821, August 1982. 5633 5636 </td> 5634 5637 </tr> 5635 5638 <tr> 5636 5639 <td class="reference"><b id="RFC822">[RFC822]</b></td> 5637 <td class="top"><a title="University of Delaware, Dept. of Electrical Engineering">Crocker, D.H.</a>, “<a href="http://tools.ietf.org/html/rfc822">Standard for the format of ARPA Internet text messages</a>”, STD 11, RFC 822, August 1982.5640 <td class="top"><a href="mailto:DCrocker@UDel-Relay" title="University of Delaware, Dept. of Electrical Engineering">Crocker, D.</a>, “<a href="http://tools.ietf.org/html/rfc822">Standard for the format of ARPA Internet text messages</a>”, STD 11, RFC 822, August 1982. 5638 5641 </td> 5639 5642 </tr> … … 5655 5658 <tr> 5656 5659 <td class="reference"><b id="Tou1998">[Tou1998]</b></td> 5657 <td class="top"><a title="USC/Information Sciences Institute">Touch, J.</a>, <a title="USC/Information Sciences Institute">Heidemann, J.</a>, and <atitle="USC/Information Sciences Institute">K. Obraczka</a>, “<a href="http://www.isi.edu/touch/pubs/http-perf96/">Analysis of HTTP Performance</a>”, ISI Research Report ISI/RR-98-463 (original report dated Aug.1996), Aug 1998, <<a href="http://www.isi.edu/touch/pubs/http-perf96/">http://www.isi.edu/touch/pubs/http-perf96/</a>>.5660 <td class="top"><a href="mailto:touch@isi.edu" title="USC/Information Sciences Institute">Touch, J.</a>, <a href="mailto:johnh@isi.edu" title="USC/Information Sciences Institute">Heidemann, J.</a>, and <a href="mailto:katia@isi.edu" title="USC/Information Sciences Institute">K. Obraczka</a>, “<a href="http://www.isi.edu/touch/pubs/http-perf96/">Analysis of HTTP Performance</a>”, ISI Research Report ISI/RR-98-463 (original report dated Aug.1996), Aug 1998, <<a href="http://www.isi.edu/touch/pubs/http-perf96/">http://www.isi.edu/touch/pubs/http-perf96/</a>>. 5658 5661 </td> 5659 5662 </tr> … … 5667 5670 </tr> 5668 5671 </table> 5669 <h1 id="rfc.authors"><a href="#rfc.section.18" id="rfc.section.18">18.</a> <a href="#rfc.authors">Authors' Addresses</a></h1> 5670 <address class="vcard"><span class="vcardline"><span class="fn">Roy T. Fielding</span><span class="n hidden"><span class="family-name">Fielding</span><span class="given-name">Roy T.</span></span></span><span class="org vcardline">Department of Information and Computer Science</span><span class="adr"><span class="street-address vcardline">University of California, Irvine</span><span class="vcardline"><span class="locality">Irvine</span>, <span class="region">CA</span> <span class="postal-code">92697-3425</span></span></span><span class="vcardline tel"><span class="type">Fax</span>: <a href="fax:+1(949)824-1715"><span class="value">+1(949)824-1715</span></a></span><span class="vcardline">EMail: <a><span class="email">fielding@ics.uci.edu</span></a></span></address> 5671 <address class="vcard"><span class="vcardline"><span class="fn">James Gettys</span><span class="n hidden"><span class="family-name">Gettys</span><span class="given-name">James</span></span></span><span class="org vcardline">World Wide Web Consortium</span><span class="adr"><span class="street-address vcardline">MIT Laboratory for Computer Science, NE43-356</span><span class="street-address vcardline">545 Technology Square</span><span class="vcardline"><span class="locality">Cambridge</span>, <span class="region">MA</span> <span class="postal-code">02139</span></span></span><span class="vcardline tel"><span class="type">Fax</span>: <a href="fax:+1(617)258-8682"><span class="value">+1(617)258-8682</span></a></span><span class="vcardline">EMail: <a><span class="email">jg@w3.org</span></a></span></address> 5672 <address class="vcard"><span class="vcardline"><span class="fn">Jeffrey C. Mogul</span><span class="n hidden"><span class="family-name">Mogul</span><span class="given-name">Jeffrey C.</span></span></span><span class="org vcardline">Compaq Computer Corporation</span><span class="adr"><span class="street-address vcardline">Western Research Laboratory</span><span class="street-address vcardline">250 University Avenue</span><span class="vcardline"><span class="locality">Palo Alto</span>, <span class="region">CA</span> <span class="postal-code">94305</span></span></span><span class="vcardline">EMail: <a><span class="email">mogul@wrl.dec.com</span></a></span></address> 5673 <address class="vcard"><span class="vcardline"><span class="fn">Henrik Frystyk Nielsen</span><span class="n hidden"><span class="family-name">Frystyk</span></span></span><span class="org vcardline">World Wide Web Consortium</span><span class="adr"><span class="street-address vcardline">MIT Laboratory for Computer Science, NE43-356</span><span class="street-address vcardline">545 Technology Square</span><span class="vcardline"><span class="locality">Cambridge</span>, <span class="region">MA</span> <span class="postal-code">02139</span></span></span><span class="vcardline tel"><span class="type">Fax</span>: <a href="fax:+1(617)258-8682"><span class="value">+1(617)258-8682</span></a></span><span class="vcardline">EMail: <a><span class="email">frystyk@w3.org</span></a></span></address> 5674 <address class="vcard"><span class="vcardline"><span class="fn">Larry Masinter</span><span class="n hidden"><span class="family-name">Masinter</span><span class="given-name">Larry</span></span></span><span class="org vcardline">Xerox Corporation</span><span class="adr"><span class="street-address vcardline">MIT Laboratory for Computer Science, NE43-356</span><span class="street-address vcardline">3333 Coyote Hill Road</span><span class="vcardline"><span class="locality">Palo Alto</span>, <span class="region">CA</span> <span class="postal-code">94034</span></span></span><span class="vcardline">EMail: <a><span class="email">masinter@parc.xerox.com</span></a></span></address> 5675 <address class="vcard"><span class="vcardline"><span class="fn">Paul J. Leach</span><span class="n hidden"><span class="family-name">Leach</span><span class="given-name">Paul J.</span></span></span><span class="org vcardline">Microsoft Corporation</span><span class="adr"><span class="street-address vcardline">1 Microsoft Way</span><span class="vcardline"><span class="locality">Redmond</span>, <span class="region">WA</span> <span class="postal-code">98052</span></span></span><span class="vcardline">EMail: <a><span class="email">paulle@microsoft.com</span></a></span></address> 5676 <address class="vcard"><span class="vcardline"><span class="fn">Tim Berners-Lee</span><span class="n hidden"><span class="family-name">Berners-Lee</span><span class="given-name">Tim</span></span></span><span class="org vcardline">World Wide Web Consortium</span><span class="adr"><span class="street-address vcardline">MIT Laboratory for Computer Science, NE43-356</span><span class="street-address vcardline">545 Technology Square</span><span class="vcardline"><span class="locality">Cambridge</span>, <span class="region">MA</span> <span class="postal-code">02139</span></span></span><span class="vcardline tel"><span class="type">Fax</span>: <a href="fax:+1(617)258-8682"><span class="value">+1(617)258-8682</span></a></span><span class="vcardline">EMail: <a><span class="email">timbl@w3.org</span></a></span></address> 5672 <div class="avoidbreak"> 5673 <h1 id="rfc.authors"><a href="#rfc.section.18" id="rfc.section.18">18.</a> <a href="#rfc.authors">Authors' Addresses</a></h1> 5674 <address class="vcard"><span class="vcardline"><span class="fn">Roy T. Fielding</span><span class="n hidden"><span class="family-name">Fielding</span><span class="given-name">Roy T.</span></span></span><span class="org vcardline">Department of Information and Computer Science</span><span class="adr"><span class="street-address vcardline">University of California, Irvine</span><span class="vcardline"><span class="locality">Irvine</span>, <span class="region">CA</span> <span class="postal-code">92697-3425</span></span></span><span class="vcardline tel"><span class="type">Fax</span>: <a href="fax:+1(949)824-1715"><span class="value">+1(949)824-1715</span></a></span><span class="vcardline">EMail: <a href="mailto:fielding@ics.uci.edu"><span class="email">fielding@ics.uci.edu</span></a></span></address> 5675 <address class="vcard"><span class="vcardline"><span class="fn">James Gettys</span><span class="n hidden"><span class="family-name">Gettys</span><span class="given-name">James</span></span></span><span class="org vcardline">World Wide Web Consortium</span><span class="adr"><span class="street-address vcardline">MIT Laboratory for Computer Science, NE43-356</span><span class="street-address vcardline">545 Technology Square</span><span class="vcardline"><span class="locality">Cambridge</span>, <span class="region">MA</span> <span class="postal-code">02139</span></span></span><span class="vcardline tel"><span class="type">Fax</span>: <a href="fax:+1(617)258-8682"><span class="value">+1(617)258-8682</span></a></span><span class="vcardline">EMail: <a href="mailto:jg@w3.org"><span class="email">jg@w3.org</span></a></span></address> 5676 <address class="vcard"><span class="vcardline"><span class="fn">Jeffrey C. Mogul</span><span class="n hidden"><span class="family-name">Mogul</span><span class="given-name">Jeffrey C.</span></span></span><span class="org vcardline">Compaq Computer Corporation</span><span class="adr"><span class="street-address vcardline">Western Research Laboratory</span><span class="street-address vcardline">250 University Avenue</span><span class="vcardline"><span class="locality">Palo Alto</span>, <span class="region">CA</span> <span class="postal-code">94305</span></span></span><span class="vcardline">EMail: <a href="mailto:mogul@wrl.dec.com"><span class="email">mogul@wrl.dec.com</span></a></span></address> 5677 <address class="vcard"><span class="vcardline"><span class="fn">Henrik Frystyk Nielsen</span><span class="n hidden"><span class="family-name">Frystyk</span></span></span><span class="org vcardline">World Wide Web Consortium</span><span class="adr"><span class="street-address vcardline">MIT Laboratory for Computer Science, NE43-356</span><span class="street-address vcardline">545 Technology Square</span><span class="vcardline"><span class="locality">Cambridge</span>, <span class="region">MA</span> <span class="postal-code">02139</span></span></span><span class="vcardline tel"><span class="type">Fax</span>: <a href="fax:+1(617)258-8682"><span class="value">+1(617)258-8682</span></a></span><span class="vcardline">EMail: <a href="mailto:frystyk@w3.org"><span class="email">frystyk@w3.org</span></a></span></address> 5678 <address class="vcard"><span class="vcardline"><span class="fn">Larry Masinter</span><span class="n hidden"><span class="family-name">Masinter</span><span class="given-name">Larry</span></span></span><span class="org vcardline">Xerox Corporation</span><span class="adr"><span class="street-address vcardline">MIT Laboratory for Computer Science, NE43-356</span><span class="street-address vcardline">3333 Coyote Hill Road</span><span class="vcardline"><span class="locality">Palo Alto</span>, <span class="region">CA</span> <span class="postal-code">94034</span></span></span><span class="vcardline">EMail: <a href="mailto:masinter@parc.xerox.com"><span class="email">masinter@parc.xerox.com</span></a></span></address> 5679 <address class="vcard"><span class="vcardline"><span class="fn">Paul J. Leach</span><span class="n hidden"><span class="family-name">Leach</span><span class="given-name">Paul J.</span></span></span><span class="org vcardline">Microsoft Corporation</span><span class="adr"><span class="street-address vcardline">1 Microsoft Way</span><span class="vcardline"><span class="locality">Redmond</span>, <span class="region">WA</span> <span class="postal-code">98052</span></span></span><span class="vcardline">EMail: <a href="mailto:paulle@microsoft.com"><span class="email">paulle@microsoft.com</span></a></span></address> 5680 <address class="vcard"><span class="vcardline"><span class="fn">Tim Berners-Lee</span><span class="n hidden"><span class="family-name">Berners-Lee</span><span class="given-name">Tim</span></span></span><span class="org vcardline">World Wide Web Consortium</span><span class="adr"><span class="street-address vcardline">MIT Laboratory for Computer Science, NE43-356</span><span class="street-address vcardline">545 Technology Square</span><span class="vcardline"><span class="locality">Cambridge</span>, <span class="region">MA</span> <span class="postal-code">02139</span></span></span><span class="vcardline tel"><span class="type">Fax</span>: <a href="fax:+1(617)258-8682"><span class="value">+1(617)258-8682</span></a></span><span class="vcardline">EMail: <a href="mailto:timbl@w3.org"><span class="email">timbl@w3.org</span></a></span></address> 5681 </div> 5677 5682 <h1 id="rfc.section.19"><a href="#rfc.section.19">19.</a> Appendices 5678 5683 </h1> … … 6058 6063 </h1> 6059 6064 <p id="rfc.section.20.p.1">Please see the PostScript version of this RFC for the INDEX.</p> 6060 <h1><a id="rfc.copyright" href="#rfc.copyright">Full Copyright Statement</a></h1>6061 <p>Copyright © The Internet Society (1999).</p>6062 <p>This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the6063 authors retain all their rights.6064 </p>6065 <p>This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION6066 HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,6067 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY6068 RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.6069 </p>6070 <h1><a id="rfc.ipr" href="#rfc.ipr">Intellectual Property</a></h1>6071 <p>The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might6072 be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any6073 license under such rights might or might not be available; nor does it represent that it has made any independent effort to6074 identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and6075 BCP 79.6076 </p>6077 <p>Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result6078 of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users6079 of this specification can be obtained from the IETF on-line IPR repository at <<a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>>.6080 </p>6081 <p>The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary6082 rights that may cover technology that may be required to implement this standard. Please address the information to the IETF6083 at <a href="mailto:ietf-ipr@ietf.org">ietf-ipr@ietf.org</a>.6084 </p>6085 6065 <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1> 6086 6066 <p class="noprint"><a href="#rfc.index.1">1</a> <a href="#rfc.index.2">2</a> <a href="#rfc.index.3">3</a> <a href="#rfc.index.4">4</a> <a href="#rfc.index.5">5</a> <a href="#rfc.index.A">A</a> <a href="#rfc.index.C">C</a> <a href="#rfc.index.D">D</a> <a href="#rfc.index.E">E</a> <a href="#rfc.index.F">F</a> <a href="#rfc.index.G">G</a> <a href="#rfc.index.H">H</a> <a href="#rfc.index.I">I</a> <a href="#rfc.index.L">L</a> <a href="#rfc.index.M">M</a> <a href="#rfc.index.N">N</a> <a href="#rfc.index.O">O</a> <a href="#rfc.index.P">P</a> <a href="#rfc.index.R">R</a> <a href="#rfc.index.S">S</a> <a href="#rfc.index.T">T</a> <a href="#rfc.index.U">U</a> <a href="#rfc.index.V">V</a> <a href="#rfc.index.W">W</a> … … 6763 6743 </ul> 6764 6744 </div> 6745 <h1><a id="rfc.copyright" href="#rfc.copyright">Full Copyright Statement</a></h1> 6746 <p>Copyright © The Internet Society (1999).</p> 6747 <p>This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the 6748 authors retain all their rights. 6749 </p> 6750 <p>This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION 6751 HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 6752 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 6753 RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 6754 </p> 6755 <h1><a id="rfc.ipr" href="#rfc.ipr">Intellectual Property</a></h1> 6756 <p>The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might 6757 be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any 6758 license under such rights might or might not be available; nor does it represent that it has made any independent effort to 6759 identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and 6760 BCP 79. 6761 </p> 6762 <p>Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result 6763 of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users 6764 of this specification can be obtained from the IETF on-line IPR repository at <a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>. 6765 </p> 6766 <p>The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary 6767 rights that may cover technology that may be required to implement this standard. Please address the information to the IETF 6768 at <a href="mailto:ietf-ipr@ietf.org">ietf-ipr@ietf.org</a>. 6769 </p> 6765 6770 </body> 6766 6771 </html> -
draft-ietf-httpbis/orig/rfc2616.html
r598 r978 37 37 } 38 38 39 dl.empty dd { 39 ul.empty { 40 list-style-type: none; 41 } 42 ul.empty li { 40 43 margin-top: .5em; 41 44 } … … 118 121 } 119 122 table.header { 123 border-spacing: 1px; 120 124 width: 95%; 121 125 font-size: 10pt; … … 129 133 white-space: nowrap; 130 134 } 131 t d.header{135 table.header td { 132 136 background-color: gray; 133 137 width: 50%; 134 138 } 135 t d.header a {139 table.header a { 136 140 color: white; 137 141 } … … 188 192 margin-left: 0em; 189 193 margin-right: 0em; 194 } 195 .avoidbreak { 196 page-break-inside: avoid; 190 197 } 191 198 .bcp14 { … … 340 347 <link rel="Alternate" title="Authorative ASCII Version" href="http://www.ietf.org/rfc/rfc2616.txt"> 341 348 <link rel="Help" title="Additional Information on tools.ietf.org" href="http://tools.ietf.org/html/rfc2616"> 342 <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.438, 2009-05-27 13:34:05, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/"> 343 <link rel="schema.DC" href="http://purl.org/dc/elements/1.1/"> 344 <meta name="DC.Creator" content="Fielding, R."> 345 <meta name="DC.Creator" content="Gettys, J."> 346 <meta name="DC.Creator" content="Mogul, J."> 347 <meta name="DC.Creator" content="Frystyk, H."> 348 <meta name="DC.Creator" content="Masinter, L."> 349 <meta name="DC.Creator" content="Leach, P."> 350 <meta name="DC.Creator" content="Berners-Lee, T."> 351 <meta name="DC.Identifier" content="urn:ietf:rfc:2616"> 352 <meta name="DC.Date.Issued" scheme="ISO8601" content="1999-06"> 353 <meta name="DC.Relation.Replaces" content="urn:ietf:rfc:2068"> 354 <meta name="DC.Description.Abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, protocol which can be used for many tasks beyond its use for hypertext, such as name servers and distributed object management systems, through extension of its request methods, error codes and headers . A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred. HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as "HTTP/1.1", and is an update to RFC 2068 ."> 355 <meta name="DC.isPartOf" content="urn:ISSN:2070-1721"> 349 <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.520, 2010-07-14 12:36:35, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/"> 350 <link rel="schema.dct" href="http://purl.org/dc/terms/"> 351 <meta name="dct.creator" content="Fielding, R."> 352 <meta name="dct.creator" content="Gettys, J."> 353 <meta name="dct.creator" content="Mogul, J."> 354 <meta name="dct.creator" content="Frystyk, H."> 355 <meta name="dct.creator" content="Masinter, L."> 356 <meta name="dct.creator" content="Leach, P."> 357 <meta name="dct.creator" content="Berners-Lee, T."> 358 <meta name="dct.identifier" content="urn:ietf:rfc:2616"> 359 <meta name="dct.issued" scheme="ISO8601" content="1999-06"> 360 <meta name="dct.replaces" content="urn:ietf:rfc:2068"> 361 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, protocol which can be used for many tasks beyond its use for hypertext, such as name servers and distributed object management systems, through extension of its request methods, error codes and headers . A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred. HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as "HTTP/1.1", and is an update to RFC 2068 ."> 362 <meta name="dct.isPartOf" content="urn:issn:2070-1721"> 363 <meta name="description" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, protocol which can be used for many tasks beyond its use for hypertext, such as name servers and distributed object management systems, through extension of its request methods, error codes and headers . A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred. HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as "HTTP/1.1", and is an update to RFC 2068 ."> 356 364 </head> 357 365 <body> 358 <table summary="header information" class="header" border="0" cellpadding="1" cellspacing="1"> 359 <tr> 360 <td class="header left">Network Working Group</td> 361 <td class="header right">R. Fielding</td> 362 </tr> 363 <tr> 364 <td class="header left">Request for Comments: 2616</td> 365 <td class="header right">UC Irvine</td> 366 </tr> 367 <tr> 368 <td class="header left">Obsoletes: <a href="http://tools.ietf.org/html/rfc2068">2068</a></td> 369 <td class="header right">J. Gettys</td> 370 </tr> 371 <tr> 372 <td class="header left">Category: Standards Track</td> 373 <td class="header right">Compaq/W3C</td> 374 </tr> 375 <tr> 376 <td class="header left"></td> 377 <td class="header right">J. Mogul</td> 378 </tr> 379 <tr> 380 <td class="header left"></td> 381 <td class="header right">Compaq</td> 382 </tr> 383 <tr> 384 <td class="header left"></td> 385 <td class="header right">H. Frystyk</td> 386 </tr> 387 <tr> 388 <td class="header left"></td> 389 <td class="header right">W3C/MIT</td> 390 </tr> 391 <tr> 392 <td class="header left"></td> 393 <td class="header right">L. Masinter</td> 394 </tr> 395 <tr> 396 <td class="header left"></td> 397 <td class="header right">Xerox</td> 398 </tr> 399 <tr> 400 <td class="header left"></td> 401 <td class="header right">P. Leach</td> 402 </tr> 403 <tr> 404 <td class="header left"></td> 405 <td class="header right">Microsoft</td> 406 </tr> 407 <tr> 408 <td class="header left"></td> 409 <td class="header right">T. Berners-Lee</td> 410 </tr> 411 <tr> 412 <td class="header left"></td> 413 <td class="header right">W3C/MIT</td> 414 </tr> 415 <tr> 416 <td class="header left"></td> 417 <td class="header right">June 1999</td> 418 </tr> 366 <table class="header"> 367 <tbody> 368 <tr> 369 <td class="left">Network Working Group</td> 370 <td class="right">R. Fielding</td> 371 </tr> 372 <tr> 373 <td class="left">Request for Comments: 2616</td> 374 <td class="right">UC Irvine</td> 375 </tr> 376 <tr> 377 <td class="left">Obsoletes: <a href="http://tools.ietf.org/html/rfc2068">2068</a></td> 378 <td class="right">J. Gettys</td> 379 </tr> 380 <tr> 381 <td class="left">Category: Standards Track</td> 382 <td class="right">Compaq/W3C</td> 383 </tr> 384 <tr> 385 <td class="left"></td> 386 <td class="right">J. Mogul</td> 387 </tr> 388 <tr> 389 <td class="left"></td> 390 <td class="right">Compaq</td> 391 </tr> 392 <tr> 393 <td class="left"></td> 394 <td class="right">H. Frystyk</td> 395 </tr> 396 <tr> 397 <td class="left"></td> 398 <td class="right">W3C/MIT</td> 399 </tr> 400 <tr> 401 <td class="left"></td> 402 <td class="right">L. Masinter</td> 403 </tr> 404 <tr> 405 <td class="left"></td> 406 <td class="right">Xerox</td> 407 </tr> 408 <tr> 409 <td class="left"></td> 410 <td class="right">P. Leach</td> 411 </tr> 412 <tr> 413 <td class="left"></td> 414 <td class="right">Microsoft</td> 415 </tr> 416 <tr> 417 <td class="left"></td> 418 <td class="right">T. Berners-Lee</td> 419 </tr> 420 <tr> 421 <td class="left"></td> 422 <td class="right">W3C/MIT</td> 423 </tr> 424 <tr> 425 <td class="left"></td> 426 <td class="right">June 1999</td> 427 </tr> 428 </tbody> 419 429 </table> 420 430 <p class="title">Hypertext Transfer Protocol -- HTTP/1.1</p> … … 784 794 </li> 785 795 <li class="tocline0">20. <a href="#rfc.section.20">Index</a></li> 796 <li class="tocline0"><a href="#rfc.index">Index</a></li> 786 797 <li class="tocline0"><a href="#rfc.ipr">Intellectual Property and Copyright Statements</a></li> 787 <li class="tocline0"><a href="#rfc.index">Index</a></li>788 798 </ul> 789 799 <hr class="noprint"> … … 818 828 <p id="rfc.section.1.3.p.2"> <span id="rfc.iref.c.1"></span> <dfn>connection</dfn> 819 829 </p> 820 < dl class="empty">821 < dd>A transport layer virtual circuit established between two programs for the purpose of communication.</dd>822 </ dl>830 <ul class="empty"> 831 <li>A transport layer virtual circuit established between two programs for the purpose of communication.</li> 832 </ul> 823 833 <p id="rfc.section.1.3.p.3"> <span id="rfc.iref.m.1"></span> <dfn>message</dfn> 824 834 </p> 825 < dl class="empty">826 < dd>The basic unit of HTTP communication, consisting of a structured sequence of octets matching the syntax defined in <a href="#http.message" title="HTTP Message">Section 4</a> and transmitted via the connection.827 </ dd>828 </ dl>835 <ul class="empty"> 836 <li>The basic unit of HTTP communication, consisting of a structured sequence of octets matching the syntax defined in <a href="#http.message" title="HTTP Message">Section 4</a> and transmitted via the connection. 837 </li> 838 </ul> 829 839 <p id="rfc.section.1.3.p.4"> <span id="rfc.iref.r.1"></span> <dfn>request</dfn> 830 840 </p> 831 < dl class="empty">832 < dd>An HTTP request message, as defined in <a href="#request" title="Request">Section 5</a>.833 </ dd>834 </ dl>841 <ul class="empty"> 842 <li>An HTTP request message, as defined in <a href="#request" title="Request">Section 5</a>. 843 </li> 844 </ul> 835 845 <p id="rfc.section.1.3.p.5"> <span id="rfc.iref.r.2"></span> <dfn>response</dfn> 836 846 </p> 837 < dl class="empty">838 < dd>An HTTP response message, as defined in <a href="#response" title="Response">Section 6</a>.839 </ dd>840 </ dl>847 <ul class="empty"> 848 <li>An HTTP response message, as defined in <a href="#response" title="Response">Section 6</a>. 849 </li> 850 </ul> 841 851 <p id="rfc.section.1.3.p.6"> <span id="rfc.iref.r.3"></span> <dfn>resource</dfn> 842 852 </p> 843 < dl class="empty">844 < dd>A network data object or service that can be identified by a URI, as defined in <a href="#uri" title="Uniform Resource Identifiers">Section 3.2</a>. Resources may be available in multiple representations (e.g. multiple languages, data formats, size, and resolutions) or853 <ul class="empty"> 854 <li>A network data object or service that can be identified by a URI, as defined in <a href="#uri" title="Uniform Resource Identifiers">Section 3.2</a>. Resources may be available in multiple representations (e.g. multiple languages, data formats, size, and resolutions) or 845 855 vary in other ways. 846 </ dd>847 </ dl>856 </li> 857 </ul> 848 858 <p id="rfc.section.1.3.p.7"> <span id="rfc.iref.e.1"></span> <dfn>entity</dfn> 849 859 </p> 850 < dl class="empty">851 < dd>The information transferred as the payload of a request or response. An entity consists of metainformation in the form of860 <ul class="empty"> 861 <li>The information transferred as the payload of a request or response. An entity consists of metainformation in the form of 852 862 entity-header fields and content in the form of an entity-body, as described in <a href="#entity" title="Entity">Section 7</a>. 853 </ dd>854 </ dl>863 </li> 864 </ul> 855 865 <p id="rfc.section.1.3.p.8"> <span id="rfc.iref.r.4"></span> <dfn>representation</dfn> 856 866 </p> 857 < dl class="empty">858 < dd>An entity included with a response that is subject to content negotiation, as described in <a href="#content.negotiation" title="Content Negotiation">Section 12</a>. There may exist multiple representations associated with a particular response status.859 </ dd>860 </ dl>867 <ul class="empty"> 868 <li>An entity included with a response that is subject to content negotiation, as described in <a href="#content.negotiation" title="Content Negotiation">Section 12</a>. There may exist multiple representations associated with a particular response status. 869 </li> 870 </ul> 861 871 <p id="rfc.section.1.3.p.9"> <span id="rfc.iref.c.2"></span> <dfn>content negotiation</dfn> 862 872 </p> 863 < dl class="empty">864 < dd>The mechanism for selecting the appropriate representation when servicing a request, as described in <a href="#content.negotiation" title="Content Negotiation">Section 12</a>. The representation of entities in any response can be negotiated (including error responses).865 </ dd>866 </ dl>873 <ul class="empty"> 874 <li>The mechanism for selecting the appropriate representation when servicing a request, as described in <a href="#content.negotiation" title="Content Negotiation">Section 12</a>. The representation of entities in any response can be negotiated (including error responses). 875 </li> 876 </ul> 867 877 <p id="rfc.section.1.3.p.10"> <span id="rfc.iref.v.1"></span> <dfn>variant</dfn> 868 878 </p> 869 < dl class="empty">870 < dd>A resource may have one, or more than one, representation(s) associated with it at any given instant. Each of these representations879 <ul class="empty"> 880 <li>A resource may have one, or more than one, representation(s) associated with it at any given instant. Each of these representations 871 881 is termed a `varriant'. Use of the term `variant' does not necessarily imply that the resource is subject to content negotiation. 872 </ dd>873 </ dl>882 </li> 883 </ul> 874 884 <p id="rfc.section.1.3.p.11"> <span id="rfc.iref.c.3"></span> <dfn>client</dfn> 875 885 </p> 876 < dl class="empty">877 < dd>A program that establishes connections for the purpose of sending requests.</dd>878 </ dl>886 <ul class="empty"> 887 <li>A program that establishes connections for the purpose of sending requests.</li> 888 </ul> 879 889 <p id="rfc.section.1.3.p.12"> <span id="rfc.iref.u.1"></span> <dfn>user agent</dfn> 880 890 </p> 881 < dl class="empty">882 < dd>The client which initiates a request. These are often browsers, editors, spiders (web-traversing robots), or other end user891 <ul class="empty"> 892 <li>The client which initiates a request. These are often browsers, editors, spiders (web-traversing robots), or other end user 883 893 tools. 884 </ dd>885 </ dl>894 </li> 895 </ul> 886 896 <p id="rfc.section.1.3.p.13"> <span id="rfc.iref.s.1"></span> <dfn>server</dfn> 887 897 </p> 888 < dl class="empty">889 < dd>An application program that accepts connections in order to service requests by sending back responses. Any given program898 <ul class="empty"> 899 <li>An application program that accepts connections in order to service requests by sending back responses. Any given program 890 900 may be capable of being both a client and a server; our use of these terms refers only to the role being performed by the 891 901 program for a particular connection, rather than to the program's capabilities in general. Likewise, any server may act as 892 902 an origin server, proxy, gateway, or tunnel, switching behavior based on the nature of each request. 893 </ dd>894 </ dl>903 </li> 904 </ul> 895 905 <p id="rfc.section.1.3.p.14"> <span id="rfc.iref.o.1"></span> <dfn>origin server</dfn> 896 906 </p> 897 < dl class="empty">898 < dd>The server on which a given resource resides or is to be created.</dd>899 </ dl>907 <ul class="empty"> 908 <li>The server on which a given resource resides or is to be created.</li> 909 </ul> 900 910 <p id="rfc.section.1.3.p.15"> <span id="rfc.iref.p.1"></span> <dfn>proxy</dfn> 901 911 </p> 902 < dl class="empty">903 < dd>An intermediary program which acts as both a server and a client for the purpose of making requests on behalf of other clients.912 <ul class="empty"> 913 <li>An intermediary program which acts as both a server and a client for the purpose of making requests on behalf of other clients. 904 914 Requests are serviced internally or by passing them on, with possible translation, to other servers. A proxy <em class="bcp14">MUST</em> implement both the client and server requirements of this specification. A "transparent proxy" is a proxy that does not modify 905 915 the request or response beyond what is required for proxy authentication and identification. A "non-transparent proxy" is … … 907 917 services, media type transformation, protocol reduction, or anonymity filtering. Except where either transparent or non-transparent 908 918 behavior is explicitly stated, the HTTP proxy requirements apply to both types of proxies. 909 </ dd>910 </ dl>919 </li> 920 </ul> 911 921 <p id="rfc.section.1.3.p.16"> <span id="rfc.iref.g.1"></span> <dfn>gateway</dfn> 912 922 </p> 913 < dl class="empty">914 < dd>A server which acts as an intermediary for some other server. Unlike a proxy, a gateway receives requests as if it were the923 <ul class="empty"> 924 <li>A server which acts as an intermediary for some other server. Unlike a proxy, a gateway receives requests as if it were the 915 925 origin server for the requested resource; the requesting client may not be aware that it is communicating with a gateway. 916 </ dd>917 </ dl>926 </li> 927 </ul> 918 928 <p id="rfc.section.1.3.p.17"> <span id="rfc.iref.t.1"></span> <dfn>tunnel</dfn> 919 929 </p> 920 < dl class="empty">921 < dd>An intermediary program which is acting as a blind relay between two connections. Once active, a tunnel is not considered930 <ul class="empty"> 931 <li>An intermediary program which is acting as a blind relay between two connections. Once active, a tunnel is not considered 922 932 a party to the HTTP communication, though the tunnel may have been initiated by an HTTP request. The tunnel ceases to exist 923 933 when both ends of the relayed connections are closed. 924 </ dd>925 </ dl>934 </li> 935 </ul> 926 936 <p id="rfc.section.1.3.p.18"> <span id="rfc.iref.c.4"></span> <dfn>cache</dfn> 927 937 </p> 928 < dl class="empty">929 < dd>A program's local store of response messages and the subsystem that controls its message storage, retrieval, and deletion.938 <ul class="empty"> 939 <li>A program's local store of response messages and the subsystem that controls its message storage, retrieval, and deletion. 930 940 A cache stores cacheable responses in order to reduce the response time and network bandwidth consumption on future, equivalent 931 941 requests. Any client or server may include a cache, though a cache cannot be used by a server that is acting as a tunnel. 932 </ dd>933 </ dl>942 </li> 943 </ul> 934 944 <p id="rfc.section.1.3.p.19"> <span id="rfc.iref.c.5"></span> <dfn>cacheable</dfn> 935 945 </p> 936 < dl class="empty">937 < dd>A response is cacheable if a cache is allowed to store a copy of the response message for use in answering subsequent requests.946 <ul class="empty"> 947 <li>A response is cacheable if a cache is allowed to store a copy of the response message for use in answering subsequent requests. 938 948 The rules for determining the cacheability of HTTP responses are defined in <a href="#caching" title="Caching in HTTP">Section 13</a>. Even if a resource is cacheable, there may be additional constraints on whether a cache can use the cached copy for a particular 939 949 request. 940 </ dd>941 </ dl>950 </li> 951 </ul> 942 952 <p id="rfc.section.1.3.p.20"> <span id="rfc.iref.f.1"></span> <dfn>first-hand</dfn> 943 953 </p> 944 < dl class="empty">945 < dd>A response is first-hand if it comes directly and without unnecessary delay from the origin server, perhaps via one or more954 <ul class="empty"> 955 <li>A response is first-hand if it comes directly and without unnecessary delay from the origin server, perhaps via one or more 946 956 proxies. A response is also first-hand if its validity has just been checked directly with the origin server. 947 </ dd>948 </ dl>957 </li> 958 </ul> 949 959 <p id="rfc.section.1.3.p.21"> <span id="rfc.iref.e.2"></span> <dfn>explicit expiration time</dfn> 950 960 </p> 951 < dl class="empty">952 < dd>The time at which the origin server intends that an entity should no longer be returned by a cache without further validation.</dd>953 </ dl>961 <ul class="empty"> 962 <li>The time at which the origin server intends that an entity should no longer be returned by a cache without further validation.</li> 963 </ul> 954 964 <p id="rfc.section.1.3.p.22"> <span id="rfc.iref.h.1"></span> <dfn>heuristic expiration time</dfn> 955 965 </p> 956 < dl class="empty">957 < dd>An expiration time assigned by a cache when no explicit expiration time is available.</dd>958 </ dl>966 <ul class="empty"> 967 <li>An expiration time assigned by a cache when no explicit expiration time is available.</li> 968 </ul> 959 969 <p id="rfc.section.1.3.p.23"> <span id="rfc.iref.a.1"></span> <dfn>age</dfn> 960 970 </p> 961 < dl class="empty">962 < dd>The age of a response is the time since it was sent by, or successfully validated with, the origin server.</dd>963 </ dl>971 <ul class="empty"> 972 <li>The age of a response is the time since it was sent by, or successfully validated with, the origin server.</li> 973 </ul> 964 974 <p id="rfc.section.1.3.p.24"> <span id="rfc.iref.f.2"></span> <dfn>freshness lifetime</dfn> 965 975 </p> 966 < dl class="empty">967 < dd>The length of time between the generation of a response and its expiration time.</dd>968 </ dl>976 <ul class="empty"> 977 <li>The length of time between the generation of a response and its expiration time.</li> 978 </ul> 969 979 <p id="rfc.section.1.3.p.25"> <span id="rfc.iref.f.3"></span> <dfn>fresh</dfn> 970 980 </p> 971 < dl class="empty">972 < dd>A response is fresh if its age has not yet exceeded its freshness lifetime.</dd>973 </ dl>981 <ul class="empty"> 982 <li>A response is fresh if its age has not yet exceeded its freshness lifetime.</li> 983 </ul> 974 984 <p id="rfc.section.1.3.p.26"> <span id="rfc.iref.s.2"></span> <dfn>stale</dfn> 975 985 </p> 976 < dl class="empty">977 < dd>A response is stale if its age has passed its freshness lifetime.</dd>978 </ dl>986 <ul class="empty"> 987 <li>A response is stale if its age has passed its freshness lifetime.</li> 988 </ul> 979 989 <p id="rfc.section.1.3.p.27"> <span id="rfc.iref.s.3"></span> <dfn>semantically transparent</dfn> 980 990 </p> 981 < dl class="empty">982 < dd>A cache behaves in a "semantically transparent" manner, with respect to a particular response, when its use affects neither991 <ul class="empty"> 992 <li>A cache behaves in a "semantically transparent" manner, with respect to a particular response, when its use affects neither 983 993 the requesting client nor the origin server, except to improve performance. When a cache is semantically transparent, the 984 994 client receives exactly the same response (except for hop-by-hop headers) that it would have received had its request been 985 995 handled directly by the origin server. 986 </ dd>987 </ dl>996 </li> 997 </ul> 988 998 <p id="rfc.section.1.3.p.28"> <span id="rfc.iref.v.2"></span> <dfn>validator</dfn> 989 999 </p> 990 < dl class="empty">991 < dd>A protocol element (e.g., an entity tag or a Last-Modified time) that is used to find out whether a cache entry is an equivalent1000 <ul class="empty"> 1001 <li>A protocol element (e.g., an entity tag or a Last-Modified time) that is used to find out whether a cache entry is an equivalent 992 1002 copy of an entity. 993 </ dd>994 </ dl>1003 </li> 1004 </ul> 995 1005 <p id="rfc.section.1.3.p.29"> <span id="rfc.iref.u.2"></span> <span id="rfc.iref.d.1"></span> <dfn>upstream</dfn>/<dfn>downstream</dfn> 996 1006 </p> 997 < dl class="empty">998 < dd>Upstream and downstream describe the flow of a message: all messages flow from upstream to downstream.</dd>999 </ dl>1007 <ul class="empty"> 1008 <li>Upstream and downstream describe the flow of a message: all messages flow from upstream to downstream.</li> 1009 </ul> 1000 1010 <p id="rfc.section.1.3.p.30"> <span id="rfc.iref.i.1"></span> <span id="rfc.iref.o.2"></span> <dfn>inbound</dfn>/<dfn>outbound</dfn> 1001 1011 </p> 1002 < dl class="empty">1003 < dd>Inbound and outbound refer to the request and response paths for messages: "inbound" means "traveling toward the origin server",1012 <ul class="empty"> 1013 <li>Inbound and outbound refer to the request and response paths for messages: "inbound" means "traveling toward the origin server", 1004 1014 and "outbound" means "traveling toward the user agent" 1005 </ dd>1006 </ dl>1015 </li> 1016 </ul> 1007 1017 <h2 id="rfc.section.1.4"><a href="#rfc.section.1.4">1.4</a> <a id="intro.overall.operation" href="#intro.overall.operation">Overall Operation</a></h2> 1008 1018 <p id="rfc.section.1.4.p.1">The HTTP protocol is a request/response protocol. A client sends a request to the server in the form of a request method, … … 1072 1082 </p> 1073 1083 <p id="rfc.section.2.1.p.2">name = definition </p> 1074 < dl class="empty">1075 < dd>The name of a rule is simply the name itself (without any enclosing "<" and ">") and is separated from its definition by the1084 <ul class="empty"> 1085 <li>The name of a rule is simply the name itself (without any enclosing "<" and ">") and is separated from its definition by the 1076 1086 equal "=" character. White space is only significant in that indentation of continuation lines is used to indicate a rule 1077 1087 definition that spans more than one line. Certain basic rules are in uppercase, such as <a href="#basic.rules" class="smpl" id="rfc.extref.s.1">SP</a>, <a href="#basic.rules.lws" class="smpl" id="rfc.extref.l.1">LWS</a>, <a href="#basic.rules" class="smpl" id="rfc.extref.h.1">HT</a>, <a href="#basic.rules.crlf" class="smpl" id="rfc.extref.c.1">CRLF</a>, <a href="#basic.rules" class="smpl" id="rfc.extref.d.1">DIGIT</a>, <a href="#basic.rules" class="smpl" id="rfc.extref.a.1">ALPHA</a>, etc. Angle brackets are used within definitions whenever their presence will facilitate discerning the use of rule names. 1078 </ dd>1079 </ dl>1088 </li> 1089 </ul> 1080 1090 <p id="rfc.section.2.1.p.3">"literal" </p> 1081 < dl class="empty">1082 < dd>Quotation marks surround literal text. Unless stated otherwise, the text is case-insensitive.</dd>1083 </ dl>1091 <ul class="empty"> 1092 <li>Quotation marks surround literal text. Unless stated otherwise, the text is case-insensitive.</li> 1093 </ul> 1084 1094 <p id="rfc.section.2.1.p.4">rule1 | rule2 </p> 1085 < dl class="empty">1086 < dd>Elements separated by a bar ("|") are alternatives, e.g., "yes | no" will accept yes or no.</dd>1087 </ dl>1095 <ul class="empty"> 1096 <li>Elements separated by a bar ("|") are alternatives, e.g., "yes | no" will accept yes or no.</li> 1097 </ul> 1088 1098 <p id="rfc.section.2.1.p.5">(rule1 rule2) </p> 1089 < dl class="empty">1090 < dd>Elements enclosed in parentheses are treated as a single element. Thus, "(elem (foo | bar) elem)" allows the token sequences1099 <ul class="empty"> 1100 <li>Elements enclosed in parentheses are treated as a single element. Thus, "(elem (foo | bar) elem)" allows the token sequences 1091 1101 "elem foo elem" and "elem bar elem". 1092 </ dd>1093 </ dl>1102 </li> 1103 </ul> 1094 1104 <p id="rfc.section.2.1.p.6">*rule </p> 1095 < dl class="empty">1096 < dd>The character "*" preceding an element indicates repetition. The full form is "<n>*<m>element" indicating at least <n> and1105 <ul class="empty"> 1106 <li>The character "*" preceding an element indicates repetition. The full form is "<n>*<m>element" indicating at least <n> and 1097 1107 at most <m> occurrences of element. Default values are 0 and infinity so that "*(element)" allows any number, including zero; 1098 1108 "1*element" requires at least one; and "1*2element" allows one or two. 1099 </ dd>1100 </ dl>1109 </li> 1110 </ul> 1101 1111 <p id="rfc.section.2.1.p.7">[rule] </p> 1102 < dl class="empty">1103 < dd>Square brackets enclose optional elements; "[foo bar]" is equivalent to "*1(foo bar)".</dd>1104 </ dl>1112 <ul class="empty"> 1113 <li>Square brackets enclose optional elements; "[foo bar]" is equivalent to "*1(foo bar)".</li> 1114 </ul> 1105 1115 <p id="rfc.section.2.1.p.8">N rule </p> 1106 < dl class="empty">1107 < dd>Specific repetition: "<n>(element)" is equivalent to "<n>*<n>(element)"; that is, exactly <n> occurrences of (element). Thus1116 <ul class="empty"> 1117 <li>Specific repetition: "<n>(element)" is equivalent to "<n>*<n>(element)"; that is, exactly <n> occurrences of (element). Thus 1108 1118 2DIGIT is a 2-digit number, and 3ALPHA is a string of three alphabetic characters. 1109 </ dd>1110 </ dl>1119 </li> 1120 </ul> 1111 1121 <p id="rfc.section.2.1.p.9">#rule </p> 1112 < dl class="empty">1113 < dd>A construct "#" is defined, similar to "*", for defining lists of elements. The full form is "<n>#<m>element" indicating at1122 <ul class="empty"> 1123 <li>A construct "#" is defined, similar to "*", for defining lists of elements. The full form is "<n>#<m>element" indicating at 1114 1124 least <n> and at most <m> elements, each separated by one or more commas (",") and <em class="bcp14">OPTIONAL</em> linear white space (LWS). This makes the usual form of lists very easy; a rule such as 1115 1125 <div id="rfc.figure.u.4"></div><pre class="text"> ( *LWS element *( *LWS "," *LWS element )) 1116 </pre> </ dd>1117 < dd>can be shown as1126 </pre> </li> 1127 <li>can be shown as 1118 1128 <div id="rfc.figure.u.5"></div><pre class="text"> 1#element 1119 </pre> </ dd>1120 < dd>Wherever this construct is used, null elements are allowed, but do not contribute to the count of elements present. That is,1129 </pre> </li> 1130 <li>Wherever this construct is used, null elements are allowed, but do not contribute to the count of elements present. That is, 1121 1131 "(element), , (element) " is permitted, but counts as only two elements. Therefore, where at least one element is required, 1122 1132 at least one non-null element <em class="bcp14">MUST</em> be present. Default values are 0 and infinity so that "#element" allows any number, including zero; "1#element" requires at 1123 1133 least one; and "1#2element" allows one or two. 1124 </ dd>1125 </ dl>1134 </li> 1135 </ul> 1126 1136 <p id="rfc.section.2.1.p.10">; comment </p> 1127 < dl class="empty">1128 < dd>A semi-colon, set off some distance to the right of rule text, starts a comment that continues to the end of line. This is1137 <ul class="empty"> 1138 <li>A semi-colon, set off some distance to the right of rule text, starts a comment that continues to the end of line. This is 1129 1139 a simple way of including useful notes in parallel with the specifications. 1130 </ dd>1131 </ dl>1140 </li> 1141 </ul> 1132 1142 <div id="implied.LWS"> 1133 1143 <p id="rfc.section.2.1.p.11">implied *LWS </p> 1134 < dl class="empty">1135 < dd>The grammar described by this specification is word-based. Except where noted otherwise, linear white space (LWS) can be included1144 <ul class="empty"> 1145 <li>The grammar described by this specification is word-based. Except where noted otherwise, linear white space (LWS) can be included 1136 1146 between any two adjacent words (token or quoted-string), and between adjacent words and separators, without changing the interpretation 1137 1147 of a field. At least one delimiter (LWS and/or separators) <em class="bcp14">MUST</em> exist between any two tokens (for the definition of "token" below), since they would otherwise be interpreted as a single 1138 1148 token. 1139 </ dd>1140 </ dl>1149 </li> 1150 </ul> 1141 1151 </div> 1142 1152 <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a> <a id="basic.rules" href="#basic.rules">Basic Rules</a></h2> … … 1237 1247 </p> 1238 1248 <p id="rfc.section.3.1.p.9"> </p> 1239 < dl class="empty">1240 < dd> <b>Note:</b> Converting between versions of HTTP may involve modification of header fields required or forbidden by the versions involved.1241 </ dd>1242 </ dl>1249 <ul class="empty"> 1250 <li> <b>Note:</b> Converting between versions of HTTP may involve modification of header fields required or forbidden by the versions involved. 1251 </li> 1252 </ul> 1243 1253 <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a> <a id="uri" href="#uri">Uniform Resource Identifiers</a></h2> 1244 1254 <p id="rfc.section.3.2.p.1">URIs have been known by many names: WWW addresses, Universal Document Identifiers, Universal Resource Identifiers <a href="#RFC1630" id="rfc.xref.RFC1630.2"><cite title="Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World-Wide Web">[3]</cite></a>, and finally the combination of Uniform Resource Locators (URL) <a href="#RFC1738" id="rfc.xref.RFC1738.2"><cite title="Uniform Resource Locators (URL)">[4]</cite></a> and Names (URN) <a href="#RFC1737" id="rfc.xref.RFC1737.2"><cite title="Functional Requirements for Uniform Resource Names">[20]</cite></a>. As far as HTTP is concerned, Uniform Resource Identifiers are simply formatted strings which identify--via name, location, … … 1254 1264 </p> 1255 1265 <p id="rfc.section.3.2.1.p.3"> </p> 1256 < dl class="empty">1257 < dd> <b>Note:</b> Servers ought to be cautious about depending on URI lengths above 255 bytes, because some older client or proxy implementations1266 <ul class="empty"> 1267 <li> <b>Note:</b> Servers ought to be cautious about depending on URI lengths above 255 bytes, because some older client or proxy implementations 1258 1268 might not properly support these lengths. 1259 </ dd>1260 </ dl>1269 </li> 1270 </ul> 1261 1271 <div id="rfc.iref.h.2"></div> 1262 1272 <div id="rfc.iref.u.3"></div> … … 1294 1304 </pre><p id="rfc.section.3.3.1.p.3">The first format is preferred as an Internet standard and represents a fixed-length subset of that defined by RFC 1123 <a href="#RFC1123" id="rfc.xref.RFC1123.1"><cite title="Requirements for Internet Hosts - Application and Support">[8]</cite></a> (an update to RFC 822 <a href="#RFC822" id="rfc.xref.RFC822.3"><cite title="Standard for the format of ARPA Internet text messages">[9]</cite></a>). The second format is in common use, but is based on the obsolete RFC 850 <a href="#RFC1036" id="rfc.xref.RFC1036.1"><cite title="Standard for interchange of USENET messages">[12]</cite></a> date format and lacks a four-digit year. HTTP/1.1 clients and servers that parse the date value <em class="bcp14">MUST</em> accept all three formats (for compatibility with HTTP/1.0), though they <em class="bcp14">MUST</em> only generate the RFC 1123 format for representing HTTP-date values in header fields. See <a href="#tolerant.applications" title="Tolerant Applications">Appendix 19.3</a> for further information. 1295 1305 </p> 1296 < dl class="empty">1297 < dd> <b>Note:</b> Recipients of date values are encouraged to be robust in accepting date values that may have been sent by non-HTTP applications,1306 <ul class="empty"> 1307 <li> <b>Note:</b> Recipients of date values are encouraged to be robust in accepting date values that may have been sent by non-HTTP applications, 1298 1308 as is sometimes the case when retrieving or posting messages via proxies/gateways to SMTP or NNTP. 1299 </ dd>1300 </ dl>1309 </li> 1310 </ul> 1301 1311 <p id="rfc.section.3.3.1.p.5">All HTTP date/time stamps <em class="bcp14">MUST</em> be represented in Greenwich Mean Time (GMT), without exception. For the purposes of HTTP, GMT is exactly equal to UTC (Coordinated 1302 1312 Universal Time). This is indicated in the first two formats by the inclusion of "GMT" as the three-letter abbreviation for … … 1340 1350 to determine the exact mapping is not permitted. 1341 1351 </p> 1342 < dl class="empty">1343 < dd> <b>Note:</b> This use of the term "character set" is more commonly referred to as a "character encoding." However, since HTTP and MIME1352 <ul class="empty"> 1353 <li> <b>Note:</b> This use of the term "character set" is more commonly referred to as a "character encoding." However, since HTTP and MIME 1344 1354 share the same registry, it is important that the terminology also be shared. 1345 </ dd>1346 </ dl>1355 </li> 1356 </ul> 1347 1357 <div id="charset"> 1348 1358 <p id="rfc.section.3.4.p.4"> HTTP character sets are identified by case-insensitive tokens. The complete set of tokens is defined by the IANA Character … … 1379 1389 <p id="rfc.section.3.5.p.5">gzip<span id="rfc.iref.g.40"></span><span id="rfc.iref.c.7"></span> 1380 1390 </p> 1381 < dl class="empty">1382 < dd>An encoding format produced by the file compression program "gzip" (GNU zip) as described in RFC 1952 <a href="#RFC1952" id="rfc.xref.RFC1952.1"><cite title="GZIP file format specification version 4.3">[25]</cite></a>. This format is a Lempel-Ziv coding (LZ77) with a 32 bit CRC.1383 </ dd>1384 </ dl>1391 <ul class="empty"> 1392 <li>An encoding format produced by the file compression program "gzip" (GNU zip) as described in RFC 1952 <a href="#RFC1952" id="rfc.xref.RFC1952.1"><cite title="GZIP file format specification version 4.3">[25]</cite></a>. This format is a Lempel-Ziv coding (LZ77) with a 32 bit CRC. 1393 </li> 1394 </ul> 1385 1395 <p id="rfc.section.3.5.p.6">compress<span id="rfc.iref.c.8"></span><span id="rfc.iref.c.9"></span> 1386 1396 </p> 1387 < dl class="empty">1388 < dd>The encoding format produced by the common UNIX file compression program "compress". This format is an adaptive Lempel-Ziv-Welch1397 <ul class="empty"> 1398 <li>The encoding format produced by the common UNIX file compression program "compress". This format is an adaptive Lempel-Ziv-Welch 1389 1399 coding (LZW). 1390 </ dd>1391 < dd>Use of program names for the identification of encoding formats is not desirable and is discouraged for future encodings.1400 </li> 1401 <li>Use of program names for the identification of encoding formats is not desirable and is discouraged for future encodings. 1392 1402 Their use here is representative of historical practice, not good design. For compatibility with previous implementations 1393 1403 of HTTP, applications <em class="bcp14">SHOULD</em> consider "x-gzip" and "x-compress" to be equivalent to "gzip" and "compress" respectively. 1394 </ dd>1395 </ dl>1404 </li> 1405 </ul> 1396 1406 <p id="rfc.section.3.5.p.7">deflate<span id="rfc.iref.d.2"></span><span id="rfc.iref.c.10"></span> 1397 1407 </p> 1398 < dl class="empty">1399 < dd>The "zlib" format defined in RFC 1950 <a href="#RFC1950" id="rfc.xref.RFC1950.1"><cite title="ZLIB Compressed Data Format Specification version 3.3">[31]</cite></a> in combination with the "deflate" compression mechanism described in RFC 1951 <a href="#RFC1951" id="rfc.xref.RFC1951.1"><cite title="DEFLATE Compressed Data Format Specification version 1.3">[29]</cite></a>.1400 </ dd>1401 </ dl>1408 <ul class="empty"> 1409 <li>The "zlib" format defined in RFC 1950 <a href="#RFC1950" id="rfc.xref.RFC1950.1"><cite title="ZLIB Compressed Data Format Specification version 3.3">[31]</cite></a> in combination with the "deflate" compression mechanism described in RFC 1951 <a href="#RFC1951" id="rfc.xref.RFC1951.1"><cite title="DEFLATE Compressed Data Format Specification version 1.3">[29]</cite></a>. 1410 </li> 1411 </ul> 1402 1412 <p id="rfc.section.3.5.p.8">identity<span id="rfc.iref.i.2"></span><span id="rfc.iref.c.11"></span> 1403 1413 </p> 1404 < dl class="empty">1405 < dd>The default (identity) encoding; the use of no transformation whatsoever. This content-coding is used only in the Accept-Encoding1414 <ul class="empty"> 1415 <li>The default (identity) encoding; the use of no transformation whatsoever. This content-coding is used only in the Accept-Encoding 1406 1416 header, and <em class="bcp14">SHOULD NOT</em> be used in the Content-Encoding header. 1407 </ dd>1408 </ dl>1417 </li> 1418 </ul> 1409 1419 <p id="rfc.section.3.5.p.9">New content-coding value tokens <em class="bcp14">SHOULD</em> be registered; to allow interoperability between clients and servers, specifications of the content coding algorithms needed 1410 1420 to implement a new value <em class="bcp14">SHOULD</em> be publicly available and adequate for independent implementation, and conform to the purpose of content coding defined in … … 1535 1545 an unrecognized multipart subtype, the application <em class="bcp14">MUST</em> treat it as being equivalent to "multipart/mixed". 1536 1546 </p> 1537 < dl class="empty">1538 < dd> <b>Note:</b> The "multipart/form-data" type has been specifically defined for carrying form data suitable for processing via the POST request1547 <ul class="empty"> 1548 <li> <b>Note:</b> The "multipart/form-data" type has been specifically defined for carrying form data suitable for processing via the POST request 1539 1549 method, as described in RFC 1867 <a href="#RFC1867" id="rfc.xref.RFC1867.1"><cite title="Form-based File Upload in HTML">[15]</cite></a>. 1540 </ dd>1541 </ dl>1550 </li> 1551 </ul> 1542 1552 <h2 id="rfc.section.3.8"><a href="#rfc.section.3.8">3.8</a> <a id="product.tokens" href="#product.tokens">Product Tokens</a></h2> 1543 1553 <p id="rfc.section.3.8.p.1">Product tokens are used to allow communicating applications to identify themselves by software name and version. Most fields … … 1694 1704 can parse multipart/byteranges responses. 1695 1705 </p> 1696 < dl class="empty">1697 < dd>A range header might be forwarded by a 1.0 proxy that does not understand multipart/byteranges; in this case the server <em class="bcp14">MUST</em> delimit the message using methods defined in items 1, 3 or 5 of this section.1698 </ dd>1699 </ dl>1706 <ul class="empty"> 1707 <li>A range header might be forwarded by a 1.0 proxy that does not understand multipart/byteranges; in this case the server <em class="bcp14">MUST</em> delimit the message using methods defined in items 1, 3 or 5 of this section. 1708 </li> 1709 </ul> 1700 1710 </li> 1701 1711 <li> … … 1797 1807 </p> 1798 1808 <p id="rfc.section.5.1.2.p.14"> </p> 1799 < dl class="empty">1800 < dd> <b>Note:</b> The "no rewrite" rule prevents the proxy from changing the meaning of the request when the origin server is improperly using1809 <ul class="empty"> 1810 <li> <b>Note:</b> The "no rewrite" rule prevents the proxy from changing the meaning of the request when the origin server is improperly using 1801 1811 a non-reserved URI character for a reserved purpose. Implementors should be aware that some pre-HTTP/1.1 proxies have been 1802 1812 known to rewrite the Request-URI. 1803 </ dd>1804 </ dl>1813 </li> 1814 </ul> 1805 1815 <h2 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2</a> <a id="the.resource.identified.by.a.request" href="#the.resource.identified.by.a.request">The Resource Identified by a Request</a></h2> 1806 1816 <p id="rfc.section.5.2.p.1">The exact resource identified by an Internet request is determined by examining both the Request-URI and the Host header field.</p> … … 2488 2498 GET or HEAD. A client <em class="bcp14">SHOULD</em> detect infinite redirection loops, since such loops generate network traffic for each redirection. 2489 2499 </p> 2490 < dl class="empty">2491 < dd> <b>Note:</b> previous versions of this specification recommended a maximum of five redirections. Content developers should be aware that2500 <ul class="empty"> 2501 <li> <b>Note:</b> previous versions of this specification recommended a maximum of five redirections. Content developers should be aware that 2492 2502 there might be clients that implement such a fixed limitation. 2493 </ dd>2494 </ dl>2503 </li> 2504 </ul> 2495 2505 <div id="rfc.iref.158"></div> 2496 2506 <div id="rfc.iref.s.13"></div> … … 2517 2527 the request was issued. 2518 2528 </p> 2519 < dl class="empty">2520 < dd> <b>Note:</b> When automatically redirecting a POST request after receiving a 301 status code, some existing HTTP/1.0 user agents will erroneously2529 <ul class="empty"> 2530 <li> <b>Note:</b> When automatically redirecting a POST request after receiving a 301 status code, some existing HTTP/1.0 user agents will erroneously 2521 2531 change it into a GET request. 2522 </ dd>2523 </ dl>2532 </li> 2533 </ul> 2524 2534 <div id="rfc.iref.160"></div> 2525 2535 <div id="rfc.iref.s.15"></div> … … 2534 2544 the request was issued. 2535 2545 </p> 2536 < dl class="empty">2537 < dd> <b>Note:</b> RFC 1945 and RFC 2068 specify that the client is not allowed to change the method on the redirected request. However, most2546 <ul class="empty"> 2547 <li> <b>Note:</b> RFC 1945 and RFC 2068 specify that the client is not allowed to change the method on the redirected request. However, most 2538 2548 existing user agent implementations treat 302 as if it were a 303 response, performing a GET on the Location field-value regardless 2539 2549 of the original request method. The status codes 303 and 307 have been added for servers that wish to make unambiguously clear 2540 2550 which kind of reaction is expected of the client. 2541 </ dd>2542 </ dl>2551 </li> 2552 </ul> 2543 2553 <div id="rfc.iref.161"></div> 2544 2554 <div id="rfc.iref.s.16"></div> … … 2550 2560 <p id="rfc.section.10.3.4.p.2">The different URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. Unless the request method was HEAD, the entity of the response <em class="bcp14">SHOULD</em> contain a short hypertext note with a hyperlink to the new URI(s). 2551 2561 </p> 2552 < dl class="empty">2553 < dd> <b>Note:</b> Many pre-HTTP/1.1 user agents do not understand the 303 status. When interoperability with such clients is a concern, the2562 <ul class="empty"> 2563 <li> <b>Note:</b> Many pre-HTTP/1.1 user agents do not understand the 303 status. When interoperability with such clients is a concern, the 2554 2564 302 status code may be used instead, since most user agents react to a 302 response as described here for 303. 2555 </ dd>2556 </ dl>2565 </li> 2566 </ul> 2557 2567 <div id="rfc.iref.162"></div> 2558 2568 <div id="rfc.iref.s.17"></div> … … 2586 2596 expected to repeat this single request via the proxy. 305 responses <em class="bcp14">MUST</em> only be generated by origin servers. 2587 2597 </p> 2588 < dl class="empty">2589 < dd> <b>Note:</b> RFC 2068 was not clear that 305 was intended to redirect a single request, and to be generated by origin servers only. Not2598 <ul class="empty"> 2599 <li> <b>Note:</b> RFC 2068 was not clear that 305 was intended to redirect a single request, and to be generated by origin servers only. Not 2590 2600 observing these limitations has significant security consequences. 2591 </ dd>2592 </ dl>2601 </li> 2602 </ul> 2593 2603 <div id="rfc.iref.164"></div> 2594 2604 <div id="rfc.iref.s.19"></div> … … 2664 2674 Depending upon the format and the capabilities of the user agent, selection of the most appropriate choice <em class="bcp14">MAY</em> be performed automatically. However, this specification does not define any standard for such automatic selection. 2665 2675 </p> 2666 < dl class="empty">2667 < dd> <b>Note:</b> HTTP/1.1 servers are allowed to return responses which are not acceptable according to the accept headers sent in the request.2676 <ul class="empty"> 2677 <li> <b>Note:</b> HTTP/1.1 servers are allowed to return responses which are not acceptable according to the accept headers sent in the request. 2668 2678 In some cases, this may even be preferable to sending a 406 response. User agents are encouraged to inspect the headers of 2669 2679 an incoming response to determine if it is acceptable. 2670 </ dd>2671 </ dl>2680 </li> 2681 </ul> 2672 2682 <p id="rfc.section.10.4.7.p.3">If the response could be unacceptable, a user agent <em class="bcp14">SHOULD</em> temporarily stop receipt of more data and query the user for a decision on further actions. 2673 2683 </p> … … 2786 2796 is that this is a temporary condition which will be alleviated after some delay. If known, the length of the delay <em class="bcp14">MAY</em> be indicated in a Retry-After header. If no Retry-After is given, the client <em class="bcp14">SHOULD</em> handle the response as it would for a 500 response. 2787 2797 </p> 2788 < dl class="empty">2789 < dd> <b>Note:</b> The existence of the 503 status code does not imply that a server must use it when becoming overloaded. Some servers may wish2798 <ul class="empty"> 2799 <li> <b>Note:</b> The existence of the 503 status code does not imply that a server must use it when becoming overloaded. Some servers may wish 2790 2800 to simply refuse the connection. 2791 </ dd>2792 </ dl>2801 </li> 2802 </ul> 2793 2803 <div id="rfc.iref.188"></div> 2794 2804 <div id="rfc.iref.s.43"></div> … … 2797 2807 URI (e.g. HTTP, FTP, LDAP) or some other auxiliary server (e.g. DNS) it needed to access in attempting to complete the request. 2798 2808 </p> 2799 < dl class="empty">2800 < dd> <b>Note:</b> Note to implementors: some deployed proxies are known to return 400 or 500 when DNS lookups time out.2801 </ dd>2802 </ dl>2809 <ul class="empty"> 2810 <li> <b>Note:</b> Note to implementors: some deployed proxies are known to return 400 or 500 when DNS lookups time out. 2811 </li> 2812 </ul> 2803 2813 <div id="rfc.iref.189"></div> 2804 2814 <div id="rfc.iref.s.44"></div> … … 2822 2832 best representation for a given response when there are multiple representations available. 2823 2833 </p> 2824 < dl class="empty">2825 < dd> <b>Note:</b> This is not called "format negotiation" because the alternate representations may be of the same media type, but use different2834 <ul class="empty"> 2835 <li> <b>Note:</b> This is not called "format negotiation" because the alternate representations may be of the same media type, but use different 2826 2836 capabilities of that type, be in different languages, etc. 2827 </ dd>2828 </ dl>2837 </li> 2838 </ul> 2829 2839 <p id="rfc.section.12.p.2">Any response containing an entity-body <em class="bcp14">MAY</em> be subject to negotiation, including error responses. 2830 2840 </p> … … 2926 2936 </ol> 2927 2937 <p id="rfc.section.13.p.5">A basic principle is that it must be possible for the clients to detect any potential relaxation of semantic transparency. </p> 2928 < dl class="empty">2929 < dd> <b>Note:</b> The server, cache, or client implementor might be faced with design decisions not explicitly discussed in this specification.2938 <ul class="empty"> 2939 <li> <b>Note:</b> The server, cache, or client implementor might be faced with design decisions not explicitly discussed in this specification. 2930 2940 If a decision might affect semantic transparency, the implementor ought to err on the side of maintaining transparency unless 2931 2941 a careful and complete analysis shows significant benefits in breaking transparency. 2932 </ dd>2933 </ dl>2942 </li> 2943 </ul> 2934 2944 <h2 id="rfc.section.13.1"><a href="#rfc.section.13.1">13.1</a> 2935 2945 </h2> … … 3205 3215 either that a method be performed if and only if a validator matches or if and only if no validators match. 3206 3216 </p> 3207 < dl class="empty">3208 < dd> <b>Note:</b> a response that lacks a validator may still be cached, and served from cache until it expires, unless this is explicitly prohibited3217 <ul class="empty"> 3218 <li> <b>Note:</b> a response that lacks a validator may still be cached, and served from cache until it expires, unless this is explicitly prohibited 3209 3219 by a cache-control directive. However, a cache cannot do a conditional retrieval if it does not have a validator for the entity, 3210 3220 which means it will not be refreshable after it expires. 3211 </ dd>3212 </ dl>3221 </li> 3222 </ul> 3213 3223 <h3 id="rfc.section.13.3.1"><a href="#rfc.section.13.3.1">13.3.1</a> <a id="last-modified.dates" href="#last-modified.dates">Last-Modified Dates</a></h3> 3214 3224 <p id="rfc.section.13.3.1.p.1">The Last-Modified entity-header field value is often used as a cache validator. In simple terms, a cache entry is considered … … 3237 3247 entity, while a weak validator is part of an identifier for a set of semantically equivalent entities. 3238 3248 </p> 3239 < dl class="empty">3240 < dd> <b>Note:</b> One example of a strong validator is an integer that is incremented in stable storage every time an entity is changed.3241 </ dd>3242 < dd>An entity's modification time, if represented with one-second resolution, could be a weak validator, since it is possible3249 <ul class="empty"> 3250 <li> <b>Note:</b> One example of a strong validator is an integer that is incremented in stable storage every time an entity is changed. 3251 </li> 3252 <li>An entity's modification time, if represented with one-second resolution, could be a weak validator, since it is possible 3243 3253 that the resource might be modified twice during a single second. 3244 </ dd>3245 < dd>Support for weak validators is optional. However, weak validators allow for more efficient caching of equivalent objects;3254 </li> 3255 <li>Support for weak validators is optional. However, weak validators allow for more efficient caching of equivalent objects; 3246 3256 for example, a hit counter on a site is probably good enough if it is updated every few days or weeks, and any value during 3247 3257 that period is likely "good enough" to be equivalent. 3248 </ dd>3249 </ dl>3258 </li> 3259 </ul> 3250 3260 <p id="rfc.section.13.3.3.p.4">A "use" of a validator is either when a client generates a request and includes the validator in a validating header field, 3251 3261 or when a server compares two validators. … … 3324 3334 <p id="rfc.section.13.3.4.p.4">In order to be legal, a strong entity tag <em class="bcp14">MUST</em> change whenever the associated entity value changes in any way. A weak entity tag <em class="bcp14">SHOULD</em> change whenever the associated entity changes in a semantically significant way. 3325 3335 </p> 3326 < dl class="empty">3327 < dd> <b>Note:</b> in order to provide semantically transparent caching, an origin server must avoid reusing a specific strong entity tag value3336 <ul class="empty"> 3337 <li> <b>Note:</b> in order to provide semantically transparent caching, an origin server must avoid reusing a specific strong entity tag value 3328 3338 for two different entities, or reusing a specific weak entity tag value for two semantically different entities. Cache entries 3329 3339 might persist for arbitrarily long periods, regardless of expiration times, so it might be inappropriate to expect that a 3330 3340 cache will never again attempt to validate an entry using a validator that it obtained at some point in the past. 3331 </ dd>3332 </ dl>3341 </li> 3342 </ul> 3333 3343 <p id="rfc.section.13.3.4.p.5">HTTP/1.1 clients: </p> 3334 3344 <ul> … … 3350 3360 fields in the request. 3351 3361 </p> 3352 < dl class="empty">3353 < dd> <b>Note:</b> The general principle behind these rules is that HTTP/1.1 servers and clients should transmit as much non-redundant information3362 <ul class="empty"> 3363 <li> <b>Note:</b> The general principle behind these rules is that HTTP/1.1 servers and clients should transmit as much non-redundant information 3354 3364 as is available in their responses and requests. HTTP/1.1 systems receiving this information will make the most conservative 3355 3365 assumptions about the validators they receive. 3356 </ dd>3357 < dd>HTTP/1.0 clients and caches will ignore entity tags. Generally, last-modified values received or used by these systems will3366 </li> 3367 <li>HTTP/1.0 clients and caches will ignore entity tags. Generally, last-modified values received or used by these systems will 3358 3368 support transparent and efficient caching, and so HTTP/1.1 origin servers should provide Last-Modified values. In those rare 3359 3369 cases where the use of a Last-Modified value as a validator by an HTTP/1.0 system could result in a serious problem, then 3360 3370 HTTP/1.1 origin servers should not provide one. 3361 </ dd>3362 </ dl>3371 </li> 3372 </ul> 3363 3373 <h3 id="rfc.section.13.3.5"><a href="#rfc.section.13.3.5">13.3.5</a> <a id="non-validating.conditionals" href="#non-validating.conditionals">Non-validating Conditionals</a></h3> 3364 3374 <p id="rfc.section.13.3.5.p.1">The principle behind entity tags is that only the service author knows the semantics of a resource well enough to select an … … 3372 3382 such a response was taken from a cache by comparing the Date header to the current time. 3373 3383 </p> 3374 < dl class="empty">3375 < dd> <b>Note:</b> some HTTP/1.0 caches are known to violate this expectation without providing any Warning.3376 </ dd>3377 </ dl>3384 <ul class="empty"> 3385 <li> <b>Note:</b> some HTTP/1.0 caches are known to violate this expectation without providing any Warning. 3386 </li> 3387 </ul> 3378 3388 <p id="rfc.section.13.4.p.2">However, in some cases it might be inappropriate for a cache to retain an entity, or to return it in response to a subsequent 3379 3389 request. This might be because absolute semantic transparency is deemed necessary by the service author, or because of security … … 3447 3457 <p id="rfc.section.13.5.2.p.6">A non-transparent proxy <em class="bcp14">MAY</em> modify or add these fields to a message that does not include no-transform, but if it does so, it <em class="bcp14">MUST</em> add a Warning 214 (Transformation applied) if one does not already appear in the message (see <a href="#header.warning" id="rfc.xref.header.warning.5" title="Warning">Section 14.46</a>). 3448 3458 </p> 3449 < dl class="empty">3450 < dd> <b>Warning:</b> unnecessary modification of end-to-end headers might cause authentication failures if stronger authentication mechanisms are3459 <ul class="empty"> 3460 <li> <b>Warning:</b> unnecessary modification of end-to-end headers might cause authentication failures if stronger authentication mechanisms are 3451 3461 introduced in later versions of HTTP. Such authentication mechanisms <em class="bcp14">MAY</em> rely on the values of header fields not listed here. 3452 </ dd>3453 </ dl>3462 </li> 3463 </ul> 3454 3464 <p id="rfc.section.13.5.2.p.7">The Content-Length field of a request or response is added or deleted according to the rules in <a href="#message.length" title="Message Length">Section 4.4</a>. A transparent proxy <em class="bcp14">MUST</em> preserve the entity-length (<a href="#entity.length" title="Entity Length">Section 7.2.2</a>) of the entity-body, although it <em class="bcp14">MAY</em> change the transfer-length (<a href="#message.length" title="Message Length">Section 4.4</a>). 3455 3465 </p> … … 3477 3487 stored with the cache entry (except for stored Warning headers with warn-code 1xx, which are deleted even if not overridden). 3478 3488 </p> 3479 < dl class="empty">3480 < dd> <b>Note:</b> this rule allows an origin server to use a <a href="#status.304" class="smpl">304 (Not Modified)</a> or a <a href="#status.206" class="smpl">206 (Partial Content)</a> response to update any header associated with a previous response for the same entity or sub-ranges thereof, although it might3489 <ul class="empty"> 3490 <li> <b>Note:</b> this rule allows an origin server to use a <a href="#status.304" class="smpl">304 (Not Modified)</a> or a <a href="#status.206" class="smpl">206 (Partial Content)</a> response to update any header associated with a previous response for the same entity or sub-ranges thereof, although it might 3481 3491 not always be meaningful or correct to do so. This rule does not allow an origin server to use a <a href="#status.304" class="smpl">304 (Not Modified)</a> or a <a href="#status.206" class="smpl">206 (Partial Content)</a> response to entirely delete a header that it had provided with a previous response. 3482 </ dd>3483 </ dl>3492 </li> 3493 </ul> 3484 3494 <h3 id="rfc.section.13.5.4"><a href="#rfc.section.13.5.4">13.5.4</a> <a id="combining.byte.ranges" href="#combining.byte.ranges">Combining Byte Ranges</a></h3> 3485 3495 <p id="rfc.section.13.5.4.p.1">A response might transfer only a subrange of the bytes of an entity-body, either because the request included one or more … … 3588 3598 to be returned. If it inserts the new response into cache storage the rules in <a href="#combining.headers" title="Combining Headers">Section 13.5.3</a> apply. 3589 3599 </p> 3590 < dl class="empty">3591 < dd> <b>Note:</b> a new response that has an older Date header value than existing cached responses is not cacheable.3592 </ dd>3593 </ dl>3600 <ul class="empty"> 3601 <li> <b>Note:</b> a new response that has an older Date header value than existing cached responses is not cacheable. 3602 </li> 3603 </ul> 3594 3604 <h2 id="rfc.section.13.13"><a href="#rfc.section.13.13">13.13</a> <a id="history.lists" href="#history.lists">History Lists</a></h2> 3595 3605 <p id="rfc.section.13.13.p.1">User agents often have history mechanisms, such as "Back" buttons and history lists, which can be used to redisplay an entity … … 3603 3613 </p> 3604 3614 <p id="rfc.section.13.13.p.4">This is not to be construed to prohibit the history mechanism from telling the user that a view might be stale. </p> 3605 < dl class="empty">3606 < dd> <b>Note:</b> if history list mechanisms unnecessarily prevent users from viewing stale resources, this will tend to force service authors3615 <ul class="empty"> 3616 <li> <b>Note:</b> if history list mechanisms unnecessarily prevent users from viewing stale resources, this will tend to force service authors 3607 3617 to avoid using HTTP expiration controls and cache controls when they would otherwise like to. Service authors may consider 3608 3618 it important that users not be presented with error messages or warning messages when they use navigation controls (such as … … 3610 3620 user interface considerations may force service authors to resort to other means of preventing caching (e.g. "once-only" URLs) 3611 3621 in order not to suffer the effects of improperly functioning history mechanisms. 3612 </ dd>3613 </ dl>3622 </li> 3623 </ul> 3614 3624 <hr class="noprint"> 3615 3625 <h1 id="rfc.section.14" class="np"><a href="#rfc.section.14">14.</a> <a id="header.fields" href="#header.fields">Header Field Definitions</a></h1> … … 3640 3650 agent to indicate the relative degree of preference for that media-range, using the qvalue scale from 0 to 1 (<a href="#quality.values" title="Quality Values">Section 3.9</a>). The default value is q=1. 3641 3651 </p> 3642 < dl class="empty">3643 < dd> <b>Note:</b> Use of the "q" parameter name to separate media type parameters from Accept extension parameters is due to historical practice.3652 <ul class="empty"> 3653 <li> <b>Note:</b> Use of the "q" parameter name to separate media type parameters from Accept extension parameters is due to historical practice. 3644 3654 Although this prevents any media type parameter named "q" from being used with a media range, such an event is believed to 3645 3655 be unlikely given the lack of any "q" parameters in the IANA media type registry and the rare usage of any media type parameters 3646 3656 in Accept. Future media types are discouraged from registering any parameter named "q". 3647 </ dd>3648 </ dl>3657 </li> 3658 </ul> 3649 3659 <p id="rfc.section.14.1.p.5">The example</p> 3650 3660 <div id="rfc.figure.u.63"></div><pre class="text"> Accept: audio/*; q=0.2, audio/basic … … 3742 3752 client. 3743 3753 </p> 3744 < dl class="empty">3745 < dd> <b>Note:</b> If the request does not include an Accept-Encoding field, and if the "identity" content-coding is unavailable, then content-codings3754 <ul class="empty"> 3755 <li> <b>Note:</b> If the request does not include an Accept-Encoding field, and if the "identity" content-coding is unavailable, then content-codings 3746 3756 commonly understood by HTTP/1.0 clients (i.e., "gzip" and "compress") are preferred; some older clients improperly display 3747 3757 messages sent with other content-codings. The server might also make this decision based on information about the particular 3748 3758 user-agent or client. 3749 </ dd>3750 < dd> <b>Note:</b> Most HTTP/1.0 applications do not recognize or obey qvalues associated with content-codings. This means that qvalues will3759 </li> 3760 <li> <b>Note:</b> Most HTTP/1.0 applications do not recognize or obey qvalues associated with content-codings. This means that qvalues will 3751 3761 not work and are not permitted with x-gzip or x-compress. 3752 </ dd>3753 </ dl>3762 </li> 3763 </ul> 3754 3764 <div id="rfc.iref.a.5"></div> 3755 3765 <div id="rfc.iref.h.7"></div> … … 3770 3780 range present in the Accept-Language field. 3771 3781 </p> 3772 < dl class="empty">3773 < dd> <b>Note:</b> This use of a prefix matching rule does not imply that language tags are assigned to languages in such a way that it is always3782 <ul class="empty"> 3783 <li> <b>Note:</b> This use of a prefix matching rule does not imply that language tags are assigned to languages in such a way that it is always 3774 3784 true that if a user understands a language with a certain tag, then this user will also understand all languages with tags 3775 3785 for which this tag is a prefix. The prefix rule simply allows the use of prefix tags if this is the case. 3776 </ dd>3777 </ dl>3786 </li> 3787 </ul> 3778 3788 <p id="rfc.section.14.4.p.6">The language quality factor assigned to a language-tag by the Accept-Language field is the quality value of the longest language-range 3779 3789 in the field that matches the language-tag. If no language-range in the field matches the tag, the language quality factor … … 3787 3797 of linguistic preference available to the user. If the choice is not made available, then the Accept-Language header field <em class="bcp14">MUST NOT</em> be given in the request. 3788 3798 </p> 3789 < dl class="empty">3790 < dd> <b>Note:</b> When making the choice of linguistic preference available to the user, we remind implementors of the fact that users are not3799 <ul class="empty"> 3800 <li> <b>Note:</b> When making the choice of linguistic preference available to the user, we remind implementors of the fact that users are not 3791 3801 familiar with the details of language matching as described above, and should provide appropriate guidance. As an example, 3792 3802 users might assume that on selecting "en-gb", they will be served any kind of English document if British English is not available. 3793 3803 A user agent might suggest in such a case to add "en" to get the best matching behavior. 3794 </ dd>3795 </ dl>3804 </li> 3805 </ul> 3796 3806 <div id="rfc.iref.a.6"></div> 3797 3807 <div id="rfc.iref.h.8"></div> … … 3871 3881 is to be given in the response. 3872 3882 </p> 3873 < dl class="empty">3874 < dd>Note that HTTP/1.0 caches might not implement Cache-Control and might only implement Pragma: no-cache (see <a href="#header.pragma" id="rfc.xref.header.pragma.2" title="Pragma">Section 14.32</a>).3875 </ dd>3876 </ dl>3883 <ul class="empty"> 3884 <li>Note that HTTP/1.0 caches might not implement Cache-Control and might only implement Pragma: no-cache (see <a href="#header.pragma" id="rfc.xref.header.pragma.2" title="Pragma">Section 14.32</a>). 3885 </li> 3886 </ul> 3877 3887 <p id="rfc.section.14.9.p.2">Cache directives <em class="bcp14">MUST</em> be passed through by a proxy or gateway application, regardless of their significance to that application, since the directives 3878 3888 might be applicable to all recipients along the request/response chain. It is not possible to specify a cache-directive for … … 3928 3938 <p id="rfc.section.14.9.1.p.2"> <span id="rfc.iref.c.14"></span> <span id="rfc.iref.p.4"></span> public 3929 3939 </p> 3930 < dl class="empty">3931 < dd>Indicates that the response <em class="bcp14">MAY</em> be cached by any cache, even if it would normally be non-cacheable or cacheable only within a non-shared cache. (See also3940 <ul class="empty"> 3941 <li>Indicates that the response <em class="bcp14">MAY</em> be cached by any cache, even if it would normally be non-cacheable or cacheable only within a non-shared cache. (See also 3932 3942 Authorization, <a href="#header.authorization" id="rfc.xref.header.authorization.4" title="Authorization">Section 14.8</a>, for additional details.) 3933 </ dd>3934 </ dl>3943 </li> 3944 </ul> 3935 3945 <p id="rfc.section.14.9.1.p.3"> <span id="rfc.iref.c.15"></span> <span id="rfc.iref.p.5"></span> private 3936 3946 </p> 3937 < dl class="empty">3938 < dd>Indicates that all or part of the response message is intended for a single user and <em class="bcp14">MUST NOT</em> be cached by a shared cache. This allows an origin server to state that the specified parts of the response are intended for3947 <ul class="empty"> 3948 <li>Indicates that all or part of the response message is intended for a single user and <em class="bcp14">MUST NOT</em> be cached by a shared cache. This allows an origin server to state that the specified parts of the response are intended for 3939 3949 only one user and are not a valid response for requests by other users. A private (non-shared) cache <em class="bcp14">MAY</em> cache the response. 3940 </ dd>3941 < dd> <b>Note:</b> This usage of the word private only controls where the response may be cached, and cannot ensure the privacy of the message3950 </li> 3951 <li> <b>Note:</b> This usage of the word private only controls where the response may be cached, and cannot ensure the privacy of the message 3942 3952 content. 3943 </ dd>3944 </ dl>3953 </li> 3954 </ul> 3945 3955 <p id="rfc.section.14.9.1.p.4"> <span id="rfc.iref.c.16"></span> <span id="rfc.iref.n.1"></span> no-cache 3946 3956 </p> 3947 < dl class="empty">3948 < dd>If the no-cache directive does not specify a field-name, then a cache <em class="bcp14">MUST NOT</em> use the response to satisfy a subsequent request without successful revalidation with the origin server. This allows an origin3957 <ul class="empty"> 3958 <li>If the no-cache directive does not specify a field-name, then a cache <em class="bcp14">MUST NOT</em> use the response to satisfy a subsequent request without successful revalidation with the origin server. This allows an origin 3949 3959 server to prevent caching even by caches that have been configured to return stale responses to client requests. 3950 </ dd>3951 < dd>If the no-cache directive does specify one or more field-names, then a cache <em class="bcp14">MAY</em> use the response to satisfy a subsequent request, subject to any other restrictions on caching. However, the specified field-name(s) <em class="bcp14">MUST NOT</em> be sent in the response to a subsequent request without successful revalidation with the origin server. This allows an origin3960 </li> 3961 <li>If the no-cache directive does specify one or more field-names, then a cache <em class="bcp14">MAY</em> use the response to satisfy a subsequent request, subject to any other restrictions on caching. However, the specified field-name(s) <em class="bcp14">MUST NOT</em> be sent in the response to a subsequent request without successful revalidation with the origin server. This allows an origin 3952 3962 server to prevent the re-use of certain header fields in a response, while still allowing caching of the rest of the response. 3953 < dl class="empty">3954 < dd> <b>Note:</b> Most HTTP/1.0 caches will not recognize or obey this directive.3955 </ dd>3956 </ dl>3957 </ dd>3958 </ dl>3963 <ul class="empty"> 3964 <li> <b>Note:</b> Most HTTP/1.0 caches will not recognize or obey this directive. 3965 </li> 3966 </ul> 3967 </li> 3968 </ul> 3959 3969 <h3 id="rfc.section.14.9.2"><a href="#rfc.section.14.9.2">14.9.2</a> <a id="what.may.be.stored.by.caches" href="#what.may.be.stored.by.caches">What May be Stored by Caches</a></h3> 3960 3970 <p id="rfc.section.14.9.2.p.1"> <span id="rfc.iref.c.17"></span> <span id="rfc.iref.n.2"></span> no-store 3961 3971 </p> 3962 < dl class="empty">3963 < dd>The purpose of the no-store directive is to prevent the inadvertent release or retention of sensitive information (for example,3972 <ul class="empty"> 3973 <li>The purpose of the no-store directive is to prevent the inadvertent release or retention of sensitive information (for example, 3964 3974 on backup tapes). The no-store directive applies to the entire message, and <em class="bcp14">MAY</em> be sent either in a response or in a request. If sent in a request, a cache <em class="bcp14">MUST NOT</em> store any part of either this request or any response to it. If sent in a response, a cache <em class="bcp14">MUST NOT</em> store any part of either this response or the request that elicited it. This directive applies to both non-shared and shared 3965 3975 caches. "<em class="bcp14">MUST NOT</em> store" in this context means that the cache <em class="bcp14">MUST NOT</em> intentionally store the information in non-volatile storage, and <em class="bcp14">MUST</em> make a best-effort attempt to remove the information from volatile storage as promptly as possible after forwarding it. 3966 </ dd>3967 < dd>Even when this directive is associated with a response, users might explicitly store such a response outside of the caching3976 </li> 3977 <li>Even when this directive is associated with a response, users might explicitly store such a response outside of the caching 3968 3978 system (e.g., with a "Save As" dialog). History buffers <em class="bcp14">MAY</em> store such responses as part of their normal operation. 3969 </ dd>3970 < dd>The purpose of this directive is to meet the stated requirements of certain users and service authors who are concerned about3979 </li> 3980 <li>The purpose of this directive is to meet the stated requirements of certain users and service authors who are concerned about 3971 3981 accidental releases of information via unanticipated accesses to cache data structures. While the use of this directive might 3972 3982 improve privacy in some cases, we caution that it is NOT in any way a reliable or sufficient mechanism for ensuring privacy. 3973 3983 In particular, malicious or compromised caches might not recognize or obey this directive, and communications networks might 3974 3984 be vulnerable to eavesdropping. 3975 </ dd>3976 </ dl>3985 </li> 3986 </ul> 3977 3987 <h3 id="rfc.section.14.9.3"><a href="#rfc.section.14.9.3">14.9.3</a> <a id="modifications.of.the.basic.expiration.mechanism" href="#modifications.of.the.basic.expiration.mechanism">Modifications of the Basic Expiration Mechanism</a></h3> 3978 3988 <p id="rfc.section.14.9.3.p.1">The expiration time of an entity <em class="bcp14">MAY</em> be specified by the origin server using the Expires header (see <a href="#header.expires" id="rfc.xref.header.expires.3" title="Expires">Section 14.21</a>). Alternatively, it <em class="bcp14">MAY</em> be specified using the max-age directive in a response. When the max-age cache-control directive is present in a cached response, … … 3990 4000 does not include a Cache-Control header field, it <em class="bcp14">SHOULD</em> consider the response to be non-cacheable in order to retain compatibility with HTTP/1.0 servers. 3991 4001 </p> 3992 < dl class="empty">3993 < dd> <b>Note:</b> An origin server might wish to use a relatively new HTTP cache control feature, such as the "private" directive, on a network4002 <ul class="empty"> 4003 <li> <b>Note:</b> An origin server might wish to use a relatively new HTTP cache control feature, such as the "private" directive, on a network 3994 4004 including older caches that do not understand that feature. The origin server will need to combine the new feature with an 3995 4005 Expires field whose value is less than or equal to the Date value. This will prevent older caches from improperly caching 3996 4006 the response. 3997 </ dd>3998 </ dl>4007 </li> 4008 </ul> 3999 4009 <p id="rfc.section.14.9.3.p.4"> <span id="rfc.iref.c.18"></span> <span id="rfc.iref.s.45"></span> s-maxage 4000 4010 </p> 4001 < dl class="empty">4002 < dd>If a response includes an s-maxage directive, then for a shared cache (but not for a private cache), the maximum age specified4011 <ul class="empty"> 4012 <li>If a response includes an s-maxage directive, then for a shared cache (but not for a private cache), the maximum age specified 4003 4013 by this directive overrides the maximum age specified by either the max-age directive or the Expires header. The s-maxage 4004 4014 directive also implies the semantics of the proxy-revalidate directive (see <a href="#cache.revalidation.and.reload.controls" title="Cache Revalidation and Reload Controls">Section 14.9.4</a>), i.e., that the shared cache must not use the entry after it becomes stale to respond to a subsequent request without first 4005 4015 revalidating it with the origin server. The s-maxage directive is always ignored by a private cache. 4006 </ dd>4007 </ dl>4016 </li> 4017 </ul> 4008 4018 <p id="rfc.section.14.9.3.p.5">Note that most older caches, not compliant with this specification, do not implement any cache-control directives. An origin 4009 4019 server wishing to use a cache-control directive that restricts, but does not prevent, caching by an HTTP/1.1-compliant cache <em class="bcp14">MAY</em> exploit the requirement that the max-age directive overrides the Expires header, and the fact that pre-HTTP/1.1-compliant … … 4014 4024 <p id="rfc.section.14.9.3.p.7"> <span id="rfc.iref.c.19"></span> <span id="rfc.iref.m.10"></span> max-age 4015 4025 </p> 4016 < dl class="empty">4017 < dd>Indicates that the client is willing to accept a response whose age is no greater than the specified time in seconds. Unless4026 <ul class="empty"> 4027 <li>Indicates that the client is willing to accept a response whose age is no greater than the specified time in seconds. Unless 4018 4028 max-stale directive is also included, the client is not willing to accept a stale response. 4019 </ dd>4020 </ dl>4029 </li> 4030 </ul> 4021 4031 <p id="rfc.section.14.9.3.p.8"> <span id="rfc.iref.c.20"></span> <span id="rfc.iref.m.11"></span> min-fresh 4022 4032 </p> 4023 < dl class="empty">4024 < dd>Indicates that the client is willing to accept a response whose freshness lifetime is no less than its current age plus the4033 <ul class="empty"> 4034 <li>Indicates that the client is willing to accept a response whose freshness lifetime is no less than its current age plus the 4025 4035 specified time in seconds. That is, the client wants a response that will still be fresh for at least the specified number 4026 4036 of seconds. 4027 </ dd>4028 </ dl>4037 </li> 4038 </ul> 4029 4039 <p id="rfc.section.14.9.3.p.9"> <span id="rfc.iref.c.21"></span> <span id="rfc.iref.m.12"></span> max-stale 4030 4040 </p> 4031 < dl class="empty">4032 < dd>Indicates that the client is willing to accept a response that has exceeded its expiration time. If max-stale is assigned4041 <ul class="empty"> 4042 <li>Indicates that the client is willing to accept a response that has exceeded its expiration time. If max-stale is assigned 4033 4043 a value, then the client is willing to accept a response that has exceeded its expiration time by no more than the specified 4034 4044 number of seconds. If no value is assigned to max-stale, then the client is willing to accept a stale response of any age. 4035 </ dd>4036 </ dl>4045 </li> 4046 </ul> 4037 4047 <p id="rfc.section.14.9.3.p.10">If a cache returns a stale response, either because of a max-stale directive on a request, or because the cache is configured 4038 4048 to override the expiration time of a response, the cache <em class="bcp14">MUST</em> attach a Warning header to the stale response, using Warning 110 (Response is stale). … … 4056 4066 <p id="rfc.section.14.9.4.p.3">The client can specify these three kinds of action using Cache-Control request directives:</p> 4057 4067 <p id="rfc.section.14.9.4.p.4">End-to-end reload </p> 4058 < dl class="empty">4059 < dd>The request includes a "no-cache" cache-control directive or, for compatibility with HTTP/1.0 clients, "Pragma: no-cache".4068 <ul class="empty"> 4069 <li>The request includes a "no-cache" cache-control directive or, for compatibility with HTTP/1.0 clients, "Pragma: no-cache". 4060 4070 Field names <em class="bcp14">MUST NOT</em> be included with the no-cache directive in a request. The server <em class="bcp14">MUST NOT</em> use a cached copy when responding to such a request. 4061 </ dd>4062 </ dl>4071 </li> 4072 </ul> 4063 4073 <p id="rfc.section.14.9.4.p.5">Specific end-to-end revalidation </p> 4064 < dl class="empty">4065 < dd>The request includes a "max-age=0" cache-control directive, which forces each cache along the path to the origin server to4074 <ul class="empty"> 4075 <li>The request includes a "max-age=0" cache-control directive, which forces each cache along the path to the origin server to 4066 4076 revalidate its own entry, if any, with the next cache or server. The initial request includes a cache-validating conditional 4067 4077 with the client's current validator. 4068 </ dd>4069 </ dl>4078 </li> 4079 </ul> 4070 4080 <p id="rfc.section.14.9.4.p.6">Unspecified end-to-end revalidation </p> 4071 < dl class="empty">4072 < dd>The request includes "max-age=0" cache-control directive, which forces each cache along the path to the origin server to revalidate4081 <ul class="empty"> 4082 <li>The request includes "max-age=0" cache-control directive, which forces each cache along the path to the origin server to revalidate 4073 4083 its own entry, if any, with the next cache or server. The initial request does not include a cache-validating conditional; 4074 4084 the first cache along the path (if any) that holds a cache entry for this resource includes a cache-validating conditional 4075 4085 with its current validator. 4076 </ dd>4077 </ dl>4086 </li> 4087 </ul> 4078 4088 <p id="rfc.section.14.9.4.p.7"> <span id="rfc.iref.c.22"></span> <span id="rfc.iref.m.13"></span> max-age 4079 4089 </p> 4080 < dl class="empty">4081 < dd>When an intermediate cache is forced, by means of a max-age=0 directive, to revalidate its own cache entry, and the client4090 <ul class="empty"> 4091 <li>When an intermediate cache is forced, by means of a max-age=0 directive, to revalidate its own cache entry, and the client 4082 4092 has supplied its own validator in the request, the supplied validator might differ from the validator currently stored with 4083 4093 the cache entry. In this case, the cache <em class="bcp14">MAY</em> use either validator in making its own request without affecting semantic transparency. 4084 </ dd>4085 < dd>However, the choice of validator might affect performance. The best approach is for the intermediate cache to use its own4094 </li> 4095 <li>However, the choice of validator might affect performance. The best approach is for the intermediate cache to use its own 4086 4096 validator when making its request. If the server replies with 304 (Not Modified), then the cache can return its now validated 4087 4097 copy to the client with a <a href="#status.200" class="smpl">200 (OK)</a> response. If the server replies with a new entity and cache validator, however, the intermediate cache can compare the returned 4088 4098 validator with the one provided in the client's request, using the strong comparison function. If the client's validator is 4089 4099 equal to the origin server's, then the intermediate cache simply returns <a href="#status.304" class="smpl">304 (Not Modified)</a>. Otherwise, it returns the new entity with a <a href="#status.200" class="smpl">200 (OK)</a> response. 4090 </ dd>4091 < dd>If a request includes the no-cache directive, it <em class="bcp14">SHOULD NOT</em> include min-fresh, max-stale, or max-age.4092 </ dd>4093 </ dl>4100 </li> 4101 <li>If a request includes the no-cache directive, it <em class="bcp14">SHOULD NOT</em> include min-fresh, max-stale, or max-age. 4102 </li> 4103 </ul> 4094 4104 <p id="rfc.section.14.9.4.p.8"> <span id="rfc.iref.c.23"></span> <span id="rfc.iref.o.4"></span> only-if-cached 4095 4105 </p> 4096 < dl class="empty">4097 < dd>In some cases, such as times of extremely poor network connectivity, a client may want a cache to return only those responses4106 <ul class="empty"> 4107 <li>In some cases, such as times of extremely poor network connectivity, a client may want a cache to return only those responses 4098 4108 that it currently has stored, and not to reload or revalidate with the origin server. To do this, the client may include the 4099 4109 only-if-cached directive in a request. If it receives this directive, a cache <em class="bcp14">SHOULD</em> either respond using a cached entry that is consistent with the other constraints of the request, or respond with a <a href="#status.504" class="smpl">504 (Gateway Timeout)</a> status. However, if a group of caches is being operated as a unified system with good internal connectivity, such a request <em class="bcp14">MAY</em> be forwarded within that group of caches. 4100 </ dd>4101 </ dl>4110 </li> 4111 </ul> 4102 4112 <p id="rfc.section.14.9.4.p.9"> <span id="rfc.iref.c.24"></span> <span id="rfc.iref.m.14"></span> must-revalidate 4103 4113 </p> 4104 < dl class="empty">4105 < dd>Because a cache <em class="bcp14">MAY</em> be configured to ignore a server's specified expiration time, and because a client request <em class="bcp14">MAY</em> include a max-stale directive (which has a similar effect), the protocol also includes a mechanism for the origin server to4114 <ul class="empty"> 4115 <li>Because a cache <em class="bcp14">MAY</em> be configured to ignore a server's specified expiration time, and because a client request <em class="bcp14">MAY</em> include a max-stale directive (which has a similar effect), the protocol also includes a mechanism for the origin server to 4106 4116 require revalidation of a cache entry on any subsequent use. When the must-revalidate directive is present in a response received 4107 4117 by a cache, that cache <em class="bcp14">MUST NOT</em> use the entry after it becomes stale to respond to a subsequent request without first revalidating it with the origin server. 4108 4118 (I.e., the cache <em class="bcp14">MUST</em> do an end-to-end revalidation every time, if, based solely on the origin server's Expires or max-age value, the cached response 4109 4119 is stale.) 4110 </ dd>4111 < dd>The must-revalidate directive is necessary to support reliable operation for certain protocol features. In all circumstances4120 </li> 4121 <li>The must-revalidate directive is necessary to support reliable operation for certain protocol features. In all circumstances 4112 4122 an HTTP/1.1 cache <em class="bcp14">MUST</em> obey the must-revalidate directive; in particular, if the cache cannot reach the origin server for any reason, it <em class="bcp14">MUST</em> generate a <a href="#status.504" class="smpl">504 (Gateway Timeout)</a> response. 4113 </ dd>4114 < dd>Servers <em class="bcp14">SHOULD</em> send the must-revalidate directive if and only if failure to revalidate a request on the entity could result in incorrect4123 </li> 4124 <li>Servers <em class="bcp14">SHOULD</em> send the must-revalidate directive if and only if failure to revalidate a request on the entity could result in incorrect 4115 4125 operation, such as a silently unexecuted financial transaction. Recipients <em class="bcp14">MUST NOT</em> take any automated action that violates this directive, and <em class="bcp14">MUST NOT</em> automatically provide an unvalidated copy of the entity if revalidation fails. 4116 </ dd>4117 < dd>Although this is not recommended, user agents operating under severe connectivity constraints <em class="bcp14">MAY</em> violate this directive but, if so, <em class="bcp14">MUST</em> explicitly warn the user that an unvalidated response has been provided. The warning <em class="bcp14">MUST</em> be provided on each unvalidated access, and <em class="bcp14">SHOULD</em> require explicit user confirmation.4118 </ dd>4119 </ dl>4126 </li> 4127 <li>Although this is not recommended, user agents operating under severe connectivity constraints <em class="bcp14">MAY</em> violate this directive but, if so, <em class="bcp14">MUST</em> explicitly warn the user that an unvalidated response has been provided. The warning <em class="bcp14">MUST</em> be provided on each unvalidated access, and <em class="bcp14">SHOULD</em> require explicit user confirmation. 4128 </li> 4129 </ul> 4120 4130 <p id="rfc.section.14.9.4.p.10"> <span id="rfc.iref.c.25"></span> <span id="rfc.iref.p.6"></span> proxy-revalidate 4121 4131 </p> 4122 < dl class="empty">4123 < dd>The proxy-revalidate directive has the same meaning as the must-revalidate directive, except that it does not apply to non-shared4132 <ul class="empty"> 4133 <li>The proxy-revalidate directive has the same meaning as the must-revalidate directive, except that it does not apply to non-shared 4124 4134 user agent caches. It can be used on a response to an authenticated request to permit the user's cache to store and later 4125 4135 return the response without needing to revalidate it (since it has already been authenticated once by that user), while still … … 4127 4137 Note that such authenticated responses also need the public cache control directive in order to allow them to be cached at 4128 4138 all. 4129 </ dd>4130 </ dl>4139 </li> 4140 </ul> 4131 4141 <h3 id="rfc.section.14.9.5"><a href="#rfc.section.14.9.5">14.9.5</a> <a id="no-transform.directive" href="#no-transform.directive">No-Transform Directive</a></h3> 4132 4142 <p id="rfc.section.14.9.5.p.1"> <span id="rfc.iref.c.26"></span> <span id="rfc.iref.n.3"></span> no-transform 4133 4143 </p> 4134 < dl class="empty">4135 < dd>Implementors of intermediate caches (proxies) have found it useful to convert the media type of certain entity bodies. A non-transparent4144 <ul class="empty"> 4145 <li>Implementors of intermediate caches (proxies) have found it useful to convert the media type of certain entity bodies. A non-transparent 4136 4146 proxy might, for example, convert between image formats in order to save cache space or to reduce the amount of traffic on 4137 4147 a slow link. 4138 </ dd>4139 < dd>Serious operational problems occur, however, when these transformations are applied to entity bodies intended for certain4148 </li> 4149 <li>Serious operational problems occur, however, when these transformations are applied to entity bodies intended for certain 4140 4150 kinds of applications. For example, applications for medical imaging, scientific data analysis and those using end-to-end 4141 4151 authentication, all depend on receiving an entity body that is bit for bit identical to the original entity-body. 4142 </ dd>4143 < dd>Therefore, if a message includes the no-transform directive, an intermediate cache or proxy <em class="bcp14">MUST NOT</em> change those headers that are listed in <a href="#non-modifiable.headers" title="Non-modifiable Headers">Section 13.5.2</a> as being subject to the no-transform directive. This implies that the cache or proxy <em class="bcp14">MUST NOT</em> change any aspect of the entity-body that is specified by these headers, including the value of the entity-body itself.4144 </ dd>4145 </ dl>4152 </li> 4153 <li>Therefore, if a message includes the no-transform directive, an intermediate cache or proxy <em class="bcp14">MUST NOT</em> change those headers that are listed in <a href="#non-modifiable.headers" title="Non-modifiable Headers">Section 13.5.2</a> as being subject to the no-transform directive. This implies that the cache or proxy <em class="bcp14">MUST NOT</em> change any aspect of the entity-body that is specified by these headers, including the value of the entity-body itself. 4154 </li> 4155 </ul> 4146 4156 <h3 id="rfc.section.14.9.6"><a href="#rfc.section.14.9.6">14.9.6</a> <a id="cache.control.extensions" href="#cache.control.extensions">Cache Control Extensions</a></h3> 4147 4157 <p id="rfc.section.14.9.6.p.1">The Cache-Control header field can be extended through the use of one or more cache-extension tokens, each with an optional … … 4308 4318 <p id="rfc.section.14.15.p.8">Conversion of all line breaks to CRLF <em class="bcp14">MUST NOT</em> be done before computing or checking the digest: the line break convention used in the text actually transmitted <em class="bcp14">MUST</em> be left unaltered when computing the digest. 4309 4319 </p> 4310 < dl class="empty">4311 < dd> <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 several4320 <ul class="empty"> 4321 <li> <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 4312 4322 ways in which the application of Content-MD5 to HTTP entity-bodies differs from its application to MIME entity-bodies. One 4313 4323 is that HTTP, unlike MIME, does not use Content-Transfer-Encoding, and does use Transfer-Encoding and Content-Encoding. Another … … 4315 4325 used to compute the digest is the transmission byte order defined for the type. Lastly, HTTP allows transmission of text types 4316 4326 with any of several line break conventions and not just the canonical form using CRLF. 4317 </ dd>4318 </ dl>4327 </li> 4328 </ul> 4319 4329 <div id="rfc.iref.c.33"></div> 4320 4330 <div id="rfc.iref.h.19"></div> … … 4384 4394 resource), it <em class="bcp14">SHOULD</em> return a response code of 416 (Requested range not satisfiable) (<a href="#status.416" id="rfc.xref.status.416.2" title="416 Requested Range Not Satisfiable">Section 10.4.17</a>). 4385 4395 </p> 4386 < dl class="empty">4387 < dd> <b>Note:</b> clients cannot depend on servers to send a <a href="#status.416" class="smpl">416 (Requested range not satisfiable)</a> response instead of a <a href="#status.200" class="smpl">200 (OK)</a> response for an unsatisfiable Range request-header, since not all servers implement this request-header.4388 </ dd>4389 </ dl>4396 <ul class="empty"> 4397 <li> <b>Note:</b> clients cannot depend on servers to send a <a href="#status.416" class="smpl">416 (Requested range not satisfiable)</a> response instead of a <a href="#status.200" class="smpl">200 (OK)</a> response for an unsatisfiable Range request-header, since not all servers implement this request-header. 4398 </li> 4399 </ul> 4390 4400 <div id="rfc.iref.c.34"></div> 4391 4401 <div id="rfc.iref.h.20"></div> … … 4486 4496 <div id="rfc.figure.u.109"></div><pre class="text"> Expires: Thu, 01 Dec 1994 16:00:00 GMT 4487 4497 </pre><p id="rfc.section.14.21.p.7"> </p> 4488 < dl class="empty">4489 < dd> <b>Note:</b> if a response includes a Cache-Control field with the max-age directive (see <a href="#modifications.of.the.basic.expiration.mechanism" title="Modifications of the Basic Expiration Mechanism">Section 14.9.3</a>), that directive overrides the Expires field.4490 </ dd>4491 </ dl>4498 <ul class="empty"> 4499 <li> <b>Note:</b> if a response includes a Cache-Control field with the max-age directive (see <a href="#modifications.of.the.basic.expiration.mechanism" title="Modifications of the Basic Expiration Mechanism">Section 14.9.3</a>), that directive overrides the Expires field. 4500 </li> 4501 </ul> 4492 4502 <p id="rfc.section.14.21.p.8">HTTP/1.1 clients and caches <em class="bcp14">MUST</em> treat other invalid date formats, especially including the value "0", as in the past (i.e., "already expired"). 4493 4503 </p> … … 4597 4607 </ol> 4598 4608 <p id="rfc.section.14.25.p.6">The purpose of this feature is to allow efficient updates of cached information with a minimum amount of transaction overhead. </p> 4599 < dl class="empty">4600 < dd> <b>Note:</b> The Range request-header field modifies the meaning of If-Modified-Since; see <a href="#header.range" id="rfc.xref.header.range.6" title="Range">Section 14.35</a> for full details.4601 </ dd>4602 < dd> <b>Note:</b> If-Modified-Since times are interpreted by the server, whose clock might not be synchronized with the client.4603 </ dd>4604 < dd> <b>Note:</b> When handling an If-Modified-Since header field, some servers will use an exact date comparison function, rather than a less-than4609 <ul class="empty"> 4610 <li> <b>Note:</b> The Range request-header field modifies the meaning of If-Modified-Since; see <a href="#header.range" id="rfc.xref.header.range.6" title="Range">Section 14.35</a> for full details. 4611 </li> 4612 <li> <b>Note:</b> If-Modified-Since times are interpreted by the server, whose clock might not be synchronized with the client. 4613 </li> 4614 <li> <b>Note:</b> When handling an If-Modified-Since header field, some servers will use an exact date comparison function, rather than a less-than 4605 4615 function, for deciding whether to send a 304 (Not Modified) response. To get best results when sending an If-Modified-Since 4606 4616 header field for cache validation, clients are advised to use the exact date string received in a previous Last-Modified header 4607 4617 field whenever possible. 4608 </ dd>4609 < dd> <b>Note:</b> If a client uses an arbitrary date in the If-Modified-Since header instead of a date taken from the Last-Modified header for4618 </li> 4619 <li> <b>Note:</b> If a client uses an arbitrary date in the If-Modified-Since header instead of a date taken from the Last-Modified header for 4610 4620 the same request, the client should be aware of the fact that this date is interpreted in the server's understanding of time. 4611 4621 The client should consider unsynchronized clocks and rounding problems due to the different encodings of time between the … … 4614 4624 If-Modified-Since date is derived from the client's clock without correction to the server's clock. Corrections for different 4615 4625 time bases between client and server are at best approximate due to network latency. 4616 </ dd>4617 </ dl>4626 </li> 4627 </ul> 4618 4628 <p id="rfc.section.14.25.p.7">The result of a request having both an If-Modified-Since header field and either an If-Match or an If-Unmodified-Since header 4619 4629 fields is undefined by this specification. … … 4723 4733 <div id="rfc.figure.u.126"></div><pre class="text"> Location: http://www.w3.org/pub/WWW/People.html 4724 4734 </pre><p id="rfc.section.14.30.p.5"> </p> 4725 < dl class="empty">4726 < dd> <b>Note:</b> The Content-Location header field (<a href="#header.content-location" id="rfc.xref.header.content-location.2" title="Content-Location">Section 14.14</a>) differs from Location in that the Content-Location identifies the original location of the entity enclosed in the request.4735 <ul class="empty"> 4736 <li> <b>Note:</b> The Content-Location header field (<a href="#header.content-location" id="rfc.xref.header.content-location.2" title="Content-Location">Section 14.14</a>) differs from Location in that the Content-Location identifies the original location of the entity enclosed in the request. 4727 4737 It is therefore possible for a response to contain header fields for both Location and Content-Location. Also see <a href="#invalidation.after.updates.or.deletions" title="Invalidation After Updates or Deletions">Section 13.10</a> for cache requirements of some methods. 4728 </ dd>4729 </ dl>4738 </li> 4739 </ul> 4730 4740 <div id="rfc.iref.m.15"></div> 4731 4741 <div id="rfc.iref.h.35"></div> … … 4761 4771 HTTP. 4762 4772 </p> 4763 < dl class="empty">4764 < dd> <b>Note:</b> because the meaning of "Pragma: no-cache as a response header field is not actually specified, it does not provide a reliable4773 <ul class="empty"> 4774 <li> <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 4765 4775 replacement for "Cache-Control: no-cache" in a response 4766 </ dd>4767 </ dl>4776 </li> 4777 </ul> 4768 4778 <div id="rfc.iref.p.8"></div> 4769 4779 <div id="rfc.iref.h.37"></div> … … 4899 4909 </pre><p id="rfc.section.14.38.p.5">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the Server response-header. Instead, it <em class="bcp14">SHOULD</em> include a Via field (as described in <a href="#header.via" id="rfc.xref.header.via.3" title="Via">Section 14.45</a>). 4900 4910 </p> 4901 < dl class="empty">4902 < dd> <b>Note:</b> Revealing the specific software version of the server might allow the server machine to become more vulnerable to attacks4911 <ul class="empty"> 4912 <li> <b>Note:</b> Revealing the specific software version of the server might allow the server machine to become more vulnerable to attacks 4903 4913 against software that is known to contain security holes. Server implementors are encouraged to make this field a configurable 4904 4914 option. 4905 </ dd>4906 </ dl>4915 </li> 4916 </ul> 4907 4917 <div id="rfc.iref.t.3"></div> 4908 4918 <div id="rfc.iref.h.43"></div> … … 5140 5150 <p id="rfc.section.14.46.p.12"> <span id="rfc.iref.395"></span> <span id="rfc.iref.w.2"></span> 110 Response is stale 5141 5151 </p> 5142 < dl class="empty">5143 < dd> <em class="bcp14">MUST</em> be included whenever the returned response is stale.5144 </ dd>5145 </ dl>5152 <ul class="empty"> 5153 <li> <em class="bcp14">MUST</em> be included whenever the returned response is stale. 5154 </li> 5155 </ul> 5146 5156 <p id="rfc.section.14.46.p.13"> <span id="rfc.iref.396"></span> <span id="rfc.iref.w.3"></span> 111 Revalidation failed 5147 5157 </p> 5148 < dl class="empty">5149 < dd> <em class="bcp14">MUST</em> be included if a cache returns a stale response because an attempt to revalidate the response failed, due to an inability5158 <ul class="empty"> 5159 <li> <em class="bcp14">MUST</em> be included if a cache returns a stale response because an attempt to revalidate the response failed, due to an inability 5150 5160 to reach the server. 5151 </ dd>5152 </ dl>5161 </li> 5162 </ul> 5153 5163 <p id="rfc.section.14.46.p.14"> <span id="rfc.iref.397"></span> <span id="rfc.iref.w.4"></span> 112 Disconnected operation 5154 5164 </p> 5155 < dl class="empty">5156 < dd> <em class="bcp14">SHOULD</em> be included if the cache is intentionally disconnected from the rest of the network for a period of time.5157 </ dd>5158 </ dl>5165 <ul class="empty"> 5166 <li> <em class="bcp14">SHOULD</em> be included if the cache is intentionally disconnected from the rest of the network for a period of time. 5167 </li> 5168 </ul> 5159 5169 <p id="rfc.section.14.46.p.15"> <span id="rfc.iref.398"></span> <span id="rfc.iref.w.5"></span> 113 Heuristic expiration 5160 5170 </p> 5161 < dl class="empty">5162 < dd> <em class="bcp14">MUST</em> be included if the cache heuristically chose a freshness lifetime greater than 24 hours and the response's age is greater5171 <ul class="empty"> 5172 <li> <em class="bcp14">MUST</em> be included if the cache heuristically chose a freshness lifetime greater than 24 hours and the response's age is greater 5163 5173 than 24 hours. 5164 </ dd>5165 </ dl>5174 </li> 5175 </ul> 5166 5176 <p id="rfc.section.14.46.p.16"> <span id="rfc.iref.399"></span> <span id="rfc.iref.w.6"></span> 199 Miscellaneous warning 5167 5177 </p> 5168 < dl class="empty">5169 < dd>The warning text <em class="bcp14">MAY</em> include arbitrary information to be presented to a human user, or logged. A system receiving this warning <em class="bcp14">MUST NOT</em> take any automated action, besides presenting the warning to the user.5170 </ dd>5171 </ dl>5178 <ul class="empty"> 5179 <li>The warning text <em class="bcp14">MAY</em> include arbitrary information to be presented to a human user, or logged. A system receiving this warning <em class="bcp14">MUST NOT</em> take any automated action, besides presenting the warning to the user. 5180 </li> 5181 </ul> 5172 5182 <p id="rfc.section.14.46.p.17"> <span id="rfc.iref.400"></span> <span id="rfc.iref.w.7"></span> 214 Transformation applied 5173 5183 </p> 5174 < dl class="empty">5175 < dd> <em class="bcp14">MUST</em> be added by an intermediate cache or proxy if it applies any transformation changing the content-coding (as specified in the5184 <ul class="empty"> 5185 <li> <em class="bcp14">MUST</em> be added by an intermediate cache or proxy if it applies any transformation changing the content-coding (as specified in the 5176 5186 Content-Encoding header) or media-type (as specified in the Content-Type header) of the response, or the entity-body of the 5177 5187 response, unless this Warning code already appears in the response. 5178 </ dd>5179 </ dl>5188 </li> 5189 </ul> 5180 5190 <p id="rfc.section.14.46.p.18"> <span id="rfc.iref.401"></span> <span id="rfc.iref.w.8"></span> 299 Miscellaneous persistent warning 5181 5191 </p> 5182 < dl class="empty">5183 < dd>The warning text <em class="bcp14">MAY</em> include arbitrary information to be presented to a human user, or logged. A system receiving this warning <em class="bcp14">MUST NOT</em> take any automated action.5184 </ dd>5185 </ dl>5192 <ul class="empty"> 5193 <li>The warning text <em class="bcp14">MAY</em> include arbitrary information to be presented to a human user, or logged. A system receiving this warning <em class="bcp14">MUST NOT</em> take any automated action. 5194 </li> 5195 </ul> 5186 5196 <p id="rfc.section.14.46.p.19">If an implementation sends a message with one or more Warning headers whose version is HTTP/1.0 or lower, then the sender <em class="bcp14">MUST</em> include in each warning-value a warn-date that matches the date in the response. 5187 5197 </p> … … 5415 5425 <h1 class="np" id="rfc.references"><a href="#rfc.section.17" id="rfc.section.17">17.</a> References 5416 5426 </h1> 5417 <table summary="References">5427 <table> 5418 5428 <tr> 5419 5429 <td class="reference"><b id="RFC1766">[1]</b></td> … … 5437 5447 </td> 5438 5448 </tr> 5439 <!--WARNING: unused reference 'RFC1866'-->5440 5449 <tr> 5441 5450 <td class="reference"><b id="RFC1866">[5]</b></td> 5442 <td class="top"><a href="mailto:timbl@w3.org" title="MIT Laboratory for Computer Science">Berners-Lee, T.</a> and <a href="mailto:connolly@w3.org" title="MIT Laboratory for Computer Science, W3 Consortium">D. W.Connolly</a>, “<a href="http://tools.ietf.org/html/rfc1866">Hypertext Markup Language - 2.0</a>”, RFC 1866, November 1995.5451 <td class="top"><a href="mailto:timbl@w3.org" title="MIT Laboratory for Computer Science">Berners-Lee, T.</a> and <a href="mailto:connolly@w3.org" title="MIT Laboratory for Computer Science, W3 Consortium">D. Connolly</a>, “<a href="http://tools.ietf.org/html/rfc1866">Hypertext Markup Language - 2.0</a>”, RFC 1866, November 1995. 5443 5452 </td> 5444 5453 </tr> 5445 5454 <tr> 5446 5455 <td class="reference"><b id="RFC1945">[6]</b></td> 5447 <td class="top"><a href="mailto:timbl@w3.org" title="MIT, Laboratory for Computer Science">Berners-Lee, T.</a>, <a href="mailto:fielding@ics.uci.edu" title="University of California, Irvine, Department of Information and Computer Science">Fielding, R. T.</a>, and <a href="mailto:frystyk@w3.org" title="W3 Consortium, MIT Laboratory for Computer Science">H.F. Nielsen</a>, “<a href="http://tools.ietf.org/html/rfc1945">Hypertext Transfer Protocol -- HTTP/1.0</a>”, RFC 1945, May 1996.5456 <td class="top"><a href="mailto:timbl@w3.org" title="MIT, Laboratory for Computer Science">Berners-Lee, T.</a>, <a href="mailto:fielding@ics.uci.edu" title="University of California, Irvine, Department of Information and Computer Science">Fielding, R.</a>, and <a href="mailto:frystyk@w3.org" title="W3 Consortium, MIT Laboratory for Computer Science">H. Nielsen</a>, “<a href="http://tools.ietf.org/html/rfc1945">Hypertext Transfer Protocol -- HTTP/1.0</a>”, RFC 1945, May 1996. 5448 5457 </td> 5449 5458 </tr> 5450 5459 <tr> 5451 5460 <td class="reference"><b id="RFC2045">[7]</b></td> 5452 <td class="top"><a href="mailto:ned@innosoft.com" title="Innosoft International, Inc.">Freed, N.</a> and <a href="mailto:nsb@nsb.fv.com" title="First Virtual Holdings">N. S.Borenstein</a>, “<a href="http://tools.ietf.org/html/rfc2045">Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies</a>”, RFC 2045, November 1996.5461 <td class="top"><a href="mailto:ned@innosoft.com" title="Innosoft International, Inc.">Freed, N.</a> and <a href="mailto:nsb@nsb.fv.com" title="First Virtual Holdings">N. Borenstein</a>, “<a href="http://tools.ietf.org/html/rfc2045">Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies</a>”, RFC 2045, November 1996. 5453 5462 </td> 5454 5463 </tr> … … 5460 5469 <tr> 5461 5470 <td class="reference"><b id="RFC822">[9]</b></td> 5462 <td class="top"><a href="mailto:DCrocker@UDel-Relay" title="University of Delaware, Dept. of Electrical Engineering">Crocker, D. H.</a>, “<a href="http://tools.ietf.org/html/rfc822">Standard for the format of ARPA Internet text messages</a>”, STD 11, RFC 822, August 1982.5471 <td class="top"><a href="mailto:DCrocker@UDel-Relay" title="University of Delaware, Dept. of Electrical Engineering">Crocker, D.</a>, “<a href="http://tools.ietf.org/html/rfc822">Standard for the format of ARPA Internet text messages</a>”, STD 11, RFC 822, August 1982. 5463 5472 </td> 5464 5473 </tr> … … 5494 5503 <tr> 5495 5504 <td class="reference"><b id="RFC821">[16]</b></td> 5496 <td class="top">Postel, J. B., “<a href="http://tools.ietf.org/html/rfc821">Simple Mail Transfer Protocol</a>”, STD 10, RFC 821, August 1982.5505 <td class="top">Postel, J., “<a href="http://tools.ietf.org/html/rfc821">Simple Mail Transfer Protocol</a>”, STD 10, RFC 821, August 1982. 5497 5506 </td> 5498 5507 </tr> … … 5523 5532 <tr> 5524 5533 <td class="reference"><b id="ISO-8859">[22]</b></td> 5525 <td class="top">International Organization for Standardization, “Information technology - 8-bit single byte coded graphic - character sets” 5526 <!--WARNING: date/@year should be a number: '1987-1990' in reference 'ISO-8859'-->, 1987-1990.<br>Part 1: Latin alphabet No. 1, ISO-8859-1:1987. Part 2: Latin alphabet No. 2, ISO-8859-2, 1987. Part 3: Latin alphabet No. 5534 <td class="top">International Organization for Standardization, “Information technology - 8-bit single byte coded graphic - character sets”, 1987-1990.<br>Part 1: Latin alphabet No. 1, ISO-8859-1:1987. Part 2: Latin alphabet No. 2, ISO-8859-2, 1987. Part 3: Latin alphabet No. 5527 5535 3, ISO-8859-3, 1988. Part 4: Latin alphabet No. 4, ISO-8859-4, 1988. Part 5: Latin/Cyrillic alphabet, ISO-8859-5, 1988. Part 5528 5536 6: Latin/Arabic alphabet, ISO-8859-6, 1987. Part 7: Latin/Greek alphabet, ISO-8859-7, 1987. Part 8: Latin/Hebrew alphabet, … … 5542 5550 <tr> 5543 5551 <td class="reference"><b id="RFC1952">[25]</b></td> 5544 <td class="top"><a href="mailto:ghost@aladdin.com" title="Aladdin Enterprises">Deutsch, P.</a>, <a href="mailto:gzip@prep.ai.mit.edu">Gailly, J-L.</a>, <a href="mailto:madler@alumni.caltech.edu">Adler, M.</a>, <a href="mailto:ghost@aladdin.com">Deutsch, L. P.</a>, and <a href="mailto:randeg@alumni.rpi.edu">G. Randers-Pehrson</a>, “<a href="http://tools.ietf.org/html/rfc1952">GZIP file format specification version 4.3</a>”, RFC 1952, May 1996.5552 <td class="top"><a href="mailto:ghost@aladdin.com" title="Aladdin Enterprises">Deutsch, P.</a>, <a href="mailto:gzip@prep.ai.mit.edu">Gailly, J-L.</a>, <a href="mailto:madler@alumni.caltech.edu">Adler, M.</a>, <a href="mailto:ghost@aladdin.com">Deutsch, L.</a>, and <a href="mailto:randeg@alumni.rpi.edu">G. Randers-Pehrson</a>, “<a href="http://tools.ietf.org/html/rfc1952">GZIP file format specification version 4.3</a>”, RFC 1952, May 1996. 5545 5553 </td> 5546 5554 </tr> 5547 5555 <tr> 5548 5556 <td class="reference"><b id="Pad1995">[26]</b></td> 5549 <td class="top">Padmanabhan, V. N. and J.C. Mogul, “Improving HTTP Latency”, Computer Networks and ISDN Systems v. 28, pp. 25-35, Dec 1995.<br>Slightly revised version of paper in Proc. 2nd International WWW Conference '94: Mosaic and the Web, Oct. 1994, which is available5557 <td class="top">Padmanabhan, V. and J. Mogul, “Improving HTTP Latency”, Computer Networks and ISDN Systems v. 28, pp. 25-35, Dec 1995.<br>Slightly revised version of paper in Proc. 2nd International WWW Conference '94: Mosaic and the Web, Oct. 1994, which is available 5550 5558 at <<a href="http://www.ncsa.uiuc.edu/SDG/IT94/Proceedings/DDay/mogul/HTTPLatency.html">http://www.ncsa.uiuc.edu/SDG/IT94/Proceedings/DDay/mogul/HTTPLatency.html</a>>. 5551 5559 </td> … … 5573 5581 <tr> 5574 5582 <td class="reference"><b id="RFC1950">[31]</b></td> 5575 <td class="top"><a href="mailto:ghost@aladdin.com" title="Aladdin Enterprises">Deutsch, L. P.</a> and J-L. Gailly, “<a href="http://tools.ietf.org/html/rfc1950">ZLIB Compressed Data Format Specification version 3.3</a>”, RFC 1950, May 1996.5583 <td class="top"><a href="mailto:ghost@aladdin.com" title="Aladdin Enterprises">Deutsch, L.</a> and J-L. Gailly, “<a href="http://tools.ietf.org/html/rfc1950">ZLIB Compressed Data Format Specification version 3.3</a>”, RFC 1950, May 1996. 5576 5584 </td> 5577 5585 </tr> 5578 <!--WARNING: unused reference 'RFC2069'-->5579 5586 <tr> 5580 5587 <td class="reference"><b id="RFC2069">[32]</b></td> … … 5599 5606 <tr> 5600 5607 <td class="reference"><b id="RFC2145">[36]</b></td> 5601 <td class="top"><a href="mailto:mogul@wrl.dec.com" title="Western Research Laboratory">Mogul, J. C.</a>, <a href="mailto:fielding@ics.uci.edu" title="Department of Information and Computer Science">Fielding, R.T.</a>, <a href="mailto:jg@w3.org" title="MIT Laboratory for Computer Science">Gettys, J.</a>, and <a href="mailto:frystyk@w3.org" title="W3 Consortium">H.F. Nielsen</a>, “<a href="http://tools.ietf.org/html/rfc2145">Use and Interpretation of HTTP Version Numbers</a>”, RFC 2145, May 1997.5608 <td class="top"><a href="mailto:mogul@wrl.dec.com" title="Western Research Laboratory">Mogul, J.</a>, <a href="mailto:fielding@ics.uci.edu" title="Department of Information and Computer Science">Fielding, R.</a>, <a href="mailto:jg@w3.org" title="MIT Laboratory for Computer Science">Gettys, J.</a>, and <a href="mailto:frystyk@w3.org" title="W3 Consortium">H. Nielsen</a>, “<a href="http://tools.ietf.org/html/rfc2145">Use and Interpretation of HTTP Version Numbers</a>”, RFC 2145, May 1997. 5602 5609 </td> 5603 5610 </tr> … … 5614 5621 <tr> 5615 5622 <td class="reference"><b id="Nie1997">[39]</b></td> 5616 <td class="top">Nielsen, H. F.., Gettys, J., Prud'hommeaux, E., Lie, H., and C. Lilley, “Network Performance Effects of HTTP/1.1, CSS1, and PNG”, Proceedings of ACM SIGCOMM '97, Cannes France, Sep 1997.</td>5623 <td class="top">Nielsen, H., Gettys, J., Prud'hommeaux, E., Lie, H., and C. Lilley, “Network Performance Effects of HTTP/1.1, CSS1, and PNG”, Proceedings of ACM SIGCOMM '97, Cannes France, Sep 1997.</td> 5617 5624 </tr> 5618 5625 <tr> … … 5623 5630 <tr> 5624 5631 <td class="reference"><b id="RFC2277">[41]</b></td> 5625 <td class="top"><a href="mailto:Harald.T.Alvestrand@uninett.no" title="UNINETT">Alvestrand, H. T.</a>, “<a href="http://tools.ietf.org/html/rfc2277">IETF Policy on Character Sets and Languages</a>”, BCP 18, RFC 2277, January 1998.5632 <td class="top"><a href="mailto:Harald.T.Alvestrand@uninett.no" title="UNINETT">Alvestrand, H.</a>, “<a href="http://tools.ietf.org/html/rfc2277">IETF Policy on Character Sets and Languages</a>”, BCP 18, RFC 2277, January 1998. 5626 5633 </td> 5627 5634 </tr> 5628 5635 <tr> 5629 5636 <td class="reference"><b id="RFC2396">[42]</b></td> 5630 <td class="top"><a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</a>, <a href="mailto:fielding@ics.uci.edu" title="Department of Information and Computer Science">Fielding, R. T.</a>, and <a href="mailto:masinter@parc.xerox.com" title="Xerox PARC">L. Masinter</a>, “<a href="http://tools.ietf.org/html/rfc2396">Uniform Resource Identifiers (URI): Generic Syntax</a>”, RFC 2396, August 1998.5637 <td class="top"><a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</a>, <a href="mailto:fielding@ics.uci.edu" title="Department of Information and Computer Science">Fielding, R.</a>, and <a href="mailto:masinter@parc.xerox.com" title="Xerox PARC">L. Masinter</a>, “<a href="http://tools.ietf.org/html/rfc2396">Uniform Resource Identifiers (URI): Generic Syntax</a>”, RFC 2396, August 1998. 5631 5638 </td> 5632 5639 </tr> 5633 5640 <tr> 5634 5641 <td class="reference"><b id="RFC2617">[43]</b></td> 5635 <td class="top"><a href="mailto:john@math.nwu.edu" title="Northwestern University, Department of Mathematics">Franks, J.</a>, <a href="mailto:pbaker@verisign.com" title="Verisign Inc.">Hallam-Baker, P. M.</a>, <a href="mailto:jeff@AbiSource.com" title="AbiSource, Inc.">Hostetler, J.L.</a>, <a href="mailto:lawrence@agranat.com" title="Agranat Systems, Inc.">Lawrence, S.D.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.J.</a>, Luotonen, A., and <a href="mailto:stewart@OpenMarket.com" title="Open Market, Inc.">L. Stewart</a>, “<a href="http://tools.ietf.org/html/rfc2617">HTTP Authentication: Basic and Digest Access Authentication</a>”, RFC 2617, June 1999.5642 <td class="top"><a href="mailto:john@math.nwu.edu" title="Northwestern University, Department of Mathematics">Franks, J.</a>, <a href="mailto:pbaker@verisign.com" title="Verisign Inc.">Hallam-Baker, P.</a>, <a href="mailto:jeff@AbiSource.com" title="AbiSource, Inc.">Hostetler, J.</a>, <a href="mailto:lawrence@agranat.com" title="Agranat Systems, Inc.">Lawrence, S.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, Luotonen, A., and <a href="mailto:stewart@OpenMarket.com" title="Open Market, Inc.">L. Stewart</a>, “<a href="http://tools.ietf.org/html/rfc2617">HTTP Authentication: Basic and Digest Access Authentication</a>”, RFC 2617, June 1999. 5636 5643 </td> 5637 5644 </tr> … … 5645 5652 </td> 5646 5653 </tr> 5647 <!--WARNING: unused reference 'RFC2026'-->5648 5654 <tr> 5649 5655 <td class="reference"><b id="RFC2026">[46]</b></td> … … 5658 5664 <tr> 5659 5665 <td class="reference"><b id="RFC2049">[48]</b></td> 5660 <td class="top"><a href="mailto:ned@innosoft.com" title="Innosoft International, Inc.">Freed, N.</a> and <a href="mailto:nsb@nsb.fv.com" title="First Virtual Holdings">N. S.Borenstein</a>, “<a href="http://tools.ietf.org/html/rfc2049">Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples</a>”, RFC 2049, November 1996.5666 <td class="top"><a href="mailto:ned@innosoft.com" title="Innosoft International, Inc.">Freed, N.</a> and <a href="mailto:nsb@nsb.fv.com" title="First Virtual Holdings">N. Borenstein</a>, “<a href="http://tools.ietf.org/html/rfc2049">Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples</a>”, RFC 2049, November 1996. 5661 5667 </td> 5662 5668 </tr> … … 5668 5674 </table> 5669 5675 <hr class="noprint"> 5670 <h1 id="rfc.authors" class="np"><a href="#rfc.section.18" id="rfc.section.18">18.</a> <a href="#rfc.authors">Authors' Addresses</a></h1> 5671 <address class="vcard"><span class="vcardline"><span class="fn">Roy T. Fielding</span><span class="n hidden"><span class="family-name">Fielding</span><span class="given-name">Roy T.</span></span></span><span class="org vcardline">Department of Information and Computer Science</span><span class="adr"><span class="street-address vcardline">University of California, Irvine</span><span class="vcardline"><span class="locality">Irvine</span>, <span class="region">CA</span> <span class="postal-code">92697-3425</span></span></span><span class="vcardline tel"><span class="type">Fax</span>: <a href="fax:+1(949)824-1715"><span class="value">+1(949)824-1715</span></a></span><span class="vcardline">EMail: <a href="mailto:fielding@ics.uci.edu"><span class="email">fielding@ics.uci.edu</span></a></span></address> 5672 <address class="vcard"><span class="vcardline"><span class="fn">James Gettys</span><span class="n hidden"><span class="family-name">Gettys</span><span class="given-name">James</span></span></span><span class="org vcardline">World Wide Web Consortium</span><span class="adr"><span class="street-address vcardline">MIT Laboratory for Computer Science, NE43-356</span><span class="street-address vcardline">545 Technology Square</span><span class="vcardline"><span class="locality">Cambridge</span>, <span class="region">MA</span> <span class="postal-code">02139</span></span></span><span class="vcardline tel"><span class="type">Fax</span>: <a href="fax:+1(617)258-8682"><span class="value">+1(617)258-8682</span></a></span><span class="vcardline">EMail: <a href="mailto:jg@w3.org"><span class="email">jg@w3.org</span></a></span></address> 5673 <address class="vcard"><span class="vcardline"><span class="fn">Jeffrey C. Mogul</span><span class="n hidden"><span class="family-name">Mogul</span><span class="given-name">Jeffrey C.</span></span></span><span class="org vcardline">Compaq Computer Corporation</span><span class="adr"><span class="street-address vcardline">Western Research Laboratory</span><span class="street-address vcardline">250 University Avenue</span><span class="vcardline"><span class="locality">Palo Alto</span>, <span class="region">CA</span> <span class="postal-code">94305</span></span></span><span class="vcardline">EMail: <a href="mailto:mogul@wrl.dec.com"><span class="email">mogul@wrl.dec.com</span></a></span></address> 5674 <address class="vcard"><span class="vcardline"><span class="fn">Henrik Frystyk Nielsen</span><span class="n hidden"><span class="family-name">Frystyk</span></span></span><span class="org vcardline">World Wide Web Consortium</span><span class="adr"><span class="street-address vcardline">MIT Laboratory for Computer Science, NE43-356</span><span class="street-address vcardline">545 Technology Square</span><span class="vcardline"><span class="locality">Cambridge</span>, <span class="region">MA</span> <span class="postal-code">02139</span></span></span><span class="vcardline tel"><span class="type">Fax</span>: <a href="fax:+1(617)258-8682"><span class="value">+1(617)258-8682</span></a></span><span class="vcardline">EMail: <a href="mailto:frystyk@w3.org"><span class="email">frystyk@w3.org</span></a></span></address> 5675 <address class="vcard"><span class="vcardline"><span class="fn">Larry Masinter</span><span class="n hidden"><span class="family-name">Masinter</span><span class="given-name">Larry</span></span></span><span class="org vcardline">Xerox Corporation</span><span class="adr"><span class="street-address vcardline">MIT Laboratory for Computer Science, NE43-356</span><span class="street-address vcardline">3333 Coyote Hill Road</span><span class="vcardline"><span class="locality">Palo Alto</span>, <span class="region">CA</span> <span class="postal-code">94034</span></span></span><span class="vcardline">EMail: <a href="mailto:masinter@parc.xerox.com"><span class="email">masinter@parc.xerox.com</span></a></span></address> 5676 <address class="vcard"><span class="vcardline"><span class="fn">Paul J. Leach</span><span class="n hidden"><span class="family-name">Leach</span><span class="given-name">Paul J.</span></span></span><span class="org vcardline">Microsoft Corporation</span><span class="adr"><span class="street-address vcardline">1 Microsoft Way</span><span class="vcardline"><span class="locality">Redmond</span>, <span class="region">WA</span> <span class="postal-code">98052</span></span></span><span class="vcardline">EMail: <a href="mailto:paulle@microsoft.com"><span class="email">paulle@microsoft.com</span></a></span></address> 5677 <address class="vcard"><span class="vcardline"><span class="fn">Tim Berners-Lee</span><span class="n hidden"><span class="family-name">Berners-Lee</span><span class="given-name">Tim</span></span></span><span class="org vcardline">World Wide Web Consortium</span><span class="adr"><span class="street-address vcardline">MIT Laboratory for Computer Science, NE43-356</span><span class="street-address vcardline">545 Technology Square</span><span class="vcardline"><span class="locality">Cambridge</span>, <span class="region">MA</span> <span class="postal-code">02139</span></span></span><span class="vcardline tel"><span class="type">Fax</span>: <a href="fax:+1(617)258-8682"><span class="value">+1(617)258-8682</span></a></span><span class="vcardline">EMail: <a href="mailto:timbl@w3.org"><span class="email">timbl@w3.org</span></a></span></address> 5676 <div class="avoidbreak"> 5677 <h1 id="rfc.authors" class="np"><a href="#rfc.section.18" id="rfc.section.18">18.</a> <a href="#rfc.authors">Authors' Addresses</a></h1> 5678 <address class="vcard"><span class="vcardline"><span class="fn">Roy T. Fielding</span><span class="n hidden"><span class="family-name">Fielding</span><span class="given-name">Roy T.</span></span></span><span class="org vcardline">Department of Information and Computer Science</span><span class="adr"><span class="street-address vcardline">University of California, Irvine</span><span class="vcardline"><span class="locality">Irvine</span>, <span class="region">CA</span> <span class="postal-code">92697-3425</span></span></span><span class="vcardline tel"><span class="type">Fax</span>: <a href="fax:+1(949)824-1715"><span class="value">+1(949)824-1715</span></a></span><span class="vcardline">EMail: <a href="mailto:fielding@ics.uci.edu"><span class="email">fielding@ics.uci.edu</span></a></span></address> 5679 <address class="vcard"><span class="vcardline"><span class="fn">James Gettys</span><span class="n hidden"><span class="family-name">Gettys</span><span class="given-name">James</span></span></span><span class="org vcardline">World Wide Web Consortium</span><span class="adr"><span class="street-address vcardline">MIT Laboratory for Computer Science, NE43-356</span><span class="street-address vcardline">545 Technology Square</span><span class="vcardline"><span class="locality">Cambridge</span>, <span class="region">MA</span> <span class="postal-code">02139</span></span></span><span class="vcardline tel"><span class="type">Fax</span>: <a href="fax:+1(617)258-8682"><span class="value">+1(617)258-8682</span></a></span><span class="vcardline">EMail: <a href="mailto:jg@w3.org"><span class="email">jg@w3.org</span></a></span></address> 5680 <address class="vcard"><span class="vcardline"><span class="fn">Jeffrey C. Mogul</span><span class="n hidden"><span class="family-name">Mogul</span><span class="given-name">Jeffrey C.</span></span></span><span class="org vcardline">Compaq Computer Corporation</span><span class="adr"><span class="street-address vcardline">Western Research Laboratory</span><span class="street-address vcardline">250 University Avenue</span><span class="vcardline"><span class="locality">Palo Alto</span>, <span class="region">CA</span> <span class="postal-code">94305</span></span></span><span class="vcardline">EMail: <a href="mailto:mogul@wrl.dec.com"><span class="email">mogul@wrl.dec.com</span></a></span></address> 5681 <address class="vcard"><span class="vcardline"><span class="fn">Henrik Frystyk Nielsen</span><span class="n hidden"><span class="family-name">Frystyk</span></span></span><span class="org vcardline">World Wide Web Consortium</span><span class="adr"><span class="street-address vcardline">MIT Laboratory for Computer Science, NE43-356</span><span class="street-address vcardline">545 Technology Square</span><span class="vcardline"><span class="locality">Cambridge</span>, <span class="region">MA</span> <span class="postal-code">02139</span></span></span><span class="vcardline tel"><span class="type">Fax</span>: <a href="fax:+1(617)258-8682"><span class="value">+1(617)258-8682</span></a></span><span class="vcardline">EMail: <a href="mailto:frystyk@w3.org"><span class="email">frystyk@w3.org</span></a></span></address> 5682 <address class="vcard"><span class="vcardline"><span class="fn">Larry Masinter</span><span class="n hidden"><span class="family-name">Masinter</span><span class="given-name">Larry</span></span></span><span class="org vcardline">Xerox Corporation<