Changeset 348 for draft-ietf-httpbis/latest-roy
- Timestamp:
- 12/11/08 22:25:02 (12 years ago)
- Location:
- draft-ietf-httpbis/latest-roy
- Files:
-
- 9 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest-roy/p2-semantics.html
r345 r348 477 477 <tr> 478 478 <td class="header left"></td> 479 <td class="header right">November 1 1, 2008</td>479 <td class="header right">November 12, 2008</td> 480 480 </tr> 481 481 </table> … … 681 681 <p id="rfc.section.2.p.4"> The ABNF rules below are defined in other parts:</p> 682 682 </div> 683 <div id="rfc.figure.u.3"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">absoluteURI</a> = <absoluteURI, defined in <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html# general.syntax" title="ERROR: Anchor 'general.syntax' not found in p1-messaging.xml.">Appendix ERROR: Anchor 'general.syntax' not found in p1-messaging.xml.</a>>684 <a href="#abnf.dependencies" class="smpl">fragment</a> = <fragment, defined in <a href="#Part1" id="rfc.xref.Part1.9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html# general.syntax" title="ERROR: Anchor 'general.syntax' not found in p1-messaging.xml.">Appendix ERROR: Anchor 'general.syntax' not found in p1-messaging.xml.</a>>683 <div id="rfc.figure.u.3"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">absoluteURI</a> = <absoluteURI, defined in <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.1</a>> 684 <a href="#abnf.dependencies" class="smpl">fragment</a> = <fragment, defined in <a href="#Part1" id="rfc.xref.Part1.9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.1</a>> 685 685 <a href="#abnf.dependencies" class="smpl">Host</a> = <Host, defined in <a href="#Part1" id="rfc.xref.Part1.10"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.host" title="Host">Section 8.4</a>> 686 686 <a href="#abnf.dependencies" class="smpl">HTTP-date</a> = <HTTP-date, defined in <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#full.date" title="Full Date">Section 3.2.1</a>> 687 687 <a href="#abnf.dependencies" class="smpl">product</a> = <product, defined in <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 3.4</a>> 688 <a href="#abnf.dependencies" class="smpl">relativeURI</a> = <relativeURI, defined in <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html# general.syntax" title="ERROR: Anchor 'general.syntax' not found in p1-messaging.xml.">Appendix ERROR: Anchor 'general.syntax' not found in p1-messaging.xml.</a>>688 <a href="#abnf.dependencies" class="smpl">relativeURI</a> = <relativeURI, defined in <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.1</a>> 689 689 <a href="#abnf.dependencies" class="smpl">TE</a> = <TE, defined in <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 8.8</a>> 690 690 </pre><div id="rfc.figure.u.4"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">Accept</a> = <Accept, defined in <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept" title="Accept">Section 6.1</a>> … … 2505 2505 <li class="indline0"><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul class="ind"> 2506 2506 <li class="indline1"><em>Part1</em> <a class="iref" href="#rfc.xref.Part1.1">1</a>, <a class="iref" href="#rfc.xref.Part1.2">2</a>, <a class="iref" href="#rfc.xref.Part1.3">2</a>, <a class="iref" href="#rfc.xref.Part1.4">2</a>, <a class="iref" href="#rfc.xref.Part1.5">2</a>, <a class="iref" href="#rfc.xref.Part1.6">2</a>, <a class="iref" href="#rfc.xref.Part1.7">2</a>, <a class="iref" href="#rfc.xref.Part1.8">2</a>, <a class="iref" href="#rfc.xref.Part1.9">2</a>, <a class="iref" href="#rfc.xref.Part1.10">2</a>, <a class="iref" href="#rfc.xref.Part1.11">2</a>, <a class="iref" href="#rfc.xref.Part1.12">2</a>, <a class="iref" href="#rfc.xref.Part1.13">2</a>, <a class="iref" href="#rfc.xref.Part1.14">2</a>, <a class="iref" href="#rfc.xref.Part1.15">4</a>, <a class="iref" href="#rfc.xref.Part1.16">4</a>, <a class="iref" href="#rfc.xref.Part1.17">7</a>, <a class="iref" href="#rfc.xref.Part1.18">8.8</a>, <a class="iref" href="#rfc.xref.Part1.19">8.8</a>, <a class="iref" href="#rfc.xref.Part1.20">9.1.1</a>, <a class="iref" href="#rfc.xref.Part1.21">9.5.6</a>, <a class="iref" href="#rfc.xref.Part1.22">10.2</a>, <a class="iref" href="#rfc.xref.Part1.23">10.8</a>, <a class="iref" href="#rfc.xref.Part1.24">10.8</a>, <a class="iref" href="#rfc.xref.Part1.25">10.9</a>, <a class="iref" href="#Part1"><b>14.1</b></a>, <a class="iref" href="#rfc.xref.Part1.26">A.2</a><ul class="ind"> 2507 <li class="indline1"><em>Appendix </em> <a class="iref" href="#rfc.xref.Part1.8">2</a>, <a class="iref" href="#rfc.xref.Part1.9">2</a>, <a class="iref" href="#rfc.xref.Part1.13">2</a></li>2508 2507 <li class="indline1"><em>Section 1.2.1</em> <a class="iref" href="#rfc.xref.Part1.2">2</a></li> 2509 2508 <li class="indline1"><em>Section 1.2.2</em> <a class="iref" href="#rfc.xref.Part1.3">2</a>, <a class="iref" href="#rfc.xref.Part1.4">2</a>, <a class="iref" href="#rfc.xref.Part1.5">2</a>, <a class="iref" href="#rfc.xref.Part1.6">2</a>, <a class="iref" href="#rfc.xref.Part1.7">2</a></li> 2509 <li class="indline1"><em>Section 2.1</em> <a class="iref" href="#rfc.xref.Part1.8">2</a>, <a class="iref" href="#rfc.xref.Part1.9">2</a>, <a class="iref" href="#rfc.xref.Part1.13">2</a></li> 2510 2510 <li class="indline1"><em>Section 3.1</em> <a class="iref" href="#rfc.xref.Part1.21">9.5.6</a></li> 2511 2511 <li class="indline1"><em>Section 3.2.1</em> <a class="iref" href="#rfc.xref.Part1.11">2</a></li> -
draft-ietf-httpbis/latest-roy/p2-semantics.xml
r345 r348 24 24 <!ENTITY notation-abnf "<xref target='Part1' x:rel='#notation.abnf' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 25 25 <!ENTITY basic-rules "<xref target='Part1' x:rel='#basic.rules' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 26 <!ENTITY general-syntax "<xref target='Part1' x:rel='#general.syntax' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">27 26 <!ENTITY uri "<xref target='Part1' x:rel='#uri' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 28 27 <!ENTITY full-date "<xref target='Part1' x:rel='#full.date' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> … … 337 336 </t> 338 337 <figure><!--Part1--><artwork type="abnf2616"> 339 <x:ref>absoluteURI</x:ref> = <absoluteURI, defined in & general-syntax;>340 <x:ref>fragment</x:ref> = <fragment, defined in & general-syntax;>338 <x:ref>absoluteURI</x:ref> = <absoluteURI, defined in &uri;> 339 <x:ref>fragment</x:ref> = <fragment, defined in &uri;> 341 340 <x:ref>Host</x:ref> = <Host, defined in &header-host;> 342 341 <x:ref>HTTP-date</x:ref> = <HTTP-date, defined in &full-date;> 343 342 <x:ref>product</x:ref> = <product, defined in &product-tokens;> 344 <x:ref>relativeURI</x:ref> = <relativeURI, defined in & general-syntax;>343 <x:ref>relativeURI</x:ref> = <relativeURI, defined in &uri;> 345 344 <x:ref>TE</x:ref> = <TE, defined in &header-te;> 346 345 </artwork></figure> -
draft-ietf-httpbis/latest-roy/p3-payload.html
r345 r348 484 484 <tr> 485 485 <td class="header left"></td> 486 <td class="header right">November 1 1, 2008</td>486 <td class="header right">November 12, 2008</td> 487 487 </tr> 488 488 </table> … … 641 641 <p id="rfc.section.2.p.4"> The ABNF rules below are defined in other parts:</p> 642 642 </div> 643 <div id="rfc.figure.u.3"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">absoluteURI</a> = <absoluteURI, defined in <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html# general.syntax" title="ERROR: Anchor 'general.syntax' not found in p1-messaging.xml.">Appendix ERROR: Anchor 'general.syntax' not found in p1-messaging.xml.</a>>643 <div id="rfc.figure.u.3"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">absoluteURI</a> = <absoluteURI, defined in <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.1</a>> 644 644 <a href="#abnf.dependencies" class="smpl">Content-Length</a> = <Content-Length, defined in <a href="#Part1" id="rfc.xref.Part1.9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.content-length" title="Content-Length">Section 8.2</a>> 645 <a href="#abnf.dependencies" class="smpl">relativeURI</a> = <relativeURI, defined in <a href="#Part1" id="rfc.xref.Part1.10"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html# general.syntax" title="ERROR: Anchor 'general.syntax' not found in p1-messaging.xml.">Appendix ERROR: Anchor 'general.syntax' not found in p1-messaging.xml.</a>>645 <a href="#abnf.dependencies" class="smpl">relativeURI</a> = <relativeURI, defined in <a href="#Part1" id="rfc.xref.Part1.10"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.1</a>> 646 646 <a href="#abnf.dependencies" class="smpl">message-header</a> = <message-header, defined in <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#message.headers" title="Message Headers">Section 4.2</a>> 647 647 </pre><div id="rfc.figure.u.4"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">Last-Modified</a> = <Last-Modified, defined in <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p4-conditional.html#header.last-modified" title="Last-Modified">Section 7.6</a>> … … 1891 1891 <li class="indline0"><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul class="ind"> 1892 1892 <li class="indline1"><em>Part1</em> <a class="iref" href="#rfc.xref.Part1.1">2</a>, <a class="iref" href="#rfc.xref.Part1.2">2</a>, <a class="iref" href="#rfc.xref.Part1.3">2</a>, <a class="iref" href="#rfc.xref.Part1.4">2</a>, <a class="iref" href="#rfc.xref.Part1.5">2</a>, <a class="iref" href="#rfc.xref.Part1.6">2</a>, <a class="iref" href="#rfc.xref.Part1.7">2</a>, <a class="iref" href="#rfc.xref.Part1.8">2</a>, <a class="iref" href="#rfc.xref.Part1.9">2</a>, <a class="iref" href="#rfc.xref.Part1.10">2</a>, <a class="iref" href="#rfc.xref.Part1.11">2</a>, <a class="iref" href="#rfc.xref.Part1.12">4.1</a>, <a class="iref" href="#rfc.xref.Part1.13">4.2</a>, <a class="iref" href="#rfc.xref.Part1.14">4.2.2</a>, <a class="iref" href="#Part1"><b>10.1</b></a>, <a class="iref" href="#rfc.xref.Part1.15">A.5</a>, <a class="iref" href="#rfc.xref.Part1.16">C.1</a><ul class="ind"> 1893 <li class="indline1"><em>Appendix </em> <a class="iref" href="#rfc.xref.Part1.8">2</a>, <a class="iref" href="#rfc.xref.Part1.10">2</a></li>1894 1893 <li class="indline1"><em>Section 1.2.1</em> <a class="iref" href="#rfc.xref.Part1.1">2</a></li> 1895 1894 <li class="indline1"><em>Section 1.2.2</em> <a class="iref" href="#rfc.xref.Part1.2">2</a>, <a class="iref" href="#rfc.xref.Part1.3">2</a>, <a class="iref" href="#rfc.xref.Part1.4">2</a>, <a class="iref" href="#rfc.xref.Part1.5">2</a>, <a class="iref" href="#rfc.xref.Part1.6">2</a>, <a class="iref" href="#rfc.xref.Part1.7">2</a></li> 1895 <li class="indline1"><em>Section 2.1</em> <a class="iref" href="#rfc.xref.Part1.8">2</a>, <a class="iref" href="#rfc.xref.Part1.10">2</a></li> 1896 1896 <li class="indline1"><em>Section 4.2</em> <a class="iref" href="#rfc.xref.Part1.11">2</a></li> 1897 1897 <li class="indline1"><em>Section 4.3</em> <a class="iref" href="#rfc.xref.Part1.13">4.2</a></li> -
draft-ietf-httpbis/latest-roy/p3-payload.xml
r345 r348 28 28 <!ENTITY message-length "<xref target='Part1' x:rel='#message.length' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 29 29 <!ENTITY message-headers "<xref target='Part1' x:rel='#message.headers' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 30 <!ENTITY general-syntax "<xref target='Part1' x:rel='#general.syntax' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">30 <!ENTITY uri "<xref target='Part1' x:rel='#uri' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 31 31 <!ENTITY multipart-byteranges "<xref target='Part5' x:rel='#internet.media.type.multipart.byteranges' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 32 32 ]> … … 284 284 </t> 285 285 <figure><!--Part1--><artwork type="abnf2616"> 286 <x:ref>absoluteURI</x:ref> = <absoluteURI, defined in & general-syntax;>286 <x:ref>absoluteURI</x:ref> = <absoluteURI, defined in &uri;> 287 287 <x:ref>Content-Length</x:ref> = <Content-Length, defined in &header-content-length;> 288 <x:ref>relativeURI</x:ref> = <relativeURI, defined in & general-syntax;>288 <x:ref>relativeURI</x:ref> = <relativeURI, defined in &uri;> 289 289 <x:ref>message-header</x:ref> = <message-header, defined in &message-headers;> 290 290 </artwork></figure> -
draft-ietf-httpbis/latest-roy/p4-conditional.html
r345 r348 473 473 <tr> 474 474 <td class="header left"></td> 475 <td class="header right">November 1 1, 2008</td>475 <td class="header right">November 12, 2008</td> 476 476 </tr> 477 477 </table> -
draft-ietf-httpbis/latest-roy/p5-range.html
r345 r348 473 473 <tr> 474 474 <td class="header left"></td> 475 <td class="header right">November 1 1, 2008</td>475 <td class="header right">November 12, 2008</td> 476 476 </tr> 477 477 </table> -
draft-ietf-httpbis/latest-roy/p6-cache.html
r345 r348 403 403 <meta name="DC.Date.Issued" scheme="ISO8601" content="2008-11"> 404 404 <meta name="DC.Relation.Replaces" content="urn:ietf:rfc:2616"> 405 <meta name="DC.Description.Abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990.This document is Part 6 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 6 defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.">405 <meta name="DC.Description.Abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. This document is Part 6 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 6 defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages."> 406 406 </head> 407 407 <body> … … 485 485 <tr> 486 486 <td class="header left"></td> 487 <td class="header right">November 1 1, 2008</td>487 <td class="header right">November 12, 2008</td> 488 488 </tr> 489 489 </table> … … 508 508 <h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1> 509 509 <p>The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information 510 systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 6 of the 511 seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 512 6 defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response 513 messages. 510 systems. This document is Part 6 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, 511 taken together, obsoletes RFC 2616. Part 6 defines requirements on HTTP caches and the associated header fields that control 512 cache behavior or indicate cacheable response messages. 514 513 </p> 515 514 <h1 id="rfc.note.1"><a href="#rfc.note.1">Editorial Note (To be removed by RFC Editor)</a></h1> … … 610 609 </ul> 611 610 <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a> <a id="caching" href="#caching">Introduction</a></h1> 612 <p id="rfc.section.1.p.1">HTTP is typically used for distributed information systems, where performance can be improved by the use of response caches, 613 and includes a number of elements intended to make caching work as well as possible. Because these elements interact with 614 each other, it is useful to describe the caching design of HTTP separately. This document defines aspects of HTTP/1.1 related 615 to caching and reusing response messages. 611 <p id="rfc.section.1.p.1">HTTP is typically used for distributed information systems, where performance can be improved by the use of response caches. 612 This document defines aspects of HTTP/1.1 related to caching and reusing response messages. 616 613 </p> 617 614 <div id="rfc.iref.c.1"></div> … … 729 726 <div id="rfc.figure.u.3"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">field-name</a> = <field-name, defined in <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#message.headers" title="Message Headers">Section 4.2</a>> 730 727 <a href="#abnf.dependencies" class="smpl">HTTP-date</a> = <HTTP-date, defined in <a href="#Part1" id="rfc.xref.Part1.9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#full.date" title="Full Date">Section 3.2.1</a>> 731 <a href="#abnf.dependencies" class="smpl">port</a> = <port, defined in <a href="#Part1" id="rfc.xref.Part1.10"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html# general.syntax" title="ERROR: Anchor 'general.syntax' not found in p1-messaging.xml.">Appendix ERROR: Anchor 'general.syntax' not found in p1-messaging.xml.</a>>728 <a href="#abnf.dependencies" class="smpl">port</a> = <port, defined in <a href="#Part1" id="rfc.xref.Part1.10"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.1</a>> 732 729 <a href="#abnf.dependencies" class="smpl">pseudonym</a> = <pseudonym, defined in <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.via" title="Via">Section 8.9</a>> 733 <a href="#abnf.dependencies" class="smpl">uri-host</a> = <uri-host, defined in <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html# general.syntax" title="ERROR: Anchor 'general.syntax' not found in p1-messaging.xml.">Appendix ERROR: Anchor 'general.syntax' not found in p1-messaging.xml.</a>>730 <a href="#abnf.dependencies" class="smpl">uri-host</a> = <uri-host, defined in <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.1</a>> 734 731 </pre><h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a id="caching.overview" href="#caching.overview">Overview</a></h1> 735 732 <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a> <a id="cache.correctness" href="#cache.correctness">Cache Correctness</a></h2> … … 756 753 <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a> <a id="warnings" href="#warnings">Warnings</a></h2> 757 754 <p id="rfc.section.3.2.p.1">Whenever a cache returns a response that is neither first-hand nor "fresh enough" (in the sense of condition 2 in <a href="#cache.correctness" title="Cache Correctness">Section 3.1</a>), it <em class="bcp14">MUST</em> attach a warning to that effect, using a Warning general-header. The Warning header and the currently defined warnings are 758 described in <a href="#header.warning" id="rfc.xref.header.warning.2" title="Warning">Section 16.6</a>. The warning allows clients to take appropriate action. 759 </p> 760 <p id="rfc.section.3.2.p.2">Warnings <em class="bcp14">MAY</em> be used for other purposes, both cache-related and otherwise. The use of a warning, rather than an error status code, distinguish 761 these responses from true failures. 762 </p> 763 <p id="rfc.section.3.2.p.3">Warnings are assigned three digit warn-codes. The first digit indicates whether the Warning <em class="bcp14">MUST</em> or <em class="bcp14">MUST NOT</em> be deleted from a stored cache entry after a successful revalidation: 764 </p> 765 <p id="rfc.section.3.2.p.4"> </p> 766 <dl> 767 <dt>1xx</dt> 768 <dd>Warnings that describe the freshness or revalidation status of the response, and so <em class="bcp14">MUST</em> be deleted after a successful revalidation. 1xx warn-codes <em class="bcp14">MAY</em> be generated by a cache only when validating a cached entry. It <em class="bcp14">MUST NOT</em> be generated by clients. 769 </dd> 770 <dt>2xx</dt> 771 <dd>Warnings that describe some aspect of the entity body or entity headers that is not rectified by a revalidation (for example, 772 a lossy compression of the entity bodies) and which <em class="bcp14">MUST NOT</em> be deleted after a successful revalidation. 773 </dd> 774 </dl> 775 <p id="rfc.section.3.2.p.5">See <a href="#header.warning" id="rfc.xref.header.warning.3" title="Warning">Section 16.6</a> for the definitions of the codes themselves. 776 </p> 777 <p id="rfc.section.3.2.p.6">HTTP/1.0 caches will cache all Warnings in responses, without deleting the ones in the first category. Warnings in responses 778 that are passed to HTTP/1.0 caches carry an extra warning-date field, which prevents a future HTTP/1.1 recipient from believing 779 an erroneously cached Warning. 780 </p> 781 <p id="rfc.section.3.2.p.7">Warnings also carry a warning text. The text <em class="bcp14">MAY</em> be in any appropriate natural language (perhaps based on the client's Accept headers), and include an <em class="bcp14">OPTIONAL</em> indication of what character set is used. 782 </p> 783 <p id="rfc.section.3.2.p.8">Multiple warnings <em class="bcp14">MAY</em> be attached to a response (either by the origin server or by a cache), including multiple warnings with the same code number. 784 For example, a server might provide the same warning with texts in both English and Basque. 785 </p> 786 <p id="rfc.section.3.2.p.9">When multiple warnings are attached to a response, it might not be practical or reasonable to display all of them to the user. 787 This version of HTTP does not specify strict priority rules for deciding which warnings to display and in what order, but 788 does suggest some heuristics. 755 described in <a href="#header.warning" id="rfc.xref.header.warning.2" title="Warning">Section 16.6</a>. 789 756 </p> 790 757 <h2 id="rfc.section.3.3"><a href="#rfc.section.3.3">3.3</a> <a id="cache-control.mechanisms" href="#cache-control.mechanisms">Cache-control Mechanisms</a></h2> … … 1072 1039 <li>Content-Type</li> 1073 1040 </ul> 1074 <p id="rfc.section.7.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. 4" title="Warning">Section 16.6</a>).1041 <p id="rfc.section.7.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.3" title="Warning">Section 16.6</a>). 1075 1042 </p> 1076 1043 <dl class="empty"> … … 1091 1058 <p id="rfc.section.7.3.p.3">The end-to-end headers stored in the cache entry are used for the constructed response, except that </p> 1092 1059 <ul> 1093 <li>any stored Warning headers with warn-code 1xx (see <a href="#header.warning" id="rfc.xref.header.warning. 5" title="Warning">Section 16.6</a>) <em class="bcp14">MUST</em> be deleted from the cache entry and the forwarded response.1060 <li>any stored Warning headers with warn-code 1xx (see <a href="#header.warning" id="rfc.xref.header.warning.4" title="Warning">Section 16.6</a>) <em class="bcp14">MUST</em> be deleted from the cache entry and the forwarded response. 1094 1061 </li> 1095 1062 <li>any stored Warning headers with warn-code 2xx <em class="bcp14">MUST</em> be retained in the cache entry and the forwarded response. … … 1649 1616 from caching operations or transformations applied to the entity body of the message. 1650 1617 </p> 1651 <p id="rfc.section.16.6.p.2">Warning headers are sent with responses using:</p> 1618 <p id="rfc.section.16.6.p.2">Warnings MAY be used for other purposes, both cache-related and otherwise. The use of a warning, rather than an error status 1619 code, distinguish these responses from true failures. 1620 </p> 1621 <p id="rfc.section.16.6.p.3">Warning headers can in general be applied to any message, however some warn-codes are specific to caches and can only be applied 1622 to response messages. 1623 </p> 1652 1624 <div id="rfc.figure.u.20"></div><pre class="inline"><span id="rfc.iref.g.14"></span><span id="rfc.iref.g.15"></span><span id="rfc.iref.g.16"></span><span id="rfc.iref.g.17"></span><span id="rfc.iref.g.18"></span><span id="rfc.iref.g.19"></span> <a href="#header.warning" class="smpl">Warning</a> = "Warning" ":" 1#<a href="#header.warning" class="smpl">warning-value</a> 1653 1625 … … 1661 1633 <a href="#header.warning" class="smpl">warn-text</a> = <a href="#notation" class="smpl">quoted-string</a> 1662 1634 <a href="#header.warning" class="smpl">warn-date</a> = <a href="#notation" class="smpl">DQUOTE</a> <a href="#abnf.dependencies" class="smpl">HTTP-date</a> <a href="#notation" class="smpl">DQUOTE</a> 1663 </pre><p id="rfc.section.16.6.p.4">A response <em class="bcp14">MAY</em> carry more than one Warning header. 1664 </p> 1665 <p id="rfc.section.16.6.p.5">The warn-text <em class="bcp14">SHOULD</em> be in a natural language and character set that is most likely to be intelligible to the human user receiving the response. 1666 This decision <em class="bcp14">MAY</em> be based on any available knowledge, such as the location of the cache or user, the Accept-Language field in a request, the 1667 Content-Language field in a response, etc. The default language is English and the default character set is ISO-8859-1 (<a href="#ISO-8859-1" id="rfc.xref.ISO-8859-1.1"><cite title="Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1">[ISO-8859-1]</cite></a>). 1668 </p> 1669 <p id="rfc.section.16.6.p.6">If a character set other than ISO-8859-1 is used, it <em class="bcp14">MUST</em> be encoded in the warn-text using the method described in <a href="#RFC2047" id="rfc.xref.RFC2047.1"><cite title="MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text">[RFC2047]</cite></a>. 1670 </p> 1671 <p id="rfc.section.16.6.p.7">Warning headers can in general be applied to any message, however some specific warn-codes are specific to caches and can 1672 only be applied to response messages. New Warning headers <em class="bcp14">SHOULD</em> be added after any existing Warning headers. A cache <em class="bcp14">MUST NOT</em> delete any Warning header that it received with a message. However, if a cache successfully validates a cache entry, it <em class="bcp14">SHOULD</em> remove any Warning headers previously attached to that entry except as specified for specific Warning codes. It <em class="bcp14">MUST</em> then add any Warning headers received in the validating response. In other words, Warning headers are those that would be 1673 attached to the most recent relevant response. 1674 </p> 1675 <p id="rfc.section.16.6.p.8">When multiple Warning headers are attached to a response, the user agent ought to inform the user of as many of them as possible, 1676 in the order that they appear in the response. If it is not possible to inform the user of all of the warnings, the user agent <em class="bcp14">SHOULD</em> follow these heuristics: 1635 </pre><p id="rfc.section.16.6.p.5">Multiple warnings <em class="bcp14">MAY</em> be attached to a response (either by the origin server or by a cache), including multiple warnings with the same code number. 1636 For example, a server might provide the same warning with texts in both English and Basque. 1637 </p> 1638 <p id="rfc.section.16.6.p.6">When this occurs, the user agent ought to inform the user of as many of them as possible, in the order that they appear in 1639 the response. If it is not possible to inform the user of all of the warnings, the user agent SHOULD follow these heuristics: 1677 1640 </p> 1678 1641 <ul> … … 1682 1645 </li> 1683 1646 </ul> 1684 <p id="rfc.section.16.6.p.9">Systems that generate multiple Warning headers <em class="bcp14">SHOULD</em> order them with this user agent behavior in mind. 1685 </p> 1686 <p id="rfc.section.16.6.p.10">Requirements for the behavior of caches with respect to Warnings are stated in <a href="#warnings" title="Warnings">Section 3.2</a>. 1687 </p> 1688 <p id="rfc.section.16.6.p.11">This is a list of the currently-defined warn-codes, each with a recommended warn-text in English, and a description of its 1689 meaning. 1690 </p> 1691 <p id="rfc.section.16.6.p.12">110 Response is stale </p> 1647 <p id="rfc.section.16.6.p.7">Systems that generate multiple Warning headers <em class="bcp14">SHOULD</em> order them with this user agent behavior in mind. New Warning headers <em class="bcp14">SHOULD</em> be added after any existing Warning headers. 1648 </p> 1649 <p id="rfc.section.16.6.p.8">Warnings are assigned three digit warn-codes. The first digit indicates whether the Warning is required to be deleted from 1650 a stored cache entry after validation: 1651 </p> 1652 <ul> 1653 <li>1xx Warnings that describe the freshness or revalidation status of the response, and so MUST be deleted by caches after validation.</li> 1654 <li>2xx Warnings that describe some aspect of the entity body or entity headers that is not rectified by a revalidation (for example, 1655 a lossy compression of the entity bodies) and which MUST NOT be deleted by caches after validation, unless a full response 1656 is returned, in which case they MUST be. 1657 </li> 1658 </ul> 1659 <p id="rfc.section.16.6.p.9">The warn-text <em class="bcp14">SHOULD</em> be in a natural language and character set that is most likely to be intelligible to the human user receiving the response. 1660 This decision <em class="bcp14">MAY</em> be based on any available knowledge, such as the location of the cache or user, the Accept-Language field in a request, the 1661 Content-Language field in a response, etc. The default language is English and the default character set is ISO-8859-1 (<a href="#ISO-8859-1" id="rfc.xref.ISO-8859-1.1"><cite title="Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1">[ISO-8859-1]</cite></a>). 1662 </p> 1663 <p id="rfc.section.16.6.p.10">If a character set other than ISO-8859-1 is used, it <em class="bcp14">MUST</em> be encoded in the warn-text using the method described in <a href="#RFC2047" id="rfc.xref.RFC2047.1"><cite title="MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text">[RFC2047]</cite></a>. 1664 </p> 1665 <p id="rfc.section.16.6.p.11">If an implementation sends a message with one or more Warning headers to a receiver whose version is HTTP/1.0 or lower, then 1666 the sender <em class="bcp14">MUST</em> include in each warning-value a warn-date that matches the Date header in the message. 1667 </p> 1668 <p id="rfc.section.16.6.p.12">If an implementation receives a message with a warning-value that includes a warn-date, and that warn-date is different from 1669 the Date value in the response, then that warning-value <em class="bcp14">MUST</em> be deleted from the message before storing, forwarding, or using it. (This prevents bad consequences of naive caching of Warning 1670 header fields.) If all of the warning-values are deleted for this reason, the Warning header <em class="bcp14">MUST</em> be deleted as well. 1671 </p> 1672 <p id="rfc.section.16.6.p.13">The following warn-codes are defined by this specification, each with a recommended warn-text in English, and a description 1673 of its meaning. 1674 </p> 1675 <p id="rfc.section.16.6.p.14">110 Response is stale </p> 1692 1676 <dl class="empty"> 1693 1677 <dd> <em class="bcp14">MUST</em> be included whenever the returned response is stale. 1694 1678 </dd> 1695 1679 </dl> 1696 <p id="rfc.section.16.6.p.1 3">111 Revalidation failed </p>1680 <p id="rfc.section.16.6.p.15">111 Revalidation failed </p> 1697 1681 <dl class="empty"> 1698 1682 <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 inability … … 1700 1684 </dd> 1701 1685 </dl> 1702 <p id="rfc.section.16.6.p.1 4">112 Disconnected operation </p>1686 <p id="rfc.section.16.6.p.16">112 Disconnected operation </p> 1703 1687 <dl class="empty"> 1704 1688 <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. 1705 1689 </dd> 1706 1690 </dl> 1707 <p id="rfc.section.16.6.p.1 5">113 Heuristic expiration </p>1691 <p id="rfc.section.16.6.p.17">113 Heuristic expiration </p> 1708 1692 <dl class="empty"> 1709 1693 <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 greater … … 1711 1695 </dd> 1712 1696 </dl> 1713 <p id="rfc.section.16.6.p.1 6">199 Miscellaneous warning </p>1697 <p id="rfc.section.16.6.p.18">199 Miscellaneous warning </p> 1714 1698 <dl class="empty"> 1715 1699 <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. 1716 1700 </dd> 1717 1701 </dl> 1718 <p id="rfc.section.16.6.p.1 7">214 Transformation applied </p>1702 <p id="rfc.section.16.6.p.19">214 Transformation applied </p> 1719 1703 <dl class="empty"> 1720 1704 <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 the … … 1723 1707 </dd> 1724 1708 </dl> 1725 <p id="rfc.section.16.6.p. 18">299 Miscellaneous persistent warning </p>1709 <p id="rfc.section.16.6.p.20">299 Miscellaneous persistent warning </p> 1726 1710 <dl class="empty"> 1727 1711 <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. 1728 1712 </dd> 1729 1713 </dl> 1730 <p id="rfc.section.16.6.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.1731 </p>1732 <p id="rfc.section.16.6.p.20">If an implementation receives a message with a warning-value that includes a warn-date, and that warn-date is different from1733 the Date value in the response, then that warning-value <em class="bcp14">MUST</em> be deleted from the message before storing, forwarding, or using it. (This prevents bad consequences of naive caching of Warning1734 header fields.) If all of the warning-values are deleted for this reason, the Warning header <em class="bcp14">MUST</em> be deleted as well.1735 </p>1736 1714 <h1 id="rfc.section.17"><a href="#rfc.section.17">17.</a> <a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1> 1737 1715 <h2 id="rfc.section.17.1"><a href="#rfc.section.17.1">17.1</a> <a id="message.header.registration" href="#message.header.registration">Message Header Registration</a></h2> … … 1789 1767 <td>http</td> 1790 1768 <td>standard</td> 1791 <td> <a href="#header.warning" id="rfc.xref.header.warning. 6" title="Warning">Section 16.6</a>1769 <td> <a href="#header.warning" id="rfc.xref.header.warning.5" title="Warning">Section 16.6</a> 1792 1770 </td> 1793 1771 </tr> … … 1909 1887 <p id="rfc.section.A.1.p.5">The Cache-Control: max-age directive was not properly defined for responses. (<a href="#modifications.of.the.basic.expiration.mechanism" title="Modifications of the Basic Expiration Mechanism">Section 16.2.3</a>) 1910 1888 </p> 1911 <p id="rfc.section.A.1.p.6">Warnings could be cached incorrectly, or not updated appropriately. (Section <a href="#warnings" title="Warnings">3.2</a>, <a href="#expiration.calculations" title="Expiration Calculations">4.4</a>, <a href="#non-modifiable.headers" title="Non-modifiable Headers">7.2</a>, <a href="#combining.headers" title="Combining Headers">7.3</a>, <a href="#modifications.of.the.basic.expiration.mechanism" title="Modifications of the Basic Expiration Mechanism">16.2.3</a>, and <a href="#header.warning" id="rfc.xref.header.warning. 7" title="Warning">16.6</a>) Warning also needed to be a general header, as PUT or other methods may have need for it in requests.1889 <p id="rfc.section.A.1.p.6">Warnings could be cached incorrectly, or not updated appropriately. (Section <a href="#warnings" title="Warnings">3.2</a>, <a href="#expiration.calculations" title="Expiration Calculations">4.4</a>, <a href="#non-modifiable.headers" title="Non-modifiable Headers">7.2</a>, <a href="#combining.headers" title="Combining Headers">7.3</a>, <a href="#modifications.of.the.basic.expiration.mechanism" title="Modifications of the Basic Expiration Mechanism">16.2.3</a>, and <a href="#header.warning" id="rfc.xref.header.warning.6" title="Warning">16.6</a>) Warning also needed to be a general header, as PUT or other methods may have need for it in requests. 1912 1890 </p> 1913 1891 <h2 id="rfc.section.A.2"><a href="#rfc.section.A.2">A.2</a> <a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h2> … … 2079 2057 <li class="indline1">Pragma <a class="iref" href="#rfc.xref.header.pragma.1">16.2</a>, <a class="iref" href="#rfc.iref.h.5"><b>16.4</b></a>, <a class="iref" href="#rfc.xref.header.pragma.2">17.1</a></li> 2080 2058 <li class="indline1">Vary <a class="iref" href="#rfc.xref.header.vary.1">8</a>, <a class="iref" href="#rfc.iref.h.6"><b>16.5</b></a>, <a class="iref" href="#rfc.xref.header.vary.2">17.1</a></li> 2081 <li class="indline1">Warning <a class="iref" href="#rfc.xref.header.warning.1">3.1</a>, <a class="iref" href="#rfc.xref.header.warning.2">3.2</a>, <a class="iref" href="#rfc.xref.header.warning.3"> 3.2</a>, <a class="iref" href="#rfc.xref.header.warning.4">7.2</a>, <a class="iref" href="#rfc.xref.header.warning.5">7.3</a>, <a class="iref" href="#rfc.iref.h.7"><b>16.6</b></a>, <a class="iref" href="#rfc.xref.header.warning.6">17.1</a>, <a class="iref" href="#rfc.xref.header.warning.7">A.1</a></li>2059 <li class="indline1">Warning <a class="iref" href="#rfc.xref.header.warning.1">3.1</a>, <a class="iref" href="#rfc.xref.header.warning.2">3.2</a>, <a class="iref" href="#rfc.xref.header.warning.3">7.2</a>, <a class="iref" href="#rfc.xref.header.warning.4">7.3</a>, <a class="iref" href="#rfc.iref.h.7"><b>16.6</b></a>, <a class="iref" href="#rfc.xref.header.warning.5">17.1</a>, <a class="iref" href="#rfc.xref.header.warning.6">A.1</a></li> 2082 2060 </ul> 2083 2061 </li> … … 2140 2118 <li class="indline0"><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul class="ind"> 2141 2119 <li class="indline1"><em>Part1</em> <a class="iref" href="#rfc.xref.Part1.1">2</a>, <a class="iref" href="#rfc.xref.Part1.2">2</a>, <a class="iref" href="#rfc.xref.Part1.3">2</a>, <a class="iref" href="#rfc.xref.Part1.4">2</a>, <a class="iref" href="#rfc.xref.Part1.5">2</a>, <a class="iref" href="#rfc.xref.Part1.6">2</a>, <a class="iref" href="#rfc.xref.Part1.7">2</a>, <a class="iref" href="#rfc.xref.Part1.8">2</a>, <a class="iref" href="#rfc.xref.Part1.9">2</a>, <a class="iref" href="#rfc.xref.Part1.10">2</a>, <a class="iref" href="#rfc.xref.Part1.11">2</a>, <a class="iref" href="#rfc.xref.Part1.12">2</a>, <a class="iref" href="#rfc.xref.Part1.13">4.3</a>, <a class="iref" href="#rfc.xref.Part1.14">7.1</a>, <a class="iref" href="#rfc.xref.Part1.15">7.2</a>, <a class="iref" href="#rfc.xref.Part1.16">7.2</a>, <a class="iref" href="#rfc.xref.Part1.17">8</a>, <a class="iref" href="#rfc.xref.Part1.18">16.3</a>, <a class="iref" href="#Part1"><b>20.1</b></a>, <a class="iref" href="#rfc.xref.Part1.19">A.1</a><ul class="ind"> 2142 <li class="indline1"><em>Appendix </em> <a class="iref" href="#rfc.xref.Part1.10">2</a>, <a class="iref" href="#rfc.xref.Part1.12">2</a></li>2143 2120 <li class="indline1"><em>Section 1.2.1</em> <a class="iref" href="#rfc.xref.Part1.1">2</a></li> 2144 2121 <li class="indline1"><em>Section 1.2.2</em> <a class="iref" href="#rfc.xref.Part1.2">2</a>, <a class="iref" href="#rfc.xref.Part1.3">2</a>, <a class="iref" href="#rfc.xref.Part1.4">2</a>, <a class="iref" href="#rfc.xref.Part1.5">2</a>, <a class="iref" href="#rfc.xref.Part1.6">2</a>, <a class="iref" href="#rfc.xref.Part1.7">2</a></li> 2122 <li class="indline1"><em>Section 2.1</em> <a class="iref" href="#rfc.xref.Part1.10">2</a>, <a class="iref" href="#rfc.xref.Part1.12">2</a></li> 2145 2123 <li class="indline1"><em>Section 3.2.1</em> <a class="iref" href="#rfc.xref.Part1.9">2</a>, <a class="iref" href="#rfc.xref.Part1.18">16.3</a></li> 2146 2124 <li class="indline1"><em>Section 4.2</em> <a class="iref" href="#rfc.xref.Part1.8">2</a>, <a class="iref" href="#rfc.xref.Part1.17">8</a></li> … … 2211 2189 </li> 2212 2190 <li class="indline0"><a id="rfc.index.W" href="#rfc.index.W"><b>W</b></a><ul class="ind"> 2213 <li class="indline1">Warning header <a class="iref" href="#rfc.xref.header.warning.1">3.1</a>, <a class="iref" href="#rfc.xref.header.warning.2">3.2</a>, <a class="iref" href="#rfc.xref.header.warning.3"> 3.2</a>, <a class="iref" href="#rfc.xref.header.warning.4">7.2</a>, <a class="iref" href="#rfc.xref.header.warning.5">7.3</a>, <a class="iref" href="#rfc.iref.w.1"><b>16.6</b></a>, <a class="iref" href="#rfc.xref.header.warning.6">17.1</a>, <a class="iref" href="#rfc.xref.header.warning.7">A.1</a></li>2191 <li class="indline1">Warning header <a class="iref" href="#rfc.xref.header.warning.1">3.1</a>, <a class="iref" href="#rfc.xref.header.warning.2">3.2</a>, <a class="iref" href="#rfc.xref.header.warning.3">7.2</a>, <a class="iref" href="#rfc.xref.header.warning.4">7.3</a>, <a class="iref" href="#rfc.iref.w.1"><b>16.6</b></a>, <a class="iref" href="#rfc.xref.header.warning.5">17.1</a>, <a class="iref" href="#rfc.xref.header.warning.6">A.1</a></li> 2214 2192 </ul> 2215 2193 </li> -
draft-ietf-httpbis/latest-roy/p6-cache.xml
r347 r348 17 17 <!ENTITY notation-abnf "<xref target='Part1' x:rel='#notation.abnf' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 18 18 <!ENTITY basic-rules "<xref target='Part1' x:rel='#basic.rules' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 19 <!ENTITY general-syntax "<xref target='Part1' x:rel='#general.syntax' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">19 <!ENTITY uri "<xref target='Part1' x:rel='#uri' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 20 20 <!ENTITY messaging "<xref target='Part1' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 21 21 <!ENTITY conditional "<xref target='Part4' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> … … 454 454 <x:ref>field-name</x:ref> = <field-name, defined in &message-headers;> 455 455 <x:ref>HTTP-date</x:ref> = <HTTP-date, defined in &full-date;> 456 <x:ref>port</x:ref> = <port, defined in & general-syntax;>456 <x:ref>port</x:ref> = <port, defined in &uri;> 457 457 <x:ref>pseudonym</x:ref> = <pseudonym, defined in &header-via;> 458 <x:ref>uri-host</x:ref> = <uri-host, defined in & general-syntax;>458 <x:ref>uri-host</x:ref> = <uri-host, defined in &uri;> 459 459 </artwork></figure> 460 460 </section> -
draft-ietf-httpbis/latest-roy/p7-auth.html
r345 r348 471 471 <tr> 472 472 <td class="header left"></td> 473 <td class="header right">November 1 1, 2008</td>473 <td class="header right">November 12, 2008</td> 474 474 </tr> 475 475 </table>
Note: See TracChangeset
for help on using the changeset viewer.