Ignore:
Timestamp:
Aug 4, 2010, 8:03:20 AM (9 years ago)
Author:
julian.reschke@…
Message:

regen HTML using latest version of xslt

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/orig/rfc2616-symrefs.html

    r598 r978  
    3737}
    3838
    39 dl.empty dd {
     39ul.empty {
     40  list-style-type: none;
     41}
     42ul.empty li {
    4043  margin-top: .5em;
    4144}
     
    118121}
    119122table.header {
     123  border-spacing: 1px;
    120124  width: 95%;
    121125  font-size: 10pt;
     
    129133  white-space: nowrap;
    130134}
    131 td.header {
     135table.header td {
    132136  background-color: gray;
    133137  width: 50%;
    134138}
    135 td.header a {
     139table.header a {
    136140  color: white;
    137141}
     
    188192  margin-left: 0em;
    189193  margin-right: 0em;
     194}
     195.avoidbreak {
     196  page-break-inside: avoid;
    190197}
    191198.bcp14 {
     
    285292@page {
    286293  @top-left {
    287        content: "INTERNET DRAFT";
     294       content: "Internet-Draft";
    288295  }
    289296  @top-right {
     
    338345      <link rel="Appendix" title="19 Appendices" href="#rfc.section.19">
    339346      <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 &#34;HTTP/1.1&#34;, 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 &#34;HTTP/1.1&#34;, 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 &#34;HTTP/1.1&#34;, and is an update to RFC 2068 .">
    353361   </head>
    354362   <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                &lt;rfc2616-symrefs&gt;
    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>
    420427      </table>
    421428      <p class="title">Hypertext Transfer Protocol -- HTTP/1.1<br><span class="filename">rfc2616-symrefs</span></p>
     
    432439         in progress”.
    433440      </p>
    434       <p>The list of current Internet-Drafts can be accessed at &lt;<a href="http://www.ietf.org/ietf/1id-abstracts.txt">http://www.ietf.org/ietf/1id-abstracts.txt</a>&gt;.
    435       </p>
    436       <p>The list of Internet-Draft Shadow Directories can be accessed at &lt;<a href="http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html</a>&gt;.
     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>.
    437444      </p>
    438445      <p>This Internet-Draft will expire in December 1999.</p>
     
    801808         </li>
    802809         <li class="tocline0">20.&nbsp;&nbsp;&nbsp;<a href="#rfc.section.20">Index</a></li>
     810         <li class="tocline0"><a href="#rfc.index">Index</a></li>
    803811         <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>
    805812      </ul>
    806813      <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<a id="introduction" href="#introduction">Introduction</a></h1>
     
    834841      <p id="rfc.section.1.3.p.2"> <span id="rfc.iref.c.1"></span>  <dfn>connection</dfn> 
    835842      </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>
    839846      <p id="rfc.section.1.3.p.3"> <span id="rfc.iref.m.1"></span>  <dfn>message</dfn> 
    840847      </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&nbsp;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&nbsp;4</a> and transmitted via the connection.
     850         </li>
     851      </ul>
    845852      <p id="rfc.section.1.3.p.4"> <span id="rfc.iref.r.1"></span>  <dfn>request</dfn> 
    846853      </p>
    847       <dl class="empty">
    848          <dd>An HTTP request message, as defined in <a href="#request" title="Request">Section&nbsp;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&nbsp;5</a>.
     856         </li>
     857      </ul>
    851858      <p id="rfc.section.1.3.p.5"> <span id="rfc.iref.r.2"></span>  <dfn>response</dfn> 
    852859      </p>
    853       <dl class="empty">
    854          <dd>An HTTP response message, as defined in <a href="#response" title="Response">Section&nbsp;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&nbsp;6</a>.
     862         </li>
     863      </ul>
    857864      <p id="rfc.section.1.3.p.6"> <span id="rfc.iref.r.3"></span>  <dfn>resource</dfn> 
    858865      </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&nbsp;3.2</a>. Resources may be available in multiple representations (e.g. multiple languages, data formats, size, and resolutions) or
     866      <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&nbsp;3.2</a>. Resources may be available in multiple representations (e.g. multiple languages, data formats, size, and resolutions) or
    861868            vary in other ways.
    862          </dd>
    863       </dl>
     869         </li>
     870      </ul>
    864871      <p id="rfc.section.1.3.p.7"> <span id="rfc.iref.e.1"></span>  <dfn>entity</dfn> 
    865872      </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 of
     873      <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
    868875            entity-header fields and content in the form of an entity-body, as described in <a href="#entity" title="Entity">Section&nbsp;7</a>.
    869          </dd>
    870       </dl>
     876         </li>
     877      </ul>
    871878      <p id="rfc.section.1.3.p.8"> <span id="rfc.iref.r.4"></span>  <dfn>representation</dfn> 
    872879      </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&nbsp;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&nbsp;12</a>. There may exist multiple representations associated with a particular response status.
     882         </li>
     883      </ul>
    877884      <p id="rfc.section.1.3.p.9"> <span id="rfc.iref.c.2"></span>  <dfn>content negotiation</dfn> 
    878885      </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&nbsp;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&nbsp;12</a>. The representation of entities in any response can be negotiated (including error responses).
     888         </li>
     889      </ul>
    883890      <p id="rfc.section.1.3.p.10"> <span id="rfc.iref.v.1"></span>  <dfn>variant</dfn> 
    884891      </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 representations
     892      <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
    887894            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>
    890897      <p id="rfc.section.1.3.p.11"> <span id="rfc.iref.c.3"></span>  <dfn>client</dfn> 
    891898      </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>
    895902      <p id="rfc.section.1.3.p.12"> <span id="rfc.iref.u.1"></span>  <dfn>user agent</dfn> 
    896903      </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 user
     904      <ul class="empty">
     905         <li>The client which initiates a request. These are often browsers, editors, spiders (web-traversing robots), or other end user
    899906            tools.
    900          </dd>
    901       </dl>
     907         </li>
     908      </ul>
    902909      <p id="rfc.section.1.3.p.13"> <span id="rfc.iref.s.1"></span>  <dfn>server</dfn> 
    903910      </p>
    904       <dl class="empty">
    905          <dd>An application program that accepts connections in order to service requests by sending back responses. Any given program
     911      <ul class="empty">
     912         <li>An application program that accepts connections in order to service requests by sending back responses. Any given program
    906913            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
    907914            program for a particular connection, rather than to the program's capabilities in general. Likewise, any server may act as
    908915            an origin server, proxy, gateway, or tunnel, switching behavior based on the nature of each request.
    909          </dd>
    910       </dl>
     916         </li>
     917      </ul>
    911918      <p id="rfc.section.1.3.p.14"> <span id="rfc.iref.o.1"></span>  <dfn>origin server</dfn> 
    912919      </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>
    916923      <p id="rfc.section.1.3.p.15"> <span id="rfc.iref.p.1"></span>  <dfn>proxy</dfn> 
    917924      </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.
    920927            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
    921928            the request or response beyond what is required for proxy authentication and identification. A "non-transparent proxy" is
     
    923930            services, media type transformation, protocol reduction, or anonymity filtering. Except where either transparent or non-transparent
    924931            behavior is explicitly stated, the HTTP proxy requirements apply to both types of proxies.
    925          </dd>
    926       </dl>
     932         </li>
     933      </ul>
    927934      <p id="rfc.section.1.3.p.16"> <span id="rfc.iref.g.1"></span>  <dfn>gateway</dfn> 
    928935      </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 the
     936      <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
    931938            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>
    934941      <p id="rfc.section.1.3.p.17"> <span id="rfc.iref.t.1"></span>  <dfn>tunnel</dfn> 
    935942      </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 considered
     943      <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
    938945            a party to the HTTP communication, though the tunnel may have been initiated by an HTTP request. The tunnel ceases to exist
    939946            when both ends of the relayed connections are closed.
    940          </dd>
    941       </dl>
     947         </li>
     948      </ul>
    942949      <p id="rfc.section.1.3.p.18"> <span id="rfc.iref.c.4"></span>  <dfn>cache</dfn> 
    943950      </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.
    946953            A cache stores cacheable responses in order to reduce the response time and network bandwidth consumption on future, equivalent
    947954            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>
    950957      <p id="rfc.section.1.3.p.19"> <span id="rfc.iref.c.5"></span>  <dfn>cacheable</dfn> 
    951958      </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.
    954961            The rules for determining the cacheability of HTTP responses are defined in <a href="#caching" title="Caching in HTTP">Section&nbsp;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
    955962            request.
    956          </dd>
    957       </dl>
     963         </li>
     964      </ul>
    958965      <p id="rfc.section.1.3.p.20"> <span id="rfc.iref.f.1"></span>  <dfn>first-hand</dfn> 
    959966      </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 more
     967      <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
    962969            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>
    965972      <p id="rfc.section.1.3.p.21"> <span id="rfc.iref.e.2"></span>  <dfn>explicit expiration time</dfn> 
    966973      </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>
    970977      <p id="rfc.section.1.3.p.22"> <span id="rfc.iref.h.1"></span>  <dfn>heuristic expiration time</dfn> 
    971978      </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>
    975982      <p id="rfc.section.1.3.p.23"> <span id="rfc.iref.a.1"></span>  <dfn>age</dfn> 
    976983      </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>
    980987      <p id="rfc.section.1.3.p.24"> <span id="rfc.iref.f.2"></span>  <dfn>freshness lifetime</dfn> 
    981988      </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>
    985992      <p id="rfc.section.1.3.p.25"> <span id="rfc.iref.f.3"></span>  <dfn>fresh</dfn> 
    986993      </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>
    990997      <p id="rfc.section.1.3.p.26"> <span id="rfc.iref.s.2"></span>  <dfn>stale</dfn> 
    991998      </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>
    9951002      <p id="rfc.section.1.3.p.27"> <span id="rfc.iref.s.3"></span>  <dfn>semantically transparent</dfn> 
    9961003      </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 neither
     1004      <ul class="empty">
     1005         <li>A cache behaves in a "semantically transparent" manner, with respect to a particular response, when its use affects neither
    9991006            the requesting client nor the origin server, except to improve performance. When a cache is semantically transparent, the
    10001007            client receives exactly the same response (except for hop-by-hop headers) that it would have received had its request been
    10011008            handled directly by the origin server.
    1002          </dd>
    1003       </dl>
     1009         </li>
     1010      </ul>
    10041011      <p id="rfc.section.1.3.p.28"> <span id="rfc.iref.v.2"></span>  <dfn>validator</dfn> 
    10051012      </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 equivalent
     1013      <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
    10081015            copy of an entity.
    1009          </dd>
    1010       </dl>
     1016         </li>
     1017      </ul>
    10111018      <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> 
    10121019      </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>
    10161023      <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> 
    10171024      </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",
    10201027            and "outbound" means "traveling toward the user agent"
    1021          </dd>
    1022       </dl>
     1028         </li>
     1029      </ul>
    10231030      <h2 id="rfc.section.1.4"><a href="#rfc.section.1.4">1.4</a>&nbsp;<a id="intro.overall.operation" href="#intro.overall.operation">Overall Operation</a></h2>
    10241031      <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,
     
    10871094      </p>
    10881095      <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 "&lt;" and "&gt;") and is separated from its definition by the
     1096      <ul class="empty">
     1097         <li>The name of a rule is simply the name itself (without any enclosing "&lt;" and "&gt;") and is separated from its definition by the
    10911098            equal "=" character. White space is only significant in that indentation of continuation lines is used to indicate a rule
    10921099            definition that spans more than one line. Certain basic rules are in uppercase, such as SP, LWS, HT, CRLF, DIGIT, ALPHA, etc.
    10931100            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>
    10961103      <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>
    11001107      <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>
    11041111      <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 sequences
     1112      <ul class="empty">
     1113         <li>Elements enclosed in parentheses are treated as a single element. Thus, "(elem (foo | bar) elem)" allows the token sequences
    11071114            "elem foo elem" and "elem bar elem".
    1108          </dd>
    1109       </dl>
     1115         </li>
     1116      </ul>
    11101117      <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 "&lt;n&gt;*&lt;m&gt;element" indicating at least &lt;n&gt; and
     1118      <ul class="empty">
     1119         <li>The character "*" preceding an element indicates repetition. The full form is "&lt;n&gt;*&lt;m&gt;element" indicating at least &lt;n&gt; and
    11131120            at most &lt;m&gt; occurrences of element. Default values are 0 and infinity so that "*(element)" allows any number, including zero;
    11141121            "1*element" requires at least one; and "1*2element" allows one or two.
    1115          </dd>
    1116       </dl>
     1122         </li>
     1123      </ul>
    11171124      <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>
    11211128      <p id="rfc.section.2.1.p.8">N rule </p>
    1122       <dl class="empty">
    1123          <dd>Specific repetition: "&lt;n&gt;(element)" is equivalent to "&lt;n&gt;*&lt;n&gt;(element)"; that is, exactly &lt;n&gt; occurrences of (element). Thus
     1129      <ul class="empty">
     1130         <li>Specific repetition: "&lt;n&gt;(element)" is equivalent to "&lt;n&gt;*&lt;n&gt;(element)"; that is, exactly &lt;n&gt; occurrences of (element). Thus
    11241131            2DIGIT is a 2-digit number, and 3ALPHA is a string of three alphabetic characters.
    1125          </dd>
    1126       </dl>
     1132         </li>
     1133      </ul>
    11271134      <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 "&lt;n&gt;#&lt;m&gt;element" indicating at
     1135      <ul class="empty">
     1136         <li>A construct "#" is defined, similar to "*", for defining lists of elements. The full form is "&lt;n&gt;#&lt;m&gt;element" indicating at
    11301137            least &lt;n&gt; and at most &lt;m&gt; 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,
    11361143            "(element), , (element) " is permitted, but counts as only two elements. Therefore, where at least one element is required,
    11371144            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
    11381145            least one; and "1#2element" allows one or two.
    1139          </dd>
    1140       </dl>
     1146         </li>
     1147      </ul>
    11411148      <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 is
     1149      <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
    11441151            a simple way of including useful notes in parallel with the specifications.
    1145          </dd>
    1146       </dl>
     1152         </li>
     1153      </ul>
    11471154      <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 included
     1155      <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
    11501157            between any two adjacent words (token or quoted-string), and between adjacent words and separators, without changing the interpretation
    11511158            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
    11521159            token.
    1153          </dd>
    1154       </dl>
     1160         </li>
     1161      </ul>
    11551162      <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a>&nbsp;<a id="basic.rules" href="#basic.rules">Basic Rules</a></h2>
    11561163      <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
     
    12351242      </p>
    12361243      <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>
    12411248      <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;<a id="uri" href="#uri">Uniform Resource Identifiers</a></h2>
    12421249      <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,
     
    12521259      </p>
    12531260      <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 implementations
     1261      <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
    12561263            might not properly support these lengths.
    1257          </dd>
    1258       </dl>
     1264         </li>
     1265      </ul>
    12591266      <h3 id="rfc.section.3.2.2"><a href="#rfc.section.3.2.2">3.2.2</a>&nbsp;<a id="http.url" href="#http.url">http URL</a></h3>
    12601267      <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
     
    12901297</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&nbsp;19.3</a> for further information.
    12911298      </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,
    12941301            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>
    12971304      <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
    12981305         Universal Time). This is indicated in the first two formats by the inclusion of "GMT" as the three-letter abbreviation for
     
    13361343         to determine the exact mapping is not permitted.
    13371344      </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 MIME
     1345      <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
    13401347            share the same registry, it is important that the terminology also be shared.
    1341          </dd>
    1342       </dl>
     1348         </li>
     1349      </ul>
    13431350      <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
    13441351         Set registry <a href="#RFC1700" id="rfc.xref.RFC1700.2"><cite title="Assigned Numbers">[RFC1700]</cite></a>.
     
    13721379      <p id="rfc.section.3.5.p.5">gzip<span id="rfc.iref.g.40"></span> 
    13731380      </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>
    13781385      <p id="rfc.section.3.5.p.6">compress<span id="rfc.iref.c.6"></span> 
    13791386      </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-Welch
     1387      <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
    13821389            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.
    13851392            Their use here is representative of historical practice, not good design. For compatibility with previous implementations
    13861393            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>
    13891396      <p id="rfc.section.3.5.p.7">deflate<span id="rfc.iref.d.2"></span> 
    13901397      </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>
    13951402      <p id="rfc.section.3.5.p.8">identity<span id="rfc.iref.i.2"></span> 
    13961403      </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-Encoding
     1404      <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
    13991406            header, and <em class="bcp14">SHOULD NOT</em> be used in the Content-Encoding header.
    1400          </dd>
    1401       </dl>
     1407         </li>
     1408      </ul>
    14021409      <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
    14031410         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
     
    15261533         an unrecognized multipart subtype, the application <em class="bcp14">MUST</em> treat it as being equivalent to "multipart/mixed".
    15271534      </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 request
     1535      <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
    15301537            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>
    15331540      <h2 id="rfc.section.3.8"><a href="#rfc.section.3.8">3.8</a>&nbsp;<a id="product.tokens" href="#product.tokens">Product Tokens</a></h2>
    15341541      <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
     
    16861693               can parse multipart/byteranges responses.
    16871694            </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>
    16921699         </li>
    16931700         <li>
     
    17911798      </p>
    17921799      <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 using
     1800      <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
    17951802            a non-reserved URI character for a reserved purpose. Implementors should be aware that some pre-HTTP/1.1 proxies have been
    17961803            known to rewrite the Request-URI.
    1797          </dd>
    1798       </dl>
     1804         </li>
     1805      </ul>
    17991806      <h2 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2</a>&nbsp;<a id="the.resource.identified.by.a.request" href="#the.resource.identified.by.a.request">The Resource Identified by a Request</a></h2>
    18001807      <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>
     
    24842491         GET or HEAD. A client <em class="bcp14">SHOULD</em> detect infinite redirection loops, since such loops generate network traffic for each redirection.
    24852492      </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 that
     2493      <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
    24882495            there might be clients that implement such a fixed limitation.
    2489          </dd>
    2490       </dl>
     2496         </li>
     2497      </ul>
    24912498      <div id="rfc.iref.151"></div>
    24922499      <div id="rfc.iref.s.13"></div>
     
    25132520         the request was issued.
    25142521      </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 erroneously
     2522      <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
    25172524            change it into a GET request.
    2518          </dd>
    2519       </dl>
     2525         </li>
     2526      </ul>
    25202527      <div id="rfc.iref.153"></div>
    25212528      <div id="rfc.iref.s.15"></div>
     
    25302537         the request was issued.
    25312538      </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, most
     2539      <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
    25342541            existing user agent implementations treat 302 as if it were a 303 response, performing a GET on the Location field-value regardless
    25352542            of the original request method. The status codes 303 and 307 have been added for servers that wish to make unambiguously clear
    25362543            which kind of reaction is expected of the client.
    2537          </dd>
    2538       </dl>
     2544         </li>
     2545      </ul>
    25392546      <div id="rfc.iref.154"></div>
    25402547      <div id="rfc.iref.s.16"></div>
     
    25462553      <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).
    25472554      </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, the
     2555      <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
    25502557            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>
    25532560      <div id="rfc.iref.155"></div>
    25542561      <div id="rfc.iref.s.17"></div>
     
    25822589         expected to repeat this single request via the proxy. 305 responses <em class="bcp14">MUST</em> only be generated by origin servers.
    25832590      </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. Not
     2591      <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
    25862593            observing these limitations has significant security consequences.
    2587          </dd>
    2588       </dl>
     2594         </li>
     2595      </ul>
    25892596      <div id="rfc.iref.157"></div>
    25902597      <div id="rfc.iref.s.19"></div>
     
    26602667         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.
    26612668      </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.
    26642671            In some cases, this may even be preferable to sending a 406 response. User agents are encouraged to inspect the headers of
    26652672            an incoming response to determine if it is acceptable.
    2666          </dd>
    2667       </dl>
     2673         </li>
     2674      </ul>
    26682675      <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.
    26692676      </p>
     
    27832790         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.
    27842791      </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 wish
     2792      <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
    27872794            to simply refuse the connection.
    2788          </dd>
    2789       </dl>
     2795         </li>
     2796      </ul>
    27902797      <div id="rfc.iref.181"></div>
    27912798      <div id="rfc.iref.s.43"></div>
     
    27942801         URI (e.g. HTTP, FTP, LDAP) or some other auxiliary server (e.g. DNS) it needed to access in attempting to complete the request.
    27952802      </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>
    28002807      <div id="rfc.iref.182"></div>
    28012808      <div id="rfc.iref.s.44"></div>
     
    28172824         best representation for a given response when there are multiple representations available.
    28182825      </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 different
     2826      <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
    28212828            capabilities of that type, be in different languages, etc.
    2822          </dd>
    2823       </dl>
     2829         </li>
     2830      </ul>
    28242831      <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.
    28252832      </p>
     
    29202927      </ol>
    29212928      <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.
    29242931            If a decision might affect semantic transparency, the implementor ought to err on the side of maintaining transparency unless
    29252932            a careful and complete analysis shows significant benefits in breaking transparency.
    2926          </dd>
    2927       </dl>
     2933         </li>
     2934      </ul>
    29282935      <h2 id="rfc.section.13.1"><a href="#rfc.section.13.1">13.1</a>&nbsp;
    29292936      </h2>
     
    31993206         either that a method be performed if and only if a validator matches or if and only if no validators match.
    32003207      </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 prohibited
     3208      <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
    32033210            by a cache-control directive. However, a cache cannot do a conditional retrieval if it does not have a validator for the entity,
    32043211            which means it will not be refreshable after it expires.
    3205          </dd>
    3206       </dl>
     3212         </li>
     3213      </ul>
    32073214      <h3 id="rfc.section.13.3.1"><a href="#rfc.section.13.3.1">13.3.1</a>&nbsp;<a id="last-modified.dates" href="#last-modified.dates">Last-Modified Dates</a></h3>
    32083215      <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
     
    32313238         entity, while a weak validator is part of an identifier for a set of semantically equivalent entities.
    32323239      </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 possible
     3240      <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
    32373244            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;
    32403247            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
    32413248            that period is likely "good enough" to be equivalent.
    3242          </dd>
    3243       </dl>
     3249         </li>
     3250      </ul>
    32443251      <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,
    32453252         or when a server compares two validators.
     
    33183325      <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.
    33193326      </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 value
     3327      <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
    33223329            for two different entities, or reusing a specific weak entity tag value for two semantically different entities. Cache entries
    33233330            might persist for arbitrarily long periods, regardless of expiration times, so it might be inappropriate to expect that a
    33243331            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>
    33273334      <p id="rfc.section.13.3.4.p.5">HTTP/1.1 clients: </p>
    33283335      <ul>
     
    33453352         fields in the request.
    33463353      </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 information
     3354      <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
    33493356            as is available in their responses and requests. HTTP/1.1 systems receiving this information will make the most conservative
    33503357            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 will
     3358         </li>
     3359         <li>HTTP/1.0 clients and caches will ignore entity tags. Generally, last-modified values received or used by these systems will
    33533360            support transparent and efficient caching, and so HTTP/1.1 origin servers should provide Last-Modified values. In those rare
    33543361            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
    33553362            HTTP/1.1 origin servers should not provide one.
    3356          </dd>
    3357       </dl>
     3363         </li>
     3364      </ul>
    33583365      <h3 id="rfc.section.13.3.5"><a href="#rfc.section.13.3.5">13.3.5</a>&nbsp;<a id="non-validating.conditionals" href="#non-validating.conditionals">Non-validating Conditionals</a></h3>
    33593366      <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
     
    33673374         such a response was taken from a cache by comparing the Date header to the current time.
    33683375      </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>
    33733380      <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
    33743381         request. This might be because absolute semantic transparency is deemed necessary by the service author, or because of security
     
    34423449      <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&nbsp;14.46</a>).
    34433450      </p>
    3444       <dl class="empty">
    3445          <dd>Warning: unnecessary modification of end-to-end headers might cause authentication failures if stronger authentication mechanisms
     3451      <ul class="empty">
     3452         <li>Warning: unnecessary modification of end-to-end headers might cause authentication failures if stronger authentication mechanisms
    34463453            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>
    34493456      <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&nbsp;4.4</a>. A transparent proxy <em class="bcp14">MUST</em> preserve the entity-length (<a href="#entity.length" title="Entity Length">Section&nbsp;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&nbsp;4.4</a>).
    34503457      </p>
     
    34733480         stored with the cache entry (except for stored Warning headers with warn-code 1xx, which are deleted even if not overridden).
    34743481      </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 associated
     3482      <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
    34773484            with a previous response for the same entity or sub-ranges thereof, although it might not always be meaningful or correct
    34783485            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
    34793486            delete a header that it had provided with a previous response.
    3480          </dd>
    3481       </dl>
     3487         </li>
     3488      </ul>
    34823489      <h3 id="rfc.section.13.5.4"><a href="#rfc.section.13.5.4">13.5.4</a>&nbsp;<a id="combining.byte.ranges" href="#combining.byte.ranges">Combining Byte Ranges</a></h3>
    34833490      <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
     
    35893596         to be returned. If it inserts the new response into cache storage the rules in <a href="#combining.headers" title="Combining Headers">Section&nbsp;13.5.3</a> apply.
    35903597      </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>
    35953602      <h2 id="rfc.section.13.13"><a href="#rfc.section.13.13">13.13</a>&nbsp;<a id="history.lists" href="#history.lists">History Lists</a></h2>
    35963603      <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
     
    36043611      </p>
    36053612      <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 authors
     3613      <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
    36083615            to avoid using HTTP expiration controls and cache controls when they would otherwise like to. Service authors may consider
    36093616            it important that users not be presented with error messages or warning messages when they use navigation controls (such as
     
    36113618            user interface considerations may force service authors to resort to other means of preventing caching (e.g. "once-only" URLs)
    36123619            in order not to suffer the effects of improperly functioning history mechanisms.
    3613          </dd>
    3614       </dl>
     3620         </li>
     3621      </ul>
    36153622      <h1 id="rfc.section.14"><a href="#rfc.section.14">14.</a>&nbsp;<a id="header.fields" href="#header.fields">Header Field Definitions</a></h1>
    36163623      <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
     
    36403647         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&nbsp;3.9</a>). The default value is q=1.
    36413648      </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.
    36443651            Although this prevents any media type parameter named "q" from being used with a media range, such an event is believed to
    36453652            be unlikely given the lack of any "q" parameters in the IANA media type registry and the rare usage of any media type parameters
    36463653            in Accept. Future media types are discouraged from registering any parameter named "q".
    3647          </dd>
    3648       </dl>
     3654         </li>
     3655      </ul>
    36493656      <p id="rfc.section.14.1.p.5">The example</p>
    36503657      <div id="rfc.figure.u.61"></div><pre class="text">    Accept: audio/*; q=0.2, audio/basic
     
    37423749         client.
    37433750      </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-codings
     3751      <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
    37463753            commonly understood by HTTP/1.0 clients (i.e., "gzip" and "compress") are preferred; some older clients improperly display
    37473754            messages sent with other content-codings. The server might also make this decision based on information about the particular
    37483755            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 will
     3756         </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
    37513758            not work and are not permitted with x-gzip or x-compress.
    3752          </dd>
    3753       </dl>
     3759         </li>
     3760      </ul>
    37543761      <div id="rfc.iref.a.5"></div>
    37553762      <div id="rfc.iref.h.6"></div>
     
    37703777         range present in the Accept-Language field.
    37713778      </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 always
     3779      <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
    37743781            true that if a user understands a language with a certain tag, then this user will also understand all languages with tags
    37753782            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>
    37783785      <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
    37793786         in the field that matches the language-tag. If no language-range in the field matches the tag, the language quality factor
     
    37873794         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.
    37883795      </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 not
     3796      <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
    37913798            familiar with the details of language matching as described above, and should provide appropriate guidance. As an example,
    37923799            users might assume that on selecting "en-gb", they will be served any kind of English document if British English is not available.
    37933800            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>
    37963803      <div id="rfc.iref.a.6"></div>
    37973804      <div id="rfc.iref.h.7"></div>
     
    38713878         is to be given in the response.
    38723879      </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&nbsp;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&nbsp;14.32</a>).
     3882         </li>
     3883      </ul>
    38773884      <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
    38783885         might be applicable to all recipients along the request/response chain. It is not possible to specify a cache-directive for
     
    39283935      <p id="rfc.section.14.9.1.p.2"> <span id="rfc.iref.c.9"></span>  <span id="rfc.iref.p.4"></span> public
    39293936      </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 also
     3937      <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
    39323939            Authorization, <a href="#header.authorization" id="rfc.xref.header.authorization.4" title="Authorization">Section&nbsp;14.8</a>, for additional details.)
    3933          </dd>
    3934       </dl>
     3940         </li>
     3941      </ul>
    39353942      <p id="rfc.section.14.9.1.p.3"> <span id="rfc.iref.c.10"></span>  <span id="rfc.iref.p.5"></span> private
    39363943      </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 for
     3944      <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
    39393946            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 message
     3947         </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
    39423949            content.
    3943          </dd>
    3944       </dl>
     3950         </li>
     3951      </ul>
    39453952      <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
    39463953      </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 origin
     3954      <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
    39493956            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 origin
     3957         </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
    39523959            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>
    39593966      <h3 id="rfc.section.14.9.2"><a href="#rfc.section.14.9.2">14.9.2</a>&nbsp;<a id="what.may.be.stored.by.caches" href="#what.may.be.stored.by.caches">What May be Stored by Caches</a></h3>
    39603967      <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
    39613968      </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,
    39643971            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
    39653972            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 caching
     3973         </li>
     3974         <li>Even when this directive is associated with a response, users might explicitly store such a response outside of the caching
    39683975            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 about
     3976         </li>
     3977         <li>The purpose of this directive is to meet the stated requirements of certain users and service authors who are concerned about
    39713978            accidental releases of information via unanticipated accesses to cache data structures. While the use of this directive might
    39723979            improve privacy in some cases, we caution that it is NOT in any way a reliable or sufficient mechanism for ensuring privacy.
    39733980            In particular, malicious or compromised caches might not recognize or obey this directive, and communications networks might
    39743981            be vulnerable to eavesdropping.
    3975          </dd>
    3976       </dl>
     3982         </li>
     3983      </ul>
    39773984      <h3 id="rfc.section.14.9.3"><a href="#rfc.section.14.9.3">14.9.3</a>&nbsp;<a id="modifications.of.the.basic.expiration.mechanism" href="#modifications.of.the.basic.expiration.mechanism">Modifications of the Basic Expiration Mechanism</a></h3>
    39783985      <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&nbsp;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,
     
    39903997         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.
    39913998      </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 network
     3999      <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
    39944001            including older caches that do not understand that feature. The origin server will need to combine the new feature with an
    39954002            Expires field whose value is less than or equal to the Date value. This will prevent older caches from improperly caching
    39964003            the response.
    3997          </dd>
    3998       </dl>
     4004         </li>
     4005      </ul>
    39994006      <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
    40004007      </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 specified
     4008      <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
    40034010            by this directive overrides the maximum age specified by either the max-age directive or the Expires header. The s-maxage
    40044011            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&nbsp;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
    40054012            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>
    40084015      <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
    40094016         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
     
    40144021      <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
    40154022      </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. Unless
     4023      <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
    40184025            max-stale directive is also included, the client is not willing to accept a stale response.
    4019          </dd>
    4020       </dl>
     4026         </li>
     4027      </ul>
    40214028      <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
    40224029      </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 the
     4030      <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
    40254032            specified time in seconds. That is, the client wants a response that will still be fresh for at least the specified number
    40264033            of seconds.
    4027          </dd>
    4028       </dl>
     4034         </li>
     4035      </ul>
    40294036      <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
    40304037      </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 assigned
     4038      <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
    40334040            a value, then the client is willing to accept a response that has exceeded its expiration time by no more than the specified
    40344041            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>
    40374044      <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
    40384045         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).
     
    40564063      <p id="rfc.section.14.9.4.p.3">The client can specify these three kinds of action using Cache-Control request directives:</p>
    40574064      <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".
    40604067            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>
    40634070      <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 to
     4071      <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
    40664073            revalidate its own entry, if any, with the next cache or server. The initial request includes a cache-validating conditional
    40674074            with the client's current validator.
    4068          </dd>
    4069       </dl>
     4075         </li>
     4076      </ul>
    40704077      <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 revalidate
     4078      <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
    40734080            its own entry, if any, with the next cache or server. The initial request does not include a cache-validating conditional;
    40744081            the first cache along the path (if any) that holds a cache entry for this resource includes a cache-validating conditional
    40754082            with its current validator.
    4076          </dd>
    4077       </dl>
     4083         </li>
     4084      </ul>
    40784085      <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
    40794086      </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 client
     4087      <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
    40824089            has supplied its own validator in the request, the supplied validator might differ from the validator currently stored with
    40834090            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 own
     4091         </li>
     4092         <li>However, the choice of validator might affect performance. The best approach is for the intermediate cache to use its own
    40864093            validator when making its request. If the server replies with 304 (Not Modified), then the cache can return its now validated
    40874094            copy to the client with a 200 (OK) response. If the server replies with a new entity and cache validator, however, the intermediate
     
    40894096            If the client's validator is equal to the origin server's, then the intermediate cache simply returns 304 (Not Modified).
    40904097            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>
    40954102      <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
    40964103      </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 responses
     4104      <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
    40994106            that it currently has stored, and not to reload or revalidate with the origin server. To do this, the client may include the
    41004107            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
    41014108            Timeout) status. However, if a group of caches is being operated as a unified system with good internal connectivity, such
    41024109            a request <em class="bcp14">MAY</em> be forwarded within that group of caches.
    4103          </dd>
    4104       </dl>
     4110         </li>
     4111      </ul>
    41054112      <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
    41064113      </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 to
     4114      <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
    41094116            require revalidation of a cache entry on any subsequent use. When the must-revalidate directive is present in a response received
    41104117            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.
    41114118            (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
    41124119            is stale.)
    4113          </dd>
    4114          <dd>The must-revalidate directive is necessary to support reliable operation for certain protocol features. In all circumstances
     4120         </li>
     4121         <li>The must-revalidate directive is necessary to support reliable operation for certain protocol features. In all circumstances
    41154122            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 incorrect
     4123         </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
    41184125            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>
    41234130      <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
    41244131      </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-shared
     4132      <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
    41274134            user agent caches. It can be used on a response to an authenticated request to permit the user's cache to store and later
    41284135            return the response without needing to revalidate it (since it has already been authenticated once by that user), while still
     
    41304137            Note that such authenticated responses also need the public cache control directive in order to allow them to be cached at
    41314138            all.
    4132          </dd>
    4133       </dl>
     4139         </li>
     4140      </ul>
    41344141      <h3 id="rfc.section.14.9.5"><a href="#rfc.section.14.9.5">14.9.5</a>&nbsp;<a id="no-transform.directive" href="#no-transform.directive">No-Transform Directive</a></h3>
    41354142      <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
    41364143      </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-transparent
     4144      <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
    41394146            proxy might, for example, convert between image formats in order to save cache space or to reduce the amount of traffic on
    41404147            a slow link.
    4141          </dd>
    4142          <dd>Serious operational problems occur, however, when these transformations are applied to entity bodies intended for certain
     4148         </li>
     4149         <li>Serious operational problems occur, however, when these transformations are applied to entity bodies intended for certain
    41434150            kinds of applications. For example, applications for medical imaging, scientific data analysis and those using end-to-end
    41444151            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&nbsp;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&nbsp;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>
    41494156      <h3 id="rfc.section.14.9.6"><a href="#rfc.section.14.9.6">14.9.6</a>&nbsp;<a id="cache.control.extensions" href="#cache.control.extensions">Cache Control Extensions</a></h3>
    41504157      <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
     
    43114318      <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.
    43124319      </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 several
     4320      <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
    43154322            ways in which the application of Content-MD5 to HTTP entity-bodies differs from its application to MIME entity-bodies. One
    43164323            is that HTTP, unlike MIME, does not use Content-Transfer-Encoding, and does use Transfer-Encoding and Content-Encoding. Another
     
    43184325            used to compute the digest is the transmission byte order defined for the type. Lastly, HTTP allows transmission of text types
    43194326            with any of several line break conventions and not just the canonical form using CRLF.
    4320          </dd>
    4321       </dl>
     4327         </li>
     4328      </ul>
    43224329      <div id="rfc.iref.c.28"></div>
    43234330      <div id="rfc.iref.h.18"></div>
     
    43874394         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&nbsp;10.4.17</a>).
    43884395      </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 for
     4396      <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
    43914398            an unsatisfiable Range request-header, since not all servers implement this request-header.
    4392          </dd>
    4393       </dl>
     4399         </li>
     4400      </ul>
    43944401      <div id="rfc.iref.c.29"></div>
    43954402      <div id="rfc.iref.h.19"></div>
     
    44924499      <div id="rfc.figure.u.107"></div><pre class="text">   Expires: Thu, 01 Dec 1994 16:00:00 GMT
    44934500</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&nbsp;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&nbsp;14.9.3</a>), that directive overrides the Expires field.
     4503         </li>
     4504      </ul>
    44984505      <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").
    44994506      </p>
     
    46044611      </ol>
    46054612      <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&nbsp;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-than
     4613      <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&nbsp;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
    46124619            function, for deciding whether to send a 304 (Not Modified) response. To get best results when sending an If-Modified-Since
    46134620            header field for cache validation, clients are advised to use the exact date string received in a previous Last-Modified header
    46144621            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 for
     4622         </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
    46174624            the same request, the client should be aware of the fact that this date is interpreted in the server's understanding of time.
    46184625            The client should consider unsynchronized clocks and rounding problems due to the different encodings of time between the
     
    46214628            If-Modified-Since date is derived from the client's clock without correction to the server's clock. Corrections for different
    46224629            time bases between client and server are at best approximate due to network latency.
    4623          </dd>
    4624       </dl>
     4630         </li>
     4631      </ul>
    46254632      <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
    46264633         fields is undefined by this specification.
     
    47324739      <div id="rfc.figure.u.124"></div><pre class="text">    Location: http://www.w3.org/pub/WWW/People.html
    47334740</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&nbsp;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&nbsp;14.14</a>) differs from Location in that the Content-Location identifies the original location of the entity enclosed in the request.
    47364743            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&nbsp;13.10</a> for cache requirements of some methods.
    4737          </dd>
    4738       </dl>
     4744         </li>
     4745      </ul>
    47394746      <div id="rfc.iref.m.15"></div>
    47404747      <div id="rfc.iref.h.34"></div>
     
    47704777         HTTP.
    47714778      </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 reliable
     4779      <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
    47744781            replacement for "Cache-Control: no-cache" in a response
    4775          </dd>
    4776       </dl>
     4782         </li>
     4783      </ul>
    47774784      <div id="rfc.iref.p.8"></div>
    47784785      <div id="rfc.iref.h.36"></div>
     
    49084915</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&nbsp;14.45</a>).
    49094916      </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 attacks
     4917      <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
    49124919            against software that is known to contain security holes. Server implementors are encouraged to make this field a configurable
    49134920            option.
    4914          </dd>
    4915       </dl>
     4921         </li>
     4922      </ul>
    49164923      <div id="rfc.iref.t.3"></div>
    49174924      <div id="rfc.iref.h.42"></div>
     
    51485155      </p>
    51495156      <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>
    51545161      <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 inability
     5162      <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
    51575164            to reach the server.
    5158          </dd>
    5159       </dl>
     5165         </li>
     5166      </ul>
    51605167      <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>
    51655172      <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 greater
     5173      <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
    51685175            than 24 hours.
    5169          </dd>
    5170       </dl>
     5176         </li>
     5177      </ul>
    51715178      <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>
    51765183      <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 the
     5184      <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
    51795186            Content-Encoding header) or media-type (as specified in the Content-Type header) of the response, or the entity-body of the
    51805187            response, unless this Warning code already appears in the response.
    5181          </dd>
    5182       </dl>
     5188         </li>
     5189      </ul>
    51835190      <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>
    51885195      <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.
    51895196      </p>
     
    54155422      <h1 id="rfc.references"><a href="#rfc.section.17" id="rfc.section.17">17.</a> References
    54165423      </h1>
    5417       <table summary="References">                                                                                                 
     5424      <table>                                                                                                 
    54185425         <tr>
    54195426            <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.
    54225428               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
    54235429               6: Latin/Arabic alphabet, ISO-8859-6, 1987. Part 7: Latin/Greek alphabet, ISO-8859-7, 1987. Part 8: Latin/Hebrew alphabet,
     
    54315437         <tr>
    54325438            <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&nbsp;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&nbsp;1997.</td>
    54345440         </tr>
    54355441         <tr>
    54365442            <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&nbsp;v. 28, pp. 25-35, Dec&nbsp;1995.<br>Slightly revised version of paper in Proc. 2nd International WWW Conference '94: Mosaic and the Web, Oct. 1994, which is available
     5443            <td class="top">Padmanabhan, V. and J. Mogul, “Improving HTTP Latency”, Computer Networks and ISDN Systems&nbsp;v. 28, pp. 25-35, Dec&nbsp;1995.<br>Slightly revised version of paper in Proc. 2nd International WWW Conference '94: Mosaic and the Web, Oct. 1994, which is available
    54385444               at &lt;<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>&gt;.
    54395445            </td>
     
    54465452         <tr>
    54475453            <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&nbsp;3, RFC&nbsp;1123, October&nbsp;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&nbsp;3, RFC&nbsp;1123, October&nbsp;1989.
    54495455            </td>
    54505456         </tr>
    54515457         <tr>
    54525458            <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&nbsp;1305, March&nbsp;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&nbsp;1305, March&nbsp;1992.
    54545460            </td>
    54555461         </tr>
    54565462         <tr>
    54575463            <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 <a 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&nbsp;1436, March&nbsp;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&nbsp;1436, March&nbsp;1993.
    54595465            </td>
    54605466         </tr>
    54615467         <tr>
    54625468            <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&nbsp;1590, November&nbsp;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&nbsp;1590, November&nbsp;1996.
    54645470            </td>
    54655471         </tr>
    54665472         <tr>
    54675473            <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 Network
     5474            <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
    54695475                  as used in the World-Wide Web</a>”, RFC&nbsp;1630, June&nbsp;1994.
    54705476            </td>
     
    54725478         <tr>
    54735479            <td class="reference"><b id="RFC1700">[RFC1700]</b></td>
    5474             <td class="top"><a title="USC/Information Sciences Institute">Reynolds, J.</a> and <a title="USC/Information Sciences Institute">J. Postel</a>, “<a href="http://tools.ietf.org/html/rfc1700">Assigned Numbers</a>”, STD&nbsp;2, RFC&nbsp;1700, October&nbsp;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&nbsp;2, RFC&nbsp;1700, October&nbsp;1994.
    54755481            </td>
    54765482         </tr>
    54775483         <tr>
    54785484            <td class="reference"><b id="RFC1737">[RFC1737]</b></td>
    5479             <td class="top"><a title="Xerox Palo Alto Research Center">Masinter, L.</a> and <a 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&nbsp;1737, December&nbsp;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&nbsp;1737, December&nbsp;1994.
    54805486            </td>
    54815487         </tr>
    54825488         <tr>
    54835489            <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 <a 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&nbsp;1738, December&nbsp;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&nbsp;1738, December&nbsp;1994.
    54855491            </td>
    54865492         </tr>
    54875493         <tr>
    54885494            <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&nbsp;1766, March&nbsp;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&nbsp;1766, March&nbsp;1995.
    54905496            </td>
    54915497         </tr>
    54925498         <tr>
    54935499            <td class="reference"><b id="RFC1806">[RFC1806]</b></td>
    5494             <td class="top"><a title="New Century Systems">Troost, R.</a> and <a 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&nbsp;1806, June&nbsp;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&nbsp;1806, June&nbsp;1995.
    54955501            </td>
    54965502         </tr>
    54975503         <tr>
    54985504            <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&nbsp;1808, June&nbsp;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&nbsp;1808, June&nbsp;1995.
    55005506            </td>
    55015507         </tr>
    55025508         <tr>
    55035509            <td class="reference"><b id="RFC1864">[RFC1864]</b></td>
    5504             <td class="top"><a title="Carnegie Mellon University">Myers, J.</a> and <a title="Dover Beach Consulting, Inc.">M. Rose</a>, “<a href="http://tools.ietf.org/html/rfc1864">The Content-MD5 Header Field</a>”, RFC&nbsp;1864, October&nbsp;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&nbsp;1864, October&nbsp;1995.
    55055511            </td>
    55065512         </tr>
    5507          <!--WARNING: unused reference 'RFC1866'-->
    55085513         <tr>
    55095514            <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&nbsp;1866, November&nbsp;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&nbsp;1866, November&nbsp;1995.
    55115516            </td>
    55125517         </tr>
    55135518         <tr>
    55145519            <td class="reference"><b id="RFC1867">[RFC1867]</b></td>
    5515             <td class="top"><a title="Xerox Palo Alto Research Center">Masinter, L.</a> and <a title="XSoft, Xerox Corporation">E. Nebel</a>, “<a href="http://tools.ietf.org/html/rfc1867">Form-based File Upload in HTML</a>”, RFC&nbsp;1867, November&nbsp;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&nbsp;1867, November&nbsp;1995.
    55165521            </td>
    55175522         </tr>
    55185523         <tr>
    55195524            <td class="reference"><b id="RFC1900">[RFC1900]</b></td>
    5520             <td class="top"><a title="CERN, Computing and Networks Division">Carpenter, B.</a> and <a title="cisco Systems">Y. Rekhter</a>, “<a href="http://tools.ietf.org/html/rfc1900">Renumbering Needs Work</a>”, RFC&nbsp;1900, February&nbsp;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&nbsp;1900, February&nbsp;1996.
    55215526            </td>
    55225527         </tr>
    55235528         <tr>
    55245529            <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&nbsp;1945, May&nbsp;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&nbsp;1945, May&nbsp;1996.
    55265531            </td>
    55275532         </tr>
    55285533         <tr>
    55295534            <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&nbsp;1950, May&nbsp;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&nbsp;1950, May&nbsp;1996.
    55315536            </td>
    55325537         </tr>
    55335538         <tr>
    55345539            <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&nbsp;1951, May&nbsp;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&nbsp;1951, May&nbsp;1996.
    55365541            </td>
    55375542         </tr>
    55385543         <tr>
    55395544            <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&nbsp;1952, May&nbsp;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&nbsp;1952, May&nbsp;1996.
    55415546            </td>
    55425547         </tr>
    5543          <!--WARNING: unused reference 'RFC2026'-->
    55445548         <tr>
    55455549            <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&nbsp;9, RFC&nbsp;2026, October&nbsp;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&nbsp;9, RFC&nbsp;2026, October&nbsp;1996.
    55475551            </td>
    55485552         </tr>
    55495553         <tr>
    55505554            <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&nbsp;2045, November&nbsp;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&nbsp;2045, November&nbsp;1996.
    55525556            </td>
    55535557         </tr>
    55545558         <tr>
    55555559            <td class="reference"><b id="RFC2046">[RFC2046]</b></td>
    5556             <td class="top"><a title="Innosoft International, Inc.">Freed, N.</a> and <a 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&nbsp;2046, November&nbsp;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&nbsp;2046, November&nbsp;1996.
    55575561            </td>
    55585562         </tr>
    55595563         <tr>
    55605564            <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&nbsp;2047, November&nbsp;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&nbsp;2047, November&nbsp;1996.
    55625566            </td>
    55635567         </tr>
    55645568         <tr>
    55655569            <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&nbsp;2049, November&nbsp;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&nbsp;2049, November&nbsp;1996.
    55675571            </td>
    55685572         </tr>
    55695573         <tr>
    55705574            <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 <a 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&nbsp;2068, January&nbsp;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&nbsp;2068, January&nbsp;1997.
    55725576            </td>
    55735577         </tr>
    5574          <!--WARNING: unused reference 'RFC2069'-->
    55755578         <tr>
    55765579            <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 <a title="Open Market, Inc.">L. Stewart</a>, “<a href="http://tools.ietf.org/html/rfc2069">An Extension to HTTP : Digest Access Authentication</a>”, RFC&nbsp;2069, January&nbsp;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&nbsp;2069, January&nbsp;1997.
    55785581            </td>
    55795582         </tr>
    55805583         <tr>
    55815584            <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&nbsp;2076, February&nbsp;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&nbsp;2076, February&nbsp;1997.
    55835586            </td>
    55845587         </tr>
    55855588         <tr>
    55865589            <td class="reference"><b id="RFC2110">[RFC2110]</b></td>
    5587             <td class="top"><a title="Stockholm University and KTH">Palme, J.</a> and <a 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&nbsp;2110, March&nbsp;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&nbsp;2110, March&nbsp;1997.
    55885591            </td>
    55895592         </tr>
    55905593         <tr>
    55915594            <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&nbsp;14, RFC&nbsp;2119, March&nbsp;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&nbsp;14, RFC&nbsp;2119, March&nbsp;1997.
    55935596            </td>
    55945597         </tr>
    55955598         <tr>
    55965599            <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&nbsp;2145, May&nbsp;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&nbsp;2145, May&nbsp;1997.
    55985601            </td>
    55995602         </tr>
    56005603         <tr>
    56015604            <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 <a 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&nbsp;2183, August&nbsp;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&nbsp;2183, August&nbsp;1997.
    56035606            </td>
    56045607         </tr>
    56055608         <tr>
    56065609            <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&nbsp;18, RFC&nbsp;2277, January&nbsp;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&nbsp;18, RFC&nbsp;2277, January&nbsp;1998.
    56085611            </td>
    56095612         </tr>
    56105613         <tr>
    56115614            <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&nbsp;2279, January&nbsp;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&nbsp;2279, January&nbsp;1998.
    56135616            </td>
    56145617         </tr>
    56155618         <tr>
    56165619            <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&nbsp;2324, April&nbsp;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&nbsp;2324, April&nbsp;1998.
    56185621            </td>
    56195622         </tr>
    56205623         <tr>
    56215624            <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 <a title="Xerox PARC">L. Masinter</a>, “<a href="http://tools.ietf.org/html/rfc2396">Uniform Resource Identifiers (URI): Generic Syntax</a>”, RFC&nbsp;2396, August&nbsp;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&nbsp;2396, August&nbsp;1998.
    56235626            </td>
    56245627         </tr>
    56255628         <tr>
    56265629            <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 <a title="Open Market, Inc.">L. Stewart</a>, “<a href="http://tools.ietf.org/html/rfc2617">HTTP Authentication: Basic and Digest Access Authentication</a>”, RFC&nbsp;2617, June&nbsp;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&nbsp;2617, June&nbsp;1999.
    56285631            </td>
    56295632         </tr>
    56305633         <tr>
    56315634            <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&nbsp;10, RFC&nbsp;821, August&nbsp;1982.
     5635            <td class="top">Postel, J., “<a href="http://tools.ietf.org/html/rfc821">Simple Mail Transfer Protocol</a>”, STD&nbsp;10, RFC&nbsp;821, August&nbsp;1982.
    56335636            </td>
    56345637         </tr>
    56355638         <tr>
    56365639            <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&nbsp;11, RFC&nbsp;822, August&nbsp;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&nbsp;11, RFC&nbsp;822, August&nbsp;1982.
    56385641            </td>
    56395642         </tr>
     
    56555658         <tr>
    56565659            <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 <a 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&nbsp;ISI/RR-98-463 (original report dated Aug.1996), Aug&nbsp;1998, &lt;<a href="http://www.isi.edu/touch/pubs/http-perf96/">http://www.isi.edu/touch/pubs/http-perf96/</a>&gt;.
     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&nbsp;ISI/RR-98-463 (original report dated Aug.1996), Aug&nbsp;1998, &lt;<a href="http://www.isi.edu/touch/pubs/http-perf96/">http://www.isi.edu/touch/pubs/http-perf96/</a>&gt;.
    56585661            </td>
    56595662         </tr>
     
    56675670         </tr>
    56685671      </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>&nbsp;<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>&nbsp;<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>&nbsp;<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>&nbsp;<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>&nbsp;<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>&nbsp;<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>&nbsp;<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>&nbsp;<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>&nbsp;<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>&nbsp;<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>&nbsp;<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>&nbsp;<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>&nbsp;<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>&nbsp;<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>
    56775682      <h1 id="rfc.section.19"><a href="#rfc.section.19">19.</a>&nbsp;Appendices
    56785683      </h1>
     
    60586063      </h1>
    60596064      <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, the
    6063          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 ORGANIZATION
    6066          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 ANY
    6068          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 might
    6072          be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any
    6073          license under such rights might or might not be available; nor does it represent that it has made any independent effort to
    6074          identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and
    6075          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 result
    6078          of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users
    6079          of this specification can be obtained from the IETF on-line IPR repository at &lt;<a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>&gt;.
    6080       </p>
    6081       <p>The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary
    6082          rights that may cover technology that may be required to implement this standard. Please address the information to the IETF
    6083          at <a href="mailto:ietf-ipr@ietf.org">ietf-ipr@ietf.org</a>.
    6084       </p>
    60856065      <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1>
    60866066      <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>
     
    67636743         </ul>
    67646744      </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>
    67656770   </body>
    67666771</html>
Note: See TracChangeset for help on using the changeset viewer.