Ignore:
Timestamp:
04/08/10 15:03:20 (13 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.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 {
    … …  
    340347      <link rel="Alternate" title="Authorative ASCII Version" href="http://www.ietf.org/rfc/rfc2616.txt">
    341348      <link rel="Help" title="Additional Information on tools.ietf.org" href="http://tools.ietf.org/html/rfc2616">
    342       <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.438, 2009-05-27 13:34:05, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/">
    343       <link rel="schema.DC" href="http://purl.org/dc/elements/1.1/">
    344       <meta name="DC.Creator" content="Fielding, R.">
    345       <meta name="DC.Creator" content="Gettys, J.">
    346       <meta name="DC.Creator" content="Mogul, J.">
    347       <meta name="DC.Creator" content="Frystyk, H.">
    348       <meta name="DC.Creator" content="Masinter, L.">
    349       <meta name="DC.Creator" content="Leach, P.">
    350       <meta name="DC.Creator" content="Berners-Lee, T.">
    351       <meta name="DC.Identifier" content="urn:ietf:rfc:2616">
    352       <meta name="DC.Date.Issued" scheme="ISO8601" content="1999-06">
    353       <meta name="DC.Relation.Replaces" content="urn:ietf:rfc:2068">
    354       <meta name="DC.Description.Abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, protocol which can be used for many tasks beyond its use for hypertext, such as name servers and distributed object management systems, through extension of its request methods, error codes and headers . A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred. HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as &#34;HTTP/1.1&#34;, and is an update to RFC 2068 .">
    355       <meta name="DC.isPartOf" content="urn:ISSN:2070-1721">
     349      <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.520, 2010-07-14 12:36:35, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/">
     350      <link rel="schema.dct" href="http://purl.org/dc/terms/">
     351      <meta name="dct.creator" content="Fielding, R.">
     352      <meta name="dct.creator" content="Gettys, J.">
     353      <meta name="dct.creator" content="Mogul, J.">
     354      <meta name="dct.creator" content="Frystyk, H.">
     355      <meta name="dct.creator" content="Masinter, L.">
     356      <meta name="dct.creator" content="Leach, P.">
     357      <meta name="dct.creator" content="Berners-Lee, T.">
     358      <meta name="dct.identifier" content="urn:ietf:rfc:2616">
     359      <meta name="dct.issued" scheme="ISO8601" content="1999-06">
     360      <meta name="dct.replaces" content="urn:ietf:rfc:2068">
     361      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, protocol which can be used for many tasks beyond its use for hypertext, such as name servers and distributed object management systems, through extension of its request methods, error codes and headers . A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred. HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as &#34;HTTP/1.1&#34;, and is an update to RFC 2068 .">
     362      <meta name="dct.isPartOf" content="urn:issn:2070-1721">
     363      <meta name="description" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, protocol which can be used for many tasks beyond its use for hypertext, such as name servers and distributed object management systems, through extension of its request methods, error codes and headers . A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred. HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as &#34;HTTP/1.1&#34;, and is an update to RFC 2068 .">
    356364   </head>
    357365   <body>
    358       <table summary="header information" class="header" border="0" cellpadding="1" cellspacing="1">
    359          <tr>
    360             <td class="header left">Network Working Group</td>
    361             <td class="header right">R. Fielding</td>
    362          </tr>
    363          <tr>
    364             <td class="header left">Request for Comments: 2616</td>
    365             <td class="header right">UC Irvine</td>
    366          </tr>
    367          <tr>
    368             <td class="header left">Obsoletes: <a href="http://tools.ietf.org/html/rfc2068">2068</a></td>
    369             <td class="header right">J. Gettys</td>
    370          </tr>
    371          <tr>
    372             <td class="header left">Category: Standards Track</td>
    373             <td class="header right">Compaq/W3C</td>
    374          </tr>
    375          <tr>
    376             <td class="header left"></td>
    377             <td class="header right">J. Mogul</td>
    378          </tr>
    379          <tr>
    380             <td class="header left"></td>
    381             <td class="header right">Compaq</td>
    382          </tr>
    383          <tr>
    384             <td class="header left"></td>
    385             <td class="header right">H. Frystyk</td>
    386          </tr>
    387          <tr>
    388             <td class="header left"></td>
    389             <td class="header right">W3C/MIT</td>
    390          </tr>
    391          <tr>
    392             <td class="header left"></td>
    393             <td class="header right">L. Masinter</td>
    394          </tr>
    395          <tr>
    396             <td class="header left"></td>
    397             <td class="header right">Xerox</td>
    398          </tr>
    399          <tr>
    400             <td class="header left"></td>
    401             <td class="header right">P. Leach</td>
    402          </tr>
    403          <tr>
    404             <td class="header left"></td>
    405             <td class="header right">Microsoft</td>
    406          </tr>
    407          <tr>
    408             <td class="header left"></td>
    409             <td class="header right">T. Berners-Lee</td>
    410          </tr>
    411          <tr>
    412             <td class="header left"></td>
    413             <td class="header right">W3C/MIT</td>
    414          </tr>
    415          <tr>
    416             <td class="header left"></td>
    417             <td class="header right">June 1999</td>
    418          </tr>
     366      <table class="header">
     367         <tbody>
     368            <tr>
     369               <td class="left">Network Working Group</td>
     370               <td class="right">R. Fielding</td>
     371            </tr>
     372            <tr>
     373               <td class="left">Request for Comments: 2616</td>
     374               <td class="right">UC Irvine</td>
     375            </tr>
     376            <tr>
     377               <td class="left">Obsoletes: <a href="http://tools.ietf.org/html/rfc2068">2068</a></td>
     378               <td class="right">J. Gettys</td>
     379            </tr>
     380            <tr>
     381               <td class="left">Category: Standards Track</td>
     382               <td class="right">Compaq/W3C</td>
     383            </tr>
     384            <tr>
     385               <td class="left"></td>
     386               <td class="right">J. Mogul</td>
     387            </tr>
     388            <tr>
     389               <td class="left"></td>
     390               <td class="right">Compaq</td>
     391            </tr>
     392            <tr>
     393               <td class="left"></td>
     394               <td class="right">H. Frystyk</td>
     395            </tr>
     396            <tr>
     397               <td class="left"></td>
     398               <td class="right">W3C/MIT</td>
     399            </tr>
     400            <tr>
     401               <td class="left"></td>
     402               <td class="right">L. Masinter</td>
     403            </tr>
     404            <tr>
     405               <td class="left"></td>
     406               <td class="right">Xerox</td>
     407            </tr>
     408            <tr>
     409               <td class="left"></td>
     410               <td class="right">P. Leach</td>
     411            </tr>
     412            <tr>
     413               <td class="left"></td>
     414               <td class="right">Microsoft</td>
     415            </tr>
     416            <tr>
     417               <td class="left"></td>
     418               <td class="right">T. Berners-Lee</td>
     419            </tr>
     420            <tr>
     421               <td class="left"></td>
     422               <td class="right">W3C/MIT</td>
     423            </tr>
     424            <tr>
     425               <td class="left"></td>
     426               <td class="right">June 1999</td>
     427            </tr>
     428         </tbody>
    419429      </table>
    420430      <p class="title">Hypertext Transfer Protocol -- HTTP/1.1</p>
    … …  
    784794         </li>
    785795         <li class="tocline0">20.&nbsp;&nbsp;&nbsp;<a href="#rfc.section.20">Index</a></li>
     796         <li class="tocline0"><a href="#rfc.index">Index</a></li>
    786797         <li class="tocline0"><a href="#rfc.ipr">Intellectual Property and Copyright Statements</a></li>
    787          <li class="tocline0"><a href="#rfc.index">Index</a></li>
    788798      </ul>
    789799      <hr class="noprint">
    … …  
    818828      <p id="rfc.section.1.3.p.2"> <span id="rfc.iref.c.1"></span>  <dfn>connection</dfn> 
    819829      </p>
    820       <dl class="empty">
    821          <dd>A transport layer virtual circuit established between two programs for the purpose of communication.</dd>
    822       </dl>
     830      <ul class="empty">
     831         <li>A transport layer virtual circuit established between two programs for the purpose of communication.</li>
     832      </ul>
    823833      <p id="rfc.section.1.3.p.3"> <span id="rfc.iref.m.1"></span>  <dfn>message</dfn> 
    824834      </p>
    825       <dl class="empty">
    826          <dd>The basic unit of HTTP communication, consisting of a structured sequence of octets matching the syntax defined in <a href="#http.message" title="HTTP Message">Section&nbsp;4</a> and transmitted via the connection.
    827          </dd>
    828       </dl>
     835      <ul class="empty">
     836         <li>The basic unit of HTTP communication, consisting of a structured sequence of octets matching the syntax defined in <a href="#http.message" title="HTTP Message">Section&nbsp;4</a> and transmitted via the connection.
     837         </li>
     838      </ul>
    829839      <p id="rfc.section.1.3.p.4"> <span id="rfc.iref.r.1"></span>  <dfn>request</dfn> 
    830840      </p>
    831       <dl class="empty">
    832          <dd>An HTTP request message, as defined in <a href="#request" title="Request">Section&nbsp;5</a>.
    833          </dd>
    834       </dl>
     841      <ul class="empty">
     842         <li>An HTTP request message, as defined in <a href="#request" title="Request">Section&nbsp;5</a>.
     843         </li>
     844      </ul>
    835845      <p id="rfc.section.1.3.p.5"> <span id="rfc.iref.r.2"></span>  <dfn>response</dfn> 
    836846      </p>
    837       <dl class="empty">
    838          <dd>An HTTP response message, as defined in <a href="#response" title="Response">Section&nbsp;6</a>.
    839          </dd>
    840       </dl>
     847      <ul class="empty">
     848         <li>An HTTP response message, as defined in <a href="#response" title="Response">Section&nbsp;6</a>.
     849         </li>
     850      </ul>
    841851      <p id="rfc.section.1.3.p.6"> <span id="rfc.iref.r.3"></span>  <dfn>resource</dfn> 
    842852      </p>
    843       <dl class="empty">
    844          <dd>A network data object or service that can be identified by a URI, as defined in <a href="#uri" title="Uniform Resource Identifiers">Section&nbsp;3.2</a>. Resources may be available in multiple representations (e.g. multiple languages, data formats, size, and resolutions) or
     853      <ul class="empty">
     854         <li>A network data object or service that can be identified by a URI, as defined in <a href="#uri" title="Uniform Resource Identifiers">Section&nbsp;3.2</a>. Resources may be available in multiple representations (e.g. multiple languages, data formats, size, and resolutions) or
    845855            vary in other ways.
    846          </dd>
    847       </dl>
     856         </li>
     857      </ul>
    848858      <p id="rfc.section.1.3.p.7"> <span id="rfc.iref.e.1"></span>  <dfn>entity</dfn> 
    849859      </p>
    850       <dl class="empty">
    851          <dd>The information transferred as the payload of a request or response. An entity consists of metainformation in the form of
     860      <ul class="empty">
     861         <li>The information transferred as the payload of a request or response. An entity consists of metainformation in the form of
    852862            entity-header fields and content in the form of an entity-body, as described in <a href="#entity" title="Entity">Section&nbsp;7</a>.
    853          </dd>
    854       </dl>
     863         </li>
     864      </ul>
    855865      <p id="rfc.section.1.3.p.8"> <span id="rfc.iref.r.4"></span>  <dfn>representation</dfn> 
    856866      </p>
    857       <dl class="empty">
    858          <dd>An entity included with a response that is subject to content negotiation, as described in <a href="#content.negotiation" title="Content Negotiation">Section&nbsp;12</a>. There may exist multiple representations associated with a particular response status.
    859          </dd>
    860       </dl>
     867      <ul class="empty">
     868         <li>An entity included with a response that is subject to content negotiation, as described in <a href="#content.negotiation" title="Content Negotiation">Section&nbsp;12</a>. There may exist multiple representations associated with a particular response status.
     869         </li>
     870      </ul>
    861871      <p id="rfc.section.1.3.p.9"> <span id="rfc.iref.c.2"></span>  <dfn>content negotiation</dfn> 
    862872      </p>
    863       <dl class="empty">
    864          <dd>The mechanism for selecting the appropriate representation when servicing a request, as described in <a href="#content.negotiation" title="Content Negotiation">Section&nbsp;12</a>. The representation of entities in any response can be negotiated (including error responses).
    865          </dd>
    866       </dl>
     873      <ul class="empty">
     874         <li>The mechanism for selecting the appropriate representation when servicing a request, as described in <a href="#content.negotiation" title="Content Negotiation">Section&nbsp;12</a>. The representation of entities in any response can be negotiated (including error responses).
     875         </li>
     876      </ul>
    867877      <p id="rfc.section.1.3.p.10"> <span id="rfc.iref.v.1"></span>  <dfn>variant</dfn> 
    868878      </p>
    869       <dl class="empty">
    870          <dd>A resource may have one, or more than one, representation(s) associated with it at any given instant. Each of these representations
     879      <ul class="empty">
     880         <li>A resource may have one, or more than one, representation(s) associated with it at any given instant. Each of these representations
    871881            is termed a `varriant'. Use of the term `variant' does not necessarily imply that the resource is subject to content negotiation.
    872          </dd>
    873       </dl>
     882         </li>
     883      </ul>
    874884      <p id="rfc.section.1.3.p.11"> <span id="rfc.iref.c.3"></span>  <dfn>client</dfn> 
    875885      </p>
    876       <dl class="empty">
    877          <dd>A program that establishes connections for the purpose of sending requests.</dd>
    878       </dl>
     886      <ul class="empty">
     887         <li>A program that establishes connections for the purpose of sending requests.</li>
     888      </ul>
    879889      <p id="rfc.section.1.3.p.12"> <span id="rfc.iref.u.1"></span>  <dfn>user agent</dfn> 
    880890      </p>
    881       <dl class="empty">
    882          <dd>The client which initiates a request. These are often browsers, editors, spiders (web-traversing robots), or other end user
     891      <ul class="empty">
     892         <li>The client which initiates a request. These are often browsers, editors, spiders (web-traversing robots), or other end user
    883893            tools.
    884          </dd>
    885       </dl>
     894         </li>
     895      </ul>
    886896      <p id="rfc.section.1.3.p.13"> <span id="rfc.iref.s.1"></span>  <dfn>server</dfn> 
    887897      </p>
    888       <dl class="empty">
    889          <dd>An application program that accepts connections in order to service requests by sending back responses. Any given program
     898      <ul class="empty">
     899         <li>An application program that accepts connections in order to service requests by sending back responses. Any given program
    890900            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
    891901            program for a particular connection, rather than to the program's capabilities in general. Likewise, any server may act as
    892902            an origin server, proxy, gateway, or tunnel, switching behavior based on the nature of each request.
    893          </dd>
    894       </dl>
     903         </li>
     904      </ul>
    895905      <p id="rfc.section.1.3.p.14"> <span id="rfc.iref.o.1"></span>  <dfn>origin server</dfn> 
    896906      </p>
    897       <dl class="empty">
    898          <dd>The server on which a given resource resides or is to be created.</dd>
    899       </dl>
     907      <ul class="empty">
     908         <li>The server on which a given resource resides or is to be created.</li>
     909      </ul>
    900910      <p id="rfc.section.1.3.p.15"> <span id="rfc.iref.p.1"></span>  <dfn>proxy</dfn> 
    901911      </p>
    902       <dl class="empty">
    903          <dd>An intermediary program which acts as both a server and a client for the purpose of making requests on behalf of other clients.
     912      <ul class="empty">
     913         <li>An intermediary program which acts as both a server and a client for the purpose of making requests on behalf of other clients.
    904914            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
    905915            the request or response beyond what is required for proxy authentication and identification. A "non-transparent proxy" is
    … …  
    907917            services, media type transformation, protocol reduction, or anonymity filtering. Except where either transparent or non-transparent
    908918            behavior is explicitly stated, the HTTP proxy requirements apply to both types of proxies.
    909          </dd>
    910       </dl>
     919         </li>
     920      </ul>
    911921      <p id="rfc.section.1.3.p.16"> <span id="rfc.iref.g.1"></span>  <dfn>gateway</dfn> 
    912922      </p>
    913       <dl class="empty">
    914          <dd>A server which acts as an intermediary for some other server. Unlike a proxy, a gateway receives requests as if it were the
     923      <ul class="empty">
     924         <li>A server which acts as an intermediary for some other server. Unlike a proxy, a gateway receives requests as if it were the
    915925            origin server for the requested resource; the requesting client may not be aware that it is communicating with a gateway.
    916          </dd>
    917       </dl>
     926         </li>
     927      </ul>
    918928      <p id="rfc.section.1.3.p.17"> <span id="rfc.iref.t.1"></span>  <dfn>tunnel</dfn> 
    919929      </p>
    920       <dl class="empty">
    921          <dd>An intermediary program which is acting as a blind relay between two connections. Once active, a tunnel is not considered
     930      <ul class="empty">
     931         <li>An intermediary program which is acting as a blind relay between two connections. Once active, a tunnel is not considered
    922932            a party to the HTTP communication, though the tunnel may have been initiated by an HTTP request. The tunnel ceases to exist
    923933            when both ends of the relayed connections are closed.
    924          </dd>
    925       </dl>
     934         </li>
     935      </ul>
    926936      <p id="rfc.section.1.3.p.18"> <span id="rfc.iref.c.4"></span>  <dfn>cache</dfn> 
    927937      </p>
    928       <dl class="empty">
    929          <dd>A program's local store of response messages and the subsystem that controls its message storage, retrieval, and deletion.
     938      <ul class="empty">
     939         <li>A program's local store of response messages and the subsystem that controls its message storage, retrieval, and deletion.
    930940            A cache stores cacheable responses in order to reduce the response time and network bandwidth consumption on future, equivalent
    931941            requests. Any client or server may include a cache, though a cache cannot be used by a server that is acting as a tunnel.
    932          </dd>
    933       </dl>
     942         </li>
     943      </ul>
    934944      <p id="rfc.section.1.3.p.19"> <span id="rfc.iref.c.5"></span>  <dfn>cacheable</dfn> 
    935945      </p>
    936       <dl class="empty">
    937          <dd>A response is cacheable if a cache is allowed to store a copy of the response message for use in answering subsequent requests.
     946      <ul class="empty">
     947         <li>A response is cacheable if a cache is allowed to store a copy of the response message for use in answering subsequent requests.
    938948            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
    939949            request.
    940          </dd>
    941       </dl>
     950         </li>
     951      </ul>
    942952      <p id="rfc.section.1.3.p.20"> <span id="rfc.iref.f.1"></span>  <dfn>first-hand</dfn> 
    943953      </p>
    944       <dl class="empty">
    945          <dd>A response is first-hand if it comes directly and without unnecessary delay from the origin server, perhaps via one or more
     954      <ul class="empty">
     955         <li>A response is first-hand if it comes directly and without unnecessary delay from the origin server, perhaps via one or more
    946956            proxies. A response is also first-hand if its validity has just been checked directly with the origin server.
    947          </dd>
    948       </dl>
     957         </li>
     958      </ul>
    949959      <p id="rfc.section.1.3.p.21"> <span id="rfc.iref.e.2"></span>  <dfn>explicit expiration time</dfn> 
    950960      </p>
    951       <dl class="empty">
    952          <dd>The time at which the origin server intends that an entity should no longer be returned by a cache without further validation.</dd>
    953       </dl>
     961      <ul class="empty">
     962         <li>The time at which the origin server intends that an entity should no longer be returned by a cache without further validation.</li>
     963      </ul>
    954964      <p id="rfc.section.1.3.p.22"> <span id="rfc.iref.h.1"></span>  <dfn>heuristic expiration time</dfn> 
    955965      </p>
    956       <dl class="empty">
    957          <dd>An expiration time assigned by a cache when no explicit expiration time is available.</dd>
    958       </dl>
     966      <ul class="empty">
     967         <li>An expiration time assigned by a cache when no explicit expiration time is available.</li>
     968      </ul>
    959969      <p id="rfc.section.1.3.p.23"> <span id="rfc.iref.a.1"></span>  <dfn>age</dfn> 
    960970      </p>
    961       <dl class="empty">
    962          <dd>The age of a response is the time since it was sent by, or successfully validated with, the origin server.</dd>
    963       </dl>
     971      <ul class="empty">
     972         <li>The age of a response is the time since it was sent by, or successfully validated with, the origin server.</li>
     973      </ul>
    964974      <p id="rfc.section.1.3.p.24"> <span id="rfc.iref.f.2"></span>  <dfn>freshness lifetime</dfn> 
    965975      </p>
    966       <dl class="empty">
    967          <dd>The length of time between the generation of a response and its expiration time.</dd>
    968       </dl>
     976      <ul class="empty">
     977         <li>The length of time between the generation of a response and its expiration time.</li>
     978      </ul>
    969979      <p id="rfc.section.1.3.p.25"> <span id="rfc.iref.f.3"></span>  <dfn>fresh</dfn> 
    970980      </p>
    971       <dl class="empty">
    972          <dd>A response is fresh if its age has not yet exceeded its freshness lifetime.</dd>
    973       </dl>
     981      <ul class="empty">
     982         <li>A response is fresh if its age has not yet exceeded its freshness lifetime.</li>
     983      </ul>
    974984      <p id="rfc.section.1.3.p.26"> <span id="rfc.iref.s.2"></span>  <dfn>stale</dfn> 
    975985      </p>
    976       <dl class="empty">
    977          <dd>A response is stale if its age has passed its freshness lifetime.</dd>
    978       </dl>
     986      <ul class="empty">
     987         <li>A response is stale if its age has passed its freshness lifetime.</li>
     988      </ul>
    979989      <p id="rfc.section.1.3.p.27"> <span id="rfc.iref.s.3"></span>  <dfn>semantically transparent</dfn> 
    980990      </p>
    981       <dl class="empty">
    982          <dd>A cache behaves in a "semantically transparent" manner, with respect to a particular response, when its use affects neither
     991      <ul class="empty">
     992         <li>A cache behaves in a "semantically transparent" manner, with respect to a particular response, when its use affects neither
    983993            the requesting client nor the origin server, except to improve performance. When a cache is semantically transparent, the
    984994            client receives exactly the same response (except for hop-by-hop headers) that it would have received had its request been
    985995            handled directly by the origin server.
    986          </dd>
    987       </dl>
     996         </li>
     997      </ul>
    988998      <p id="rfc.section.1.3.p.28"> <span id="rfc.iref.v.2"></span>  <dfn>validator</dfn> 
    989999      </p>
    990       <dl class="empty">
    991          <dd>A protocol element (e.g., an entity tag or a Last-Modified time) that is used to find out whether a cache entry is an equivalent
     1000      <ul class="empty">
     1001         <li>A protocol element (e.g., an entity tag or a Last-Modified time) that is used to find out whether a cache entry is an equivalent
    9921002            copy of an entity.
    993          </dd>
    994       </dl>
     1003         </li>
     1004      </ul>
    9951005      <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> 
    9961006      </p>
    997       <dl class="empty">
    998          <dd>Upstream and downstream describe the flow of a message: all messages flow from upstream to downstream.</dd>
    999       </dl>
     1007      <ul class="empty">
     1008         <li>Upstream and downstream describe the flow of a message: all messages flow from upstream to downstream.</li>
     1009      </ul>
    10001010      <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> 
    10011011      </p>
    1002       <dl class="empty">
    1003          <dd>Inbound and outbound refer to the request and response paths for messages: "inbound" means "traveling toward the origin server",
     1012      <ul class="empty">
     1013         <li>Inbound and outbound refer to the request and response paths for messages: "inbound" means "traveling toward the origin server",
    10041014            and "outbound" means "traveling toward the user agent"
    1005          </dd>
    1006       </dl>
     1015         </li>
     1016      </ul>
    10071017      <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>
    10081018      <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,
    … …  
    10721082      </p>
    10731083      <p id="rfc.section.2.1.p.2">name = definition </p>
    1074       <dl class="empty">
    1075          <dd>The name of a rule is simply the name itself (without any enclosing "&lt;" and "&gt;") and is separated from its definition by the
     1084      <ul class="empty">
     1085         <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
    10761086            equal "=" character. White space is only significant in that indentation of continuation lines is used to indicate a rule
    10771087            definition that spans more than one line. Certain basic rules are in uppercase, such as <a href="#basic.rules" class="smpl" id="rfc.extref.s.1">SP</a>, <a href="#basic.rules.lws" class="smpl" id="rfc.extref.l.1">LWS</a>, <a href="#basic.rules" class="smpl" id="rfc.extref.h.1">HT</a>, <a href="#basic.rules.crlf" class="smpl" id="rfc.extref.c.1">CRLF</a>, <a href="#basic.rules" class="smpl" id="rfc.extref.d.1">DIGIT</a>, <a href="#basic.rules" class="smpl" id="rfc.extref.a.1">ALPHA</a>, etc. Angle brackets are used within definitions whenever their presence will facilitate discerning the use of rule names.
    1078          </dd>
    1079       </dl>
     1088         </li>
     1089      </ul>
    10801090      <p id="rfc.section.2.1.p.3">"literal" </p>
    1081       <dl class="empty">
    1082          <dd>Quotation marks surround literal text. Unless stated otherwise, the text is case-insensitive.</dd>
    1083       </dl>
     1091      <ul class="empty">
     1092         <li>Quotation marks surround literal text. Unless stated otherwise, the text is case-insensitive.</li>
     1093      </ul>
    10841094      <p id="rfc.section.2.1.p.4">rule1 | rule2 </p>
    1085       <dl class="empty">
    1086          <dd>Elements separated by a bar ("|") are alternatives, e.g., "yes | no" will accept yes or no.</dd>
    1087       </dl>
     1095      <ul class="empty">
     1096         <li>Elements separated by a bar ("|") are alternatives, e.g., "yes | no" will accept yes or no.</li>
     1097      </ul>
    10881098      <p id="rfc.section.2.1.p.5">(rule1 rule2) </p>
    1089       <dl class="empty">
    1090          <dd>Elements enclosed in parentheses are treated as a single element. Thus, "(elem (foo | bar) elem)" allows the token sequences
     1099      <ul class="empty">
     1100         <li>Elements enclosed in parentheses are treated as a single element. Thus, "(elem (foo | bar) elem)" allows the token sequences
    10911101            "elem foo elem" and "elem bar elem".
    1092          </dd>
    1093       </dl>
     1102         </li>
     1103      </ul>
    10941104      <p id="rfc.section.2.1.p.6">*rule </p>
    1095       <dl class="empty">
    1096          <dd>The character "*" preceding an element indicates repetition. The full form is "&lt;n&gt;*&lt;m&gt;element" indicating at least &lt;n&gt; and
     1105      <ul class="empty">
     1106         <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
    10971107            at most &lt;m&gt; occurrences of element. Default values are 0 and infinity so that "*(element)" allows any number, including zero;
    10981108            "1*element" requires at least one; and "1*2element" allows one or two.
    1099          </dd>
    1100       </dl>
     1109         </li>
     1110      </ul>
    11011111      <p id="rfc.section.2.1.p.7">[rule] </p>
    1102       <dl class="empty">
    1103          <dd>Square brackets enclose optional elements; "[foo bar]" is equivalent to "*1(foo bar)".</dd>
    1104       </dl>
     1112      <ul class="empty">
     1113         <li>Square brackets enclose optional elements; "[foo bar]" is equivalent to "*1(foo bar)".</li>
     1114      </ul>
    11051115      <p id="rfc.section.2.1.p.8">N rule </p>
    1106       <dl class="empty">
    1107          <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
     1116      <ul class="empty">
     1117         <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
    11081118            2DIGIT is a 2-digit number, and 3ALPHA is a string of three alphabetic characters.
    1109          </dd>
    1110       </dl>
     1119         </li>
     1120      </ul>
    11111121      <p id="rfc.section.2.1.p.9">#rule </p>
    1112       <dl class="empty">
    1113          <dd>A construct "#" is defined, similar to "*", for defining lists of elements. The full form is "&lt;n&gt;#&lt;m&gt;element" indicating at
     1122      <ul class="empty">
     1123         <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
    11141124            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
    11151125            <div id="rfc.figure.u.4"></div><pre class="text">   ( *LWS element *( *LWS "," *LWS element ))
    1116 </pre> </dd>
    1117          <dd>can be shown as
     1126</pre> </li>
     1127         <li>can be shown as
    11181128            <div id="rfc.figure.u.5"></div><pre class="text">   1#element
    1119 </pre> </dd>
    1120          <dd>Wherever this construct is used, null elements are allowed, but do not contribute to the count of elements present. That is,
     1129</pre> </li>
     1130         <li>Wherever this construct is used, null elements are allowed, but do not contribute to the count of elements present. That is,
    11211131            "(element), , (element) " is permitted, but counts as only two elements. Therefore, where at least one element is required,
    11221132            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
    11231133            least one; and "1#2element" allows one or two.
    1124          </dd>
    1125       </dl>
     1134         </li>
     1135      </ul>
    11261136      <p id="rfc.section.2.1.p.10">; comment </p>
    1127       <dl class="empty">
    1128          <dd>A semi-colon, set off some distance to the right of rule text, starts a comment that continues to the end of line. This is
     1137      <ul class="empty">
     1138         <li>A semi-colon, set off some distance to the right of rule text, starts a comment that continues to the end of line. This is
    11291139            a simple way of including useful notes in parallel with the specifications.
    1130          </dd>
    1131       </dl>
     1140         </li>
     1141      </ul>
    11321142      <div id="implied.LWS">
    11331143         <p id="rfc.section.2.1.p.11">implied *LWS </p>
    1134          <dl class="empty">
    1135             <dd>The grammar described by this specification is word-based. Except where noted otherwise, linear white space (LWS) can be included
     1144         <ul class="empty">
     1145            <li>The grammar described by this specification is word-based. Except where noted otherwise, linear white space (LWS) can be included
    11361146               between any two adjacent words (token or quoted-string), and between adjacent words and separators, without changing the interpretation
    11371147               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
    11381148               token.
    1139             </dd>
    1140          </dl>
     1149            </li>
     1150         </ul>
    11411151      </div>
    11421152      <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>
    … …  
    12371247      </p>
    12381248      <p id="rfc.section.3.1.p.9"> </p>
    1239       <dl class="empty">
    1240          <dd> <b>Note:</b> Converting between versions of HTTP may involve modification of header fields required or forbidden by the versions involved.
    1241          </dd>
    1242       </dl>
     1249      <ul class="empty">
     1250         <li> <b>Note:</b> Converting between versions of HTTP may involve modification of header fields required or forbidden by the versions involved.
     1251         </li>
     1252      </ul>
    12431253      <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>
    12441254      <p id="rfc.section.3.2.p.1">URIs have been known by many names: WWW addresses, Universal Document Identifiers, Universal Resource Identifiers <a href="#RFC1630" id="rfc.xref.RFC1630.2"><cite title="Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World-Wide Web">[3]</cite></a>, and finally the combination of Uniform Resource Locators (URL) <a href="#RFC1738" id="rfc.xref.RFC1738.2"><cite title="Uniform Resource Locators (URL)">[4]</cite></a> and Names (URN) <a href="#RFC1737" id="rfc.xref.RFC1737.2"><cite title="Functional Requirements for Uniform Resource Names">[20]</cite></a>. As far as HTTP is concerned, Uniform Resource Identifiers are simply formatted strings which identify--via name, location,
    … …  
    12541264      </p>
    12551265      <p id="rfc.section.3.2.1.p.3"> </p>
    1256       <dl class="empty">
    1257          <dd> <b>Note:</b> Servers ought to be cautious about depending on URI lengths above 255 bytes, because some older client or proxy implementations
     1266      <ul class="empty">
     1267         <li> <b>Note:</b> Servers ought to be cautious about depending on URI lengths above 255 bytes, because some older client or proxy implementations
    12581268            might not properly support these lengths.
    1259          </dd>
    1260       </dl>
     1269         </li>
     1270      </ul>
    12611271      <div id="rfc.iref.h.2"></div>
    12621272      <div id="rfc.iref.u.3"></div>
    … …  
    12941304</pre><p id="rfc.section.3.3.1.p.3">The first format is preferred as an Internet standard and represents a fixed-length subset of that defined by RFC 1123 <a href="#RFC1123" id="rfc.xref.RFC1123.1"><cite title="Requirements for Internet Hosts - Application and Support">[8]</cite></a> (an update to RFC 822 <a href="#RFC822" id="rfc.xref.RFC822.3"><cite title="Standard for the format of ARPA Internet text messages">[9]</cite></a>). The second format is in common use, but is based on the obsolete RFC 850 <a href="#RFC1036" id="rfc.xref.RFC1036.1"><cite title="Standard for interchange of USENET messages">[12]</cite></a> date format and lacks a four-digit year. HTTP/1.1 clients and servers that parse the date value <em class="bcp14">MUST</em> accept all three formats (for compatibility with HTTP/1.0), though they <em class="bcp14">MUST</em> only generate the RFC 1123 format for representing HTTP-date values in header fields. See <a href="#tolerant.applications" title="Tolerant Applications">Appendix&nbsp;19.3</a> for further information.
    12951305      </p>
    1296       <dl class="empty">
    1297          <dd> <b>Note:</b> Recipients of date values are encouraged to be robust in accepting date values that may have been sent by non-HTTP applications,
     1306      <ul class="empty">
     1307         <li> <b>Note:</b> Recipients of date values are encouraged to be robust in accepting date values that may have been sent by non-HTTP applications,
    12981308            as is sometimes the case when retrieving or posting messages via proxies/gateways to SMTP or NNTP.
    1299          </dd>
    1300       </dl>
     1309         </li>
     1310      </ul>
    13011311      <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
    13021312         Universal Time). This is indicated in the first two formats by the inclusion of "GMT" as the three-letter abbreviation for
    … …  
    13401350         to determine the exact mapping is not permitted.
    13411351      </p>
    1342       <dl class="empty">
    1343          <dd> <b>Note:</b> This use of the term "character set" is more commonly referred to as a "character encoding." However, since HTTP and MIME
     1352      <ul class="empty">
     1353         <li> <b>Note:</b> This use of the term "character set" is more commonly referred to as a "character encoding." However, since HTTP and MIME
    13441354            share the same registry, it is important that the terminology also be shared.
    1345          </dd>
    1346       </dl>
     1355         </li>
     1356      </ul>
    13471357      <div id="charset">
    13481358         <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
    … …  
    13791389      <p id="rfc.section.3.5.p.5">gzip<span id="rfc.iref.g.40"></span><span id="rfc.iref.c.7"></span> 
    13801390      </p>
    1381       <dl class="empty">
    1382          <dd>An encoding format produced by the file compression program "gzip" (GNU zip) as described in RFC 1952 <a href="#RFC1952" id="rfc.xref.RFC1952.1"><cite title="GZIP file format specification version 4.3">[25]</cite></a>. This format is a Lempel-Ziv coding (LZ77) with a 32 bit CRC.
    1383          </dd>
    1384       </dl>
     1391      <ul class="empty">
     1392         <li>An encoding format produced by the file compression program "gzip" (GNU zip) as described in RFC 1952 <a href="#RFC1952" id="rfc.xref.RFC1952.1"><cite title="GZIP file format specification version 4.3">[25]</cite></a>. This format is a Lempel-Ziv coding (LZ77) with a 32 bit CRC.
     1393         </li>
     1394      </ul>
    13851395      <p id="rfc.section.3.5.p.6">compress<span id="rfc.iref.c.8"></span><span id="rfc.iref.c.9"></span> 
    13861396      </p>
    1387       <dl class="empty">
    1388          <dd>The encoding format produced by the common UNIX file compression program "compress". This format is an adaptive Lempel-Ziv-Welch
     1397      <ul class="empty">
     1398         <li>The encoding format produced by the common UNIX file compression program "compress". This format is an adaptive Lempel-Ziv-Welch
    13891399            coding (LZW).
    1390          </dd>
    1391          <dd>Use of program names for the identification of encoding formats is not desirable and is discouraged for future encodings.
     1400         </li>
     1401         <li>Use of program names for the identification of encoding formats is not desirable and is discouraged for future encodings.
    13921402            Their use here is representative of historical practice, not good design. For compatibility with previous implementations
    13931403            of HTTP, applications <em class="bcp14">SHOULD</em> consider "x-gzip" and "x-compress" to be equivalent to "gzip" and "compress" respectively.
    1394          </dd>
    1395       </dl>
     1404         </li>
     1405      </ul>
    13961406      <p id="rfc.section.3.5.p.7">deflate<span id="rfc.iref.d.2"></span><span id="rfc.iref.c.10"></span> 
    13971407      </p>
    1398       <dl class="empty">
    1399          <dd>The "zlib" format defined in RFC 1950 <a href="#RFC1950" id="rfc.xref.RFC1950.1"><cite title="ZLIB Compressed Data Format Specification version 3.3">[31]</cite></a> in combination with the "deflate" compression mechanism described in RFC 1951 <a href="#RFC1951" id="rfc.xref.RFC1951.1"><cite title="DEFLATE Compressed Data Format Specification version 1.3">[29]</cite></a>.
    1400          </dd>
    1401       </dl>
     1408      <ul class="empty">
     1409         <li>The "zlib" format defined in RFC 1950 <a href="#RFC1950" id="rfc.xref.RFC1950.1"><cite title="ZLIB Compressed Data Format Specification version 3.3">[31]</cite></a> in combination with the "deflate" compression mechanism described in RFC 1951 <a href="#RFC1951" id="rfc.xref.RFC1951.1"><cite title="DEFLATE Compressed Data Format Specification version 1.3">[29]</cite></a>.
     1410         </li>
     1411      </ul>
    14021412      <p id="rfc.section.3.5.p.8">identity<span id="rfc.iref.i.2"></span><span id="rfc.iref.c.11"></span> 
    14031413      </p>
    1404       <dl class="empty">
    1405          <dd>The default (identity) encoding; the use of no transformation whatsoever. This content-coding is used only in the Accept-Encoding
     1414      <ul class="empty">
     1415         <li>The default (identity) encoding; the use of no transformation whatsoever. This content-coding is used only in the Accept-Encoding
    14061416            header, and <em class="bcp14">SHOULD NOT</em> be used in the Content-Encoding header.
    1407          </dd>
    1408       </dl>
     1417         </li>
     1418      </ul>
    14091419      <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
    14101420         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
    … …  
    15351545         an unrecognized multipart subtype, the application <em class="bcp14">MUST</em> treat it as being equivalent to "multipart/mixed".
    15361546      </p>
    1537       <dl class="empty">
    1538          <dd> <b>Note:</b> The "multipart/form-data" type has been specifically defined for carrying form data suitable for processing via the POST request
     1547      <ul class="empty">
     1548         <li> <b>Note:</b> The "multipart/form-data" type has been specifically defined for carrying form data suitable for processing via the POST request
    15391549            method, as described in RFC 1867 <a href="#RFC1867" id="rfc.xref.RFC1867.1"><cite title="Form-based File Upload in HTML">[15]</cite></a>.
    1540          </dd>
    1541       </dl>
     1550         </li>
     1551      </ul>
    15421552      <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>
    15431553      <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
    … …  
    16941704               can parse multipart/byteranges responses.
    16951705            </p>
    1696             <dl class="empty">
    1697                <dd>A range header might be forwarded by a 1.0 proxy that does not understand multipart/byteranges; in this case the server <em class="bcp14">MUST</em> delimit the message using methods defined in items 1, 3 or 5 of this section.
    1698                </dd>
    1699             </dl>
     1706            <ul class="empty">
     1707               <li>A range header might be forwarded by a 1.0 proxy that does not understand multipart/byteranges; in this case the server <em class="bcp14">MUST</em> delimit the message using methods defined in items 1, 3 or 5 of this section.
     1708               </li>
     1709            </ul>
    17001710         </li>
    17011711         <li>
    … …  
    17971807      </p>
    17981808      <p id="rfc.section.5.1.2.p.14"> </p>
    1799       <dl class="empty">
    1800          <dd> <b>Note:</b> The "no rewrite" rule prevents the proxy from changing the meaning of the request when the origin server is improperly using
     1809      <ul class="empty">
     1810         <li> <b>Note:</b> The "no rewrite" rule prevents the proxy from changing the meaning of the request when the origin server is improperly using
    18011811            a non-reserved URI character for a reserved purpose. Implementors should be aware that some pre-HTTP/1.1 proxies have been
    18021812            known to rewrite the Request-URI.
    1803          </dd>
    1804       </dl>
     1813         </li>
     1814      </ul>
    18051815      <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>
    18061816      <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>
    … …  
    24882498         GET or HEAD. A client <em class="bcp14">SHOULD</em> detect infinite redirection loops, since such loops generate network traffic for each redirection.
    24892499      </p>
    2490       <dl class="empty">
    2491          <dd> <b>Note:</b> previous versions of this specification recommended a maximum of five redirections. Content developers should be aware that
     2500      <ul class="empty">
     2501         <li> <b>Note:</b> previous versions of this specification recommended a maximum of five redirections. Content developers should be aware that
    24922502            there might be clients that implement such a fixed limitation.
    2493          </dd>
    2494       </dl>
     2503         </li>
     2504      </ul>
    24952505      <div id="rfc.iref.158"></div>
    24962506      <div id="rfc.iref.s.13"></div>
    … …  
    25172527         the request was issued.
    25182528      </p>
    2519       <dl class="empty">
    2520          <dd> <b>Note:</b> When automatically redirecting a POST request after receiving a 301 status code, some existing HTTP/1.0 user agents will erroneously
     2529      <ul class="empty">
     2530         <li> <b>Note:</b> When automatically redirecting a POST request after receiving a 301 status code, some existing HTTP/1.0 user agents will erroneously
    25212531            change it into a GET request.
    2522          </dd>
    2523       </dl>
     2532         </li>
     2533      </ul>
    25242534      <div id="rfc.iref.160"></div>
    25252535      <div id="rfc.iref.s.15"></div>
    … …  
    25342544         the request was issued.
    25352545      </p>
    2536       <dl class="empty">
    2537          <dd> <b>Note:</b> RFC 1945 and RFC 2068 specify that the client is not allowed to change the method on the redirected request. However, most
     2546      <ul class="empty">
     2547         <li> <b>Note:</b> RFC 1945 and RFC 2068 specify that the client is not allowed to change the method on the redirected request. However, most
    25382548            existing user agent implementations treat 302 as if it were a 303 response, performing a GET on the Location field-value regardless
    25392549            of the original request method. The status codes 303 and 307 have been added for servers that wish to make unambiguously clear
    25402550            which kind of reaction is expected of the client.
    2541          </dd>
    2542       </dl>
     2551         </li>
     2552      </ul>
    25432553      <div id="rfc.iref.161"></div>
    25442554      <div id="rfc.iref.s.16"></div>
    … …  
    25502560      <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).
    25512561      </p>
    2552       <dl class="empty">
    2553          <dd> <b>Note:</b> Many pre-HTTP/1.1 user agents do not understand the 303 status. When interoperability with such clients is a concern, the
     2562      <ul class="empty">
     2563         <li> <b>Note:</b> Many pre-HTTP/1.1 user agents do not understand the 303 status. When interoperability with such clients is a concern, the
    25542564            302 status code may be used instead, since most user agents react to a 302 response as described here for 303.
    2555          </dd>
    2556       </dl>
     2565         </li>
     2566      </ul>
    25572567      <div id="rfc.iref.162"></div>
    25582568      <div id="rfc.iref.s.17"></div>
    … …  
    25862596         expected to repeat this single request via the proxy. 305 responses <em class="bcp14">MUST</em> only be generated by origin servers.
    25872597      </p>
    2588       <dl class="empty">
    2589          <dd> <b>Note:</b> RFC 2068 was not clear that 305 was intended to redirect a single request, and to be generated by origin servers only. Not
     2598      <ul class="empty">
     2599         <li> <b>Note:</b> RFC 2068 was not clear that 305 was intended to redirect a single request, and to be generated by origin servers only. Not
    25902600            observing these limitations has significant security consequences.
    2591          </dd>
    2592       </dl>
     2601         </li>
     2602      </ul>
    25932603      <div id="rfc.iref.164"></div>
    25942604      <div id="rfc.iref.s.19"></div>
    … …  
    26642674         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.
    26652675      </p>
    2666       <dl class="empty">
    2667          <dd> <b>Note:</b> HTTP/1.1 servers are allowed to return responses which are not acceptable according to the accept headers sent in the request.
     2676      <ul class="empty">
     2677         <li> <b>Note:</b> HTTP/1.1 servers are allowed to return responses which are not acceptable according to the accept headers sent in the request.
    26682678            In some cases, this may even be preferable to sending a 406 response. User agents are encouraged to inspect the headers of
    26692679            an incoming response to determine if it is acceptable.
    2670          </dd>
    2671       </dl>
     2680         </li>
     2681      </ul>
    26722682      <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.
    26732683      </p>
    … …  
    27862796         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.
    27872797      </p>
    2788       <dl class="empty">
    2789          <dd> <b>Note:</b> The existence of the 503 status code does not imply that a server must use it when becoming overloaded. Some servers may wish
     2798      <ul class="empty">
     2799         <li> <b>Note:</b> The existence of the 503 status code does not imply that a server must use it when becoming overloaded. Some servers may wish
    27902800            to simply refuse the connection.
    2791          </dd>
    2792       </dl>
     2801         </li>
     2802      </ul>
    27932803      <div id="rfc.iref.188"></div>
    27942804      <div id="rfc.iref.s.43"></div>
    … …  
    27972807         URI (e.g. HTTP, FTP, LDAP) or some other auxiliary server (e.g. DNS) it needed to access in attempting to complete the request.
    27982808      </p>
    2799       <dl class="empty">
    2800          <dd> <b>Note:</b> Note to implementors: some deployed proxies are known to return 400 or 500 when DNS lookups time out.
    2801          </dd>
    2802       </dl>
     2809      <ul class="empty">
     2810         <li> <b>Note:</b> Note to implementors: some deployed proxies are known to return 400 or 500 when DNS lookups time out.
     2811         </li>
     2812      </ul>
    28032813      <div id="rfc.iref.189"></div>
    28042814      <div id="rfc.iref.s.44"></div>
    … …  
    28222832         best representation for a given response when there are multiple representations available.
    28232833      </p>
    2824       <dl class="empty">
    2825          <dd> <b>Note:</b> This is not called "format negotiation" because the alternate representations may be of the same media type, but use different
     2834      <ul class="empty">
     2835         <li> <b>Note:</b> This is not called "format negotiation" because the alternate representations may be of the same media type, but use different
    28262836            capabilities of that type, be in different languages, etc.
    2827          </dd>
    2828       </dl>
     2837         </li>
     2838      </ul>
    28292839      <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.
    28302840      </p>
    … …  
    29262936      </ol>
    29272937      <p id="rfc.section.13.p.5">A basic principle is that it must be possible for the clients to detect any potential relaxation of semantic transparency. </p>
    2928       <dl class="empty">
    2929          <dd> <b>Note:</b> The server, cache, or client implementor might be faced with design decisions not explicitly discussed in this specification.
     2938      <ul class="empty">
     2939         <li> <b>Note:</b> The server, cache, or client implementor might be faced with design decisions not explicitly discussed in this specification.
    29302940            If a decision might affect semantic transparency, the implementor ought to err on the side of maintaining transparency unless
    29312941            a careful and complete analysis shows significant benefits in breaking transparency.
    2932          </dd>
    2933       </dl>
     2942         </li>
     2943      </ul>
    29342944      <h2 id="rfc.section.13.1"><a href="#rfc.section.13.1">13.1</a>&nbsp;
    29352945      </h2>
    … …  
    32053215         either that a method be performed if and only if a validator matches or if and only if no validators match.
    32063216      </p>
    3207       <dl class="empty">
    3208          <dd> <b>Note:</b> a response that lacks a validator may still be cached, and served from cache until it expires, unless this is explicitly prohibited
     3217      <ul class="empty">
     3218         <li> <b>Note:</b> a response that lacks a validator may still be cached, and served from cache until it expires, unless this is explicitly prohibited
    32093219            by a cache-control directive. However, a cache cannot do a conditional retrieval if it does not have a validator for the entity,
    32103220            which means it will not be refreshable after it expires.
    3211          </dd>
    3212       </dl>
     3221         </li>
     3222      </ul>
    32133223      <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>
    32143224      <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
    … …  
    32373247         entity, while a weak validator is part of an identifier for a set of semantically equivalent entities.
    32383248      </p>
    3239       <dl class="empty">
    3240          <dd> <b>Note:</b> One example of a strong validator is an integer that is incremented in stable storage every time an entity is changed.
    3241          </dd>
    3242          <dd>An entity's modification time, if represented with one-second resolution, could be a weak validator, since it is possible
     3249      <ul class="empty">
     3250         <li> <b>Note:</b> One example of a strong validator is an integer that is incremented in stable storage every time an entity is changed.
     3251         </li>
     3252         <li>An entity's modification time, if represented with one-second resolution, could be a weak validator, since it is possible
    32433253            that the resource might be modified twice during a single second.
    3244          </dd>
    3245          <dd>Support for weak validators is optional. However, weak validators allow for more efficient caching of equivalent objects;
     3254         </li>
     3255         <li>Support for weak validators is optional. However, weak validators allow for more efficient caching of equivalent objects;
    32463256            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
    32473257            that period is likely "good enough" to be equivalent.
    3248          </dd>
    3249       </dl>
     3258         </li>
     3259      </ul>
    32503260      <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,
    32513261         or when a server compares two validators.
    … …  
    33243334      <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.
    33253335      </p>
    3326       <dl class="empty">
    3327          <dd> <b>Note:</b> in order to provide semantically transparent caching, an origin server must avoid reusing a specific strong entity tag value
     3336      <ul class="empty">
     3337         <li> <b>Note:</b> in order to provide semantically transparent caching, an origin server must avoid reusing a specific strong entity tag value
    33283338            for two different entities, or reusing a specific weak entity tag value for two semantically different entities. Cache entries
    33293339            might persist for arbitrarily long periods, regardless of expiration times, so it might be inappropriate to expect that a
    33303340            cache will never again attempt to validate an entry using a validator that it obtained at some point in the past.
    3331          </dd>
    3332       </dl>
     3341         </li>
     3342      </ul>
    33333343      <p id="rfc.section.13.3.4.p.5">HTTP/1.1 clients: </p>
    33343344      <ul>
    … …  
    33503360         fields in the request.
    33513361      </p>
    3352       <dl class="empty">
    3353          <dd> <b>Note:</b> The general principle behind these rules is that HTTP/1.1 servers and clients should transmit as much non-redundant information
     3362      <ul class="empty">
     3363         <li> <b>Note:</b> The general principle behind these rules is that HTTP/1.1 servers and clients should transmit as much non-redundant information
    33543364            as is available in their responses and requests. HTTP/1.1 systems receiving this information will make the most conservative
    33553365            assumptions about the validators they receive.
    3356          </dd>
    3357          <dd>HTTP/1.0 clients and caches will ignore entity tags. Generally, last-modified values received or used by these systems will
     3366         </li>
     3367         <li>HTTP/1.0 clients and caches will ignore entity tags. Generally, last-modified values received or used by these systems will
    33583368            support transparent and efficient caching, and so HTTP/1.1 origin servers should provide Last-Modified values. In those rare
    33593369            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
    33603370            HTTP/1.1 origin servers should not provide one.
    3361          </dd>
    3362       </dl>
     3371         </li>
     3372      </ul>
    33633373      <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>
    33643374      <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
    … …  
    33723382         such a response was taken from a cache by comparing the Date header to the current time.
    33733383      </p>
    3374       <dl class="empty">
    3375          <dd> <b>Note:</b> some HTTP/1.0 caches are known to violate this expectation without providing any Warning.
    3376          </dd>
    3377       </dl>
     3384      <ul class="empty">
     3385         <li> <b>Note:</b> some HTTP/1.0 caches are known to violate this expectation without providing any Warning.
     3386         </li>
     3387      </ul>
    33783388      <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
    33793389         request. This might be because absolute semantic transparency is deemed necessary by the service author, or because of security
    … …  
    34473457      <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>).
    34483458      </p>
    3449       <dl class="empty">
    3450          <dd> <b>Warning:</b> unnecessary modification of end-to-end headers might cause authentication failures if stronger authentication mechanisms are
     3459      <ul class="empty">
     3460         <li> <b>Warning:</b> unnecessary modification of end-to-end headers might cause authentication failures if stronger authentication mechanisms are
    34513461            introduced in later versions of HTTP. Such authentication mechanisms <em class="bcp14">MAY</em> rely on the values of header fields not listed here.
    3452          </dd>
    3453       </dl>
     3462         </li>
     3463      </ul>
    34543464      <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>).
    34553465      </p>
    … …  
    34773487         stored with the cache entry (except for stored Warning headers with warn-code 1xx, which are deleted even if not overridden).
    34783488      </p>
    3479       <dl class="empty">
    3480          <dd> <b>Note:</b> this rule allows an origin server to use a <a href="#status.304" class="smpl">304 (Not Modified)</a> or a <a href="#status.206" class="smpl">206 (Partial Content)</a> response to update any header associated with a previous response for the same entity or sub-ranges thereof, although it might
     3489      <ul class="empty">
     3490         <li> <b>Note:</b> this rule allows an origin server to use a <a href="#status.304" class="smpl">304 (Not Modified)</a> or a <a href="#status.206" class="smpl">206 (Partial Content)</a> response to update any header associated with a previous response for the same entity or sub-ranges thereof, although it might
    34813491            not always be meaningful or correct to do so. This rule does not allow an origin server to use a <a href="#status.304" class="smpl">304 (Not Modified)</a> or a <a href="#status.206" class="smpl">206 (Partial Content)</a> response to entirely delete a header that it had provided with a previous response.
    3482          </dd>
    3483       </dl>
     3492         </li>
     3493      </ul>
    34843494      <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>
    34853495      <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
    … …  
    35883598         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.
    35893599      </p>
    3590       <dl class="empty">
    3591          <dd> <b>Note:</b> a new response that has an older Date header value than existing cached responses is not cacheable.
    3592          </dd>
    3593       </dl>
     3600      <ul class="empty">
     3601         <li> <b>Note:</b> a new response that has an older Date header value than existing cached responses is not cacheable.
     3602         </li>
     3603      </ul>
    35943604      <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>
    35953605      <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
    … …  
    36033613      </p>
    36043614      <p id="rfc.section.13.13.p.4">This is not to be construed to prohibit the history mechanism from telling the user that a view might be stale. </p>
    3605       <dl class="empty">
    3606          <dd> <b>Note:</b> if history list mechanisms unnecessarily prevent users from viewing stale resources, this will tend to force service authors
     3615      <ul class="empty">
     3616         <li> <b>Note:</b> if history list mechanisms unnecessarily prevent users from viewing stale resources, this will tend to force service authors
    36073617            to avoid using HTTP expiration controls and cache controls when they would otherwise like to. Service authors may consider
    36083618            it important that users not be presented with error messages or warning messages when they use navigation controls (such as
    … …  
    36103620            user interface considerations may force service authors to resort to other means of preventing caching (e.g. "once-only" URLs)
    36113621            in order not to suffer the effects of improperly functioning history mechanisms.
    3612          </dd>
    3613       </dl>
     3622         </li>
     3623      </ul>
    36143624      <hr class="noprint">
    36153625      <h1 id="rfc.section.14" class="np"><a href="#rfc.section.14">14.</a>&nbsp;<a id="header.fields" href="#header.fields">Header Field Definitions</a></h1>
    … …  
    36403650         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.
    36413651      </p>
    3642       <dl class="empty">
    3643          <dd> <b>Note:</b> Use of the "q" parameter name to separate media type parameters from Accept extension parameters is due to historical practice.
     3652      <ul class="empty">
     3653         <li> <b>Note:</b> Use of the "q" parameter name to separate media type parameters from Accept extension parameters is due to historical practice.
    36443654            Although this prevents any media type parameter named "q" from being used with a media range, such an event is believed to
    36453655            be unlikely given the lack of any "q" parameters in the IANA media type registry and the rare usage of any media type parameters
    36463656            in Accept. Future media types are discouraged from registering any parameter named "q".
    3647          </dd>
    3648       </dl>
     3657         </li>
     3658      </ul>
    36493659      <p id="rfc.section.14.1.p.5">The example</p>
    36503660      <div id="rfc.figure.u.63"></div><pre class="text">    Accept: audio/*; q=0.2, audio/basic
    … …  
    37423752         client.
    37433753      </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
     3754      <ul class="empty">
     3755         <li> <b>Note:</b> If the request does not include an Accept-Encoding field, and if the "identity" content-coding is unavailable, then content-codings
    37463756            commonly understood by HTTP/1.0 clients (i.e., "gzip" and "compress") are preferred; some older clients improperly display
    37473757            messages sent with other content-codings. The server might also make this decision based on information about the particular
    37483758            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
     3759         </li>
     3760         <li> <b>Note:</b> Most HTTP/1.0 applications do not recognize or obey qvalues associated with content-codings. This means that qvalues will
    37513761            not work and are not permitted with x-gzip or x-compress.
    3752          </dd>
    3753       </dl>
     3762         </li>
     3763      </ul>
    37543764      <div id="rfc.iref.a.5"></div>
    37553765      <div id="rfc.iref.h.7"></div>
    … …  
    37703780         range present in the Accept-Language field.
    37713781      </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
     3782      <ul class="empty">
     3783         <li> <b>Note:</b> This use of a prefix matching rule does not imply that language tags are assigned to languages in such a way that it is always
    37743784            true that if a user understands a language with a certain tag, then this user will also understand all languages with tags
    37753785            for which this tag is a prefix. The prefix rule simply allows the use of prefix tags if this is the case.
    3776          </dd>
    3777       </dl>
     3786         </li>
     3787      </ul>
    37783788      <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
    37793789         in the field that matches the language-tag. If no language-range in the field matches the tag, the language quality factor
    … …  
    37873797         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.
    37883798      </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
     3799      <ul class="empty">
     3800         <li> <b>Note:</b> When making the choice of linguistic preference available to the user, we remind implementors of the fact that users are not
    37913801            familiar with the details of language matching as described above, and should provide appropriate guidance. As an example,
    37923802            users might assume that on selecting "en-gb", they will be served any kind of English document if British English is not available.
    37933803            A user agent might suggest in such a case to add "en" to get the best matching behavior.
    3794          </dd>
    3795       </dl>
     3804         </li>
     3805      </ul>
    37963806      <div id="rfc.iref.a.6"></div>
    37973807      <div id="rfc.iref.h.8"></div>
    … …  
    38713881         is to be given in the response.
    38723882      </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>
     3883      <ul class="empty">
     3884         <li>Note that HTTP/1.0 caches might not implement Cache-Control and might only implement Pragma: no-cache (see <a href="#header.pragma" id="rfc.xref.header.pragma.2" title="Pragma">Section&nbsp;14.32</a>).
     3885         </li>
     3886      </ul>
    38773887      <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
    38783888         might be applicable to all recipients along the request/response chain. It is not possible to specify a cache-directive for
    … …  
    39283938      <p id="rfc.section.14.9.1.p.2"> <span id="rfc.iref.c.14"></span>  <span id="rfc.iref.p.4"></span> public
    39293939      </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
     3940      <ul class="empty">
     3941         <li>Indicates that the response <em class="bcp14">MAY</em> be cached by any cache, even if it would normally be non-cacheable or cacheable only within a non-shared cache. (See also
    39323942            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>
     3943         </li>
     3944      </ul>
    39353945      <p id="rfc.section.14.9.1.p.3"> <span id="rfc.iref.c.15"></span>  <span id="rfc.iref.p.5"></span> private
    39363946      </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
     3947      <ul class="empty">
     3948         <li>Indicates that all or part of the response message is intended for a single user and <em class="bcp14">MUST NOT</em> be cached by a shared cache. This allows an origin server to state that the specified parts of the response are intended for
    39393949            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
     3950         </li>
     3951         <li> <b>Note:</b> This usage of the word private only controls where the response may be cached, and cannot ensure the privacy of the message
    39423952            content.
    3943          </dd>
    3944       </dl>
     3953         </li>
     3954      </ul>
    39453955      <p id="rfc.section.14.9.1.p.4"> <span id="rfc.iref.c.16"></span>  <span id="rfc.iref.n.1"></span> no-cache
    39463956      </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
     3957      <ul class="empty">
     3958         <li>If the no-cache directive does not specify a field-name, then a cache <em class="bcp14">MUST NOT</em> use the response to satisfy a subsequent request without successful revalidation with the origin server. This allows an origin
    39493959            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
     3960         </li>
     3961         <li>If the no-cache directive does specify one or more field-names, then a cache <em class="bcp14">MAY</em> use the response to satisfy a subsequent request, subject to any other restrictions on caching. However, the specified field-name(s) <em class="bcp14">MUST NOT</em> be sent in the response to a subsequent request without successful revalidation with the origin server. This allows an origin
    39523962            server to prevent the re-use of certain header fields in a response, while still allowing caching of the rest of the response.
    3953             <dl class="empty">
    3954                <dd> <b>Note:</b> Most HTTP/1.0 caches will not recognize or obey this directive.
    3955                </dd>
    3956             </dl>
    3957          </dd>
    3958       </dl>
     3963            <ul class="empty">
     3964               <li> <b>Note:</b> Most HTTP/1.0 caches will not recognize or obey this directive.
     3965               </li>
     3966            </ul>
     3967         </li>
     3968      </ul>
    39593969      <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>
    39603970      <p id="rfc.section.14.9.2.p.1"> <span id="rfc.iref.c.17"></span>  <span id="rfc.iref.n.2"></span> no-store
    39613971      </p>
    3962       <dl class="empty">
    3963          <dd>The purpose of the no-store directive is to prevent the inadvertent release or retention of sensitive information (for example,
     3972      <ul class="empty">
     3973         <li>The purpose of the no-store directive is to prevent the inadvertent release or retention of sensitive information (for example,
    39643974            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
    39653975            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
     3976         </li>
     3977         <li>Even when this directive is associated with a response, users might explicitly store such a response outside of the caching
    39683978            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
     3979         </li>
     3980         <li>The purpose of this directive is to meet the stated requirements of certain users and service authors who are concerned about
    39713981            accidental releases of information via unanticipated accesses to cache data structures. While the use of this directive might
    39723982            improve privacy in some cases, we caution that it is NOT in any way a reliable or sufficient mechanism for ensuring privacy.
    39733983            In particular, malicious or compromised caches might not recognize or obey this directive, and communications networks might
    39743984            be vulnerable to eavesdropping.
    3975          </dd>
    3976       </dl>
     3985         </li>
     3986      </ul>
    39773987      <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>
    39783988      <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,
    … …  
    39904000         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.
    39914001      </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
     4002      <ul class="empty">
     4003         <li> <b>Note:</b> An origin server might wish to use a relatively new HTTP cache control feature, such as the "private" directive, on a network
    39944004            including older caches that do not understand that feature. The origin server will need to combine the new feature with an
    39954005            Expires field whose value is less than or equal to the Date value. This will prevent older caches from improperly caching
    39964006            the response.
    3997          </dd>
    3998       </dl>
     4007         </li>
     4008      </ul>
    39994009      <p id="rfc.section.14.9.3.p.4"> <span id="rfc.iref.c.18"></span>  <span id="rfc.iref.s.45"></span> s-maxage
    40004010      </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
     4011      <ul class="empty">
     4012         <li>If a response includes an s-maxage directive, then for a shared cache (but not for a private cache), the maximum age specified
    40034013            by this directive overrides the maximum age specified by either the max-age directive or the Expires header. The s-maxage
    40044014            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
    40054015            revalidating it with the origin server. The s-maxage directive is always ignored by a private cache.
    4006          </dd>
    4007       </dl>
     4016         </li>
     4017      </ul>
    40084018      <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
    40094019         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
    … …  
    40144024      <p id="rfc.section.14.9.3.p.7"> <span id="rfc.iref.c.19"></span>  <span id="rfc.iref.m.10"></span> max-age
    40154025      </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
     4026      <ul class="empty">
     4027         <li>Indicates that the client is willing to accept a response whose age is no greater than the specified time in seconds. Unless
    40184028            max-stale directive is also included, the client is not willing to accept a stale response.
    4019          </dd>
    4020       </dl>
     4029         </li>
     4030      </ul>
    40214031      <p id="rfc.section.14.9.3.p.8"> <span id="rfc.iref.c.20"></span>  <span id="rfc.iref.m.11"></span> min-fresh
    40224032      </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
     4033      <ul class="empty">
     4034         <li>Indicates that the client is willing to accept a response whose freshness lifetime is no less than its current age plus the
    40254035            specified time in seconds. That is, the client wants a response that will still be fresh for at least the specified number
    40264036            of seconds.
    4027          </dd>
    4028       </dl>
     4037         </li>
     4038      </ul>
    40294039      <p id="rfc.section.14.9.3.p.9"> <span id="rfc.iref.c.21"></span>  <span id="rfc.iref.m.12"></span> max-stale
    40304040      </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
     4041      <ul class="empty">
     4042         <li>Indicates that the client is willing to accept a response that has exceeded its expiration time. If max-stale is assigned
    40334043            a value, then the client is willing to accept a response that has exceeded its expiration time by no more than the specified
    40344044            number of seconds. If no value is assigned to max-stale, then the client is willing to accept a stale response of any age.
    4035          </dd>
    4036       </dl>
     4045         </li>
     4046      </ul>
    40374047      <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
    40384048         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).
    … …  
    40564066      <p id="rfc.section.14.9.4.p.3">The client can specify these three kinds of action using Cache-Control request directives:</p>
    40574067      <p id="rfc.section.14.9.4.p.4">End-to-end reload </p>
    4058       <dl class="empty">
    4059          <dd>The request includes a "no-cache" cache-control directive or, for compatibility with HTTP/1.0 clients, "Pragma: no-cache".
     4068      <ul class="empty">
     4069         <li>The request includes a "no-cache" cache-control directive or, for compatibility with HTTP/1.0 clients, "Pragma: no-cache".
    40604070            Field names <em class="bcp14">MUST NOT</em> be included with the no-cache directive in a request. The server <em class="bcp14">MUST NOT</em> use a cached copy when responding to such a request.
    4061          </dd>
    4062       </dl>
     4071         </li>
     4072      </ul>
    40634073      <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
     4074      <ul class="empty">
     4075         <li>The request includes a "max-age=0" cache-control directive, which forces each cache along the path to the origin server to
    40664076            revalidate its own entry, if any, with the next cache or server. The initial request includes a cache-validating conditional
    40674077            with the client's current validator.
    4068          </dd>
    4069       </dl>
     4078         </li>
     4079      </ul>
    40704080      <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
     4081      <ul class="empty">
     4082         <li>The request includes "max-age=0" cache-control directive, which forces each cache along the path to the origin server to revalidate
    40734083            its own entry, if any, with the next cache or server. The initial request does not include a cache-validating conditional;
    40744084            the first cache along the path (if any) that holds a cache entry for this resource includes a cache-validating conditional
    40754085            with its current validator.
    4076          </dd>
    4077       </dl>
     4086         </li>
     4087      </ul>
    40784088      <p id="rfc.section.14.9.4.p.7"> <span id="rfc.iref.c.22"></span>  <span id="rfc.iref.m.13"></span> max-age
    40794089      </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
     4090      <ul class="empty">
     4091         <li>When an intermediate cache is forced, by means of a max-age=0 directive, to revalidate its own cache entry, and the client
    40824092            has supplied its own validator in the request, the supplied validator might differ from the validator currently stored with
    40834093            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
     4094         </li>
     4095         <li>However, the choice of validator might affect performance. The best approach is for the intermediate cache to use its own
    40864096            validator when making its request. If the server replies with 304 (Not Modified), then the cache can return its now validated
    40874097            copy to the client with a <a href="#status.200" class="smpl">200 (OK)</a> response. If the server replies with a new entity and cache validator, however, the intermediate cache can compare the returned
    40884098            validator with the one provided in the client's request, using the strong comparison function. If the client's validator is
    40894099            equal to the origin server's, then the intermediate cache simply returns <a href="#status.304" class="smpl">304 (Not Modified)</a>. Otherwise, it returns the new entity with a <a href="#status.200" class="smpl">200 (OK)</a> response.
    4090          </dd>
    4091          <dd>If a request includes the no-cache directive, it <em class="bcp14">SHOULD NOT</em> include min-fresh, max-stale, or max-age.
    4092          </dd>
    4093       </dl>
     4100         </li>
     4101         <li>If a request includes the no-cache directive, it <em class="bcp14">SHOULD NOT</em> include min-fresh, max-stale, or max-age.
     4102         </li>
     4103      </ul>
    40944104      <p id="rfc.section.14.9.4.p.8"> <span id="rfc.iref.c.23"></span>  <span id="rfc.iref.o.4"></span> only-if-cached
    40954105      </p>
    4096       <dl class="empty">
    4097          <dd>In some cases, such as times of extremely poor network connectivity, a client may want a cache to return only those responses
     4106      <ul class="empty">
     4107         <li>In some cases, such as times of extremely poor network connectivity, a client may want a cache to return only those responses
    40984108            that it currently has stored, and not to reload or revalidate with the origin server. To do this, the client may include the
    40994109            only-if-cached directive in a request. If it receives this directive, a cache <em class="bcp14">SHOULD</em> either respond using a cached entry that is consistent with the other constraints of the request, or respond with a <a href="#status.504" class="smpl">504 (Gateway Timeout)</a> status. However, if a group of caches is being operated as a unified system with good internal connectivity, such a request <em class="bcp14">MAY</em> be forwarded within that group of caches.
    4100          </dd>
    4101       </dl>
     4110         </li>
     4111      </ul>
    41024112      <p id="rfc.section.14.9.4.p.9"> <span id="rfc.iref.c.24"></span>  <span id="rfc.iref.m.14"></span> must-revalidate
    41034113      </p>
    4104       <dl class="empty">
    4105          <dd>Because a cache <em class="bcp14">MAY</em> be configured to ignore a server's specified expiration time, and because a client request <em class="bcp14">MAY</em> include a max-stale directive (which has a similar effect), the protocol also includes a mechanism for the origin server 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
    41064116            require revalidation of a cache entry on any subsequent use. When the must-revalidate directive is present in a response received
    41074117            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.
    41084118            (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
    41094119            is stale.)
    4110          </dd>
    4111          <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
    41124122            an HTTP/1.1 cache <em class="bcp14">MUST</em> obey the must-revalidate directive; in particular, if the cache cannot reach the origin server for any reason, it <em class="bcp14">MUST</em> generate a <a href="#status.504" class="smpl">504 (Gateway Timeout)</a> response.
    4113          </dd>
    4114          <dd>Servers <em class="bcp14">SHOULD</em> send the must-revalidate directive if and only if failure to revalidate a request on the entity could result in 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
    41154125            operation, such as a silently unexecuted financial transaction. Recipients <em class="bcp14">MUST NOT</em> take any automated action that violates this directive, and <em class="bcp14">MUST NOT</em> automatically provide an unvalidated copy of the entity if revalidation fails.
    4116          </dd>
    4117          <dd>Although this is not recommended, user agents operating under severe connectivity constraints <em class="bcp14">MAY</em> violate this directive but, if so, <em class="bcp14">MUST</em> explicitly warn the user that an unvalidated response has been provided. The warning <em class="bcp14">MUST</em> be provided on each unvalidated access, and <em class="bcp14">SHOULD</em> require explicit user confirmation.
    4118          </dd>
    4119       </dl>
     4126         </li>
     4127         <li>Although this is not recommended, user agents operating under severe connectivity constraints <em class="bcp14">MAY</em> violate this directive but, if so, <em class="bcp14">MUST</em> explicitly warn the user that an unvalidated response has been provided. The warning <em class="bcp14">MUST</em> be provided on each unvalidated access, and <em class="bcp14">SHOULD</em> require explicit user confirmation.
     4128         </li>
     4129      </ul>
    41204130      <p id="rfc.section.14.9.4.p.10"> <span id="rfc.iref.c.25"></span>  <span id="rfc.iref.p.6"></span> proxy-revalidate
    41214131      </p>
    4122       <dl class="empty">
    4123          <dd>The proxy-revalidate directive has the same meaning as the must-revalidate directive, except that it does not apply to non-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
    41244134            user agent caches. It can be used on a response to an authenticated request to permit the user's cache to store and later
    41254135            return the response without needing to revalidate it (since it has already been authenticated once by that user), while still
    … …  
    41274137            Note that such authenticated responses also need the public cache control directive in order to allow them to be cached at
    41284138            all.
    4129          </dd>
    4130       </dl>
     4139         </li>
     4140      </ul>
    41314141      <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>
    41324142      <p id="rfc.section.14.9.5.p.1"> <span id="rfc.iref.c.26"></span>  <span id="rfc.iref.n.3"></span> no-transform
    41334143      </p>
    4134       <dl class="empty">
    4135          <dd>Implementors of intermediate caches (proxies) have found it useful to convert the media type of certain entity bodies. A non-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
    41364146            proxy might, for example, convert between image formats in order to save cache space or to reduce the amount of traffic on
    41374147            a slow link.
    4138          </dd>
    4139          <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
    41404150            kinds of applications. For example, applications for medical imaging, scientific data analysis and those using end-to-end
    41414151            authentication, all depend on receiving an entity body that is bit for bit identical to the original entity-body.
    4142          </dd>
    4143          <dd>Therefore, if a message includes the no-transform directive, an intermediate cache or proxy <em class="bcp14">MUST NOT</em> change those headers that are listed in <a href="#non-modifiable.headers" title="Non-modifiable Headers">Section&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.
    4144          </dd>
    4145       </dl>
     4152         </li>
     4153         <li>Therefore, if a message includes the no-transform directive, an intermediate cache or proxy <em class="bcp14">MUST NOT</em> change those headers that are listed in <a href="#non-modifiable.headers" title="Non-modifiable Headers">Section&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>
    41464156      <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>
    41474157      <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
    … …  
    43084318      <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.
    43094319      </p>
    4310       <dl class="empty">
    4311          <dd> <b>Note:</b> while the definition of Content-MD5 is exactly the same for HTTP as in RFC 1864 for MIME entity-bodies, there are 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
    43124322            ways in which the application of Content-MD5 to HTTP entity-bodies differs from its application to MIME entity-bodies. One
    43134323            is that HTTP, unlike MIME, does not use Content-Transfer-Encoding, and does use Transfer-Encoding and Content-Encoding. Another
    … …  
    43154325            used to compute the digest is the transmission byte order defined for the type. Lastly, HTTP allows transmission of text types
    43164326            with any of several line break conventions and not just the canonical form using CRLF.
    4317          </dd>
    4318       </dl>
     4327         </li>
     4328      </ul>
    43194329      <div id="rfc.iref.c.33"></div>
    43204330      <div id="rfc.iref.h.19"></div>
    … …  
    43844394         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>).
    43854395      </p>
    4386       <dl class="empty">
    4387          <dd> <b>Note:</b> clients cannot depend on servers to send a <a href="#status.416" class="smpl">416 (Requested range not satisfiable)</a> response instead of a <a href="#status.200" class="smpl">200 (OK)</a> response for an unsatisfiable Range request-header, since not all servers implement this request-header.
    4388          </dd>
    4389       </dl>
     4396      <ul class="empty">
     4397         <li> <b>Note:</b> clients cannot depend on servers to send a <a href="#status.416" class="smpl">416 (Requested range not satisfiable)</a> response instead of a <a href="#status.200" class="smpl">200 (OK)</a> response for an unsatisfiable Range request-header, since not all servers implement this request-header.
     4398         </li>
     4399      </ul>
    43904400      <div id="rfc.iref.c.34"></div>
    43914401      <div id="rfc.iref.h.20"></div>
    … …  
    44864496      <div id="rfc.figure.u.109"></div><pre class="text">   Expires: Thu, 01 Dec 1994 16:00:00 GMT
    44874497</pre><p id="rfc.section.14.21.p.7"> </p>
    4488       <dl class="empty">
    4489          <dd> <b>Note:</b> if a response includes a Cache-Control field with the max-age directive (see <a href="#modifications.of.the.basic.expiration.mechanism" title="Modifications of the Basic Expiration Mechanism">Section&nbsp;14.9.3</a>), that directive overrides the Expires field.
    4490          </dd>
    4491       </dl>
     4498      <ul class="empty">
     4499         <li> <b>Note:</b> if a response includes a Cache-Control field with the max-age directive (see <a href="#modifications.of.the.basic.expiration.mechanism" title="Modifications of the Basic Expiration Mechanism">Section&nbsp;14.9.3</a>), that directive overrides the Expires field.
     4500         </li>
     4501      </ul>
    44924502      <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").
    44934503      </p>
    … …  
    45974607      </ol>
    45984608      <p id="rfc.section.14.25.p.6">The purpose of this feature is to allow efficient updates of cached information with a minimum amount of transaction overhead. </p>
    4599       <dl class="empty">
    4600          <dd> <b>Note:</b> The Range request-header field modifies the meaning of If-Modified-Since; see <a href="#header.range" id="rfc.xref.header.range.6" title="Range">Section&nbsp;14.35</a> for full details.
    4601          </dd>
    4602          <dd> <b>Note:</b> If-Modified-Since times are interpreted by the server, whose clock might not be synchronized with the client.
    4603          </dd>
    4604          <dd> <b>Note:</b> When handling an If-Modified-Since header field, some servers will use an exact date comparison function, rather than a less-than
     4609      <ul class="empty">
     4610         <li> <b>Note:</b> The Range request-header field modifies the meaning of If-Modified-Since; see <a href="#header.range" id="rfc.xref.header.range.6" title="Range">Section&nbsp;14.35</a> for full details.
     4611         </li>
     4612         <li> <b>Note:</b> If-Modified-Since times are interpreted by the server, whose clock might not be synchronized with the client.
     4613         </li>
     4614         <li> <b>Note:</b> When handling an If-Modified-Since header field, some servers will use an exact date comparison function, rather than a less-than
    46054615            function, for deciding whether to send a 304 (Not Modified) response. To get best results when sending an If-Modified-Since
    46064616            header field for cache validation, clients are advised to use the exact date string received in a previous Last-Modified header
    46074617            field whenever possible.
    4608          </dd>
    4609          <dd> <b>Note:</b> If a client uses an arbitrary date in the If-Modified-Since header instead of a date taken from the Last-Modified header for
     4618         </li>
     4619         <li> <b>Note:</b> If a client uses an arbitrary date in the If-Modified-Since header instead of a date taken from the Last-Modified header for
    46104620            the same request, the client should be aware of the fact that this date is interpreted in the server's understanding of time.
    46114621            The client should consider unsynchronized clocks and rounding problems due to the different encodings of time between the
    … …  
    46144624            If-Modified-Since date is derived from the client's clock without correction to the server's clock. Corrections for different
    46154625            time bases between client and server are at best approximate due to network latency.
    4616          </dd>
    4617       </dl>
     4626         </li>
     4627      </ul>
    46184628      <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
    46194629         fields is undefined by this specification.
    … …  
    47234733      <div id="rfc.figure.u.126"></div><pre class="text">    Location: http://www.w3.org/pub/WWW/People.html
    47244734</pre><p id="rfc.section.14.30.p.5"> </p>
    4725       <dl class="empty">
    4726          <dd> <b>Note:</b> The Content-Location header field (<a href="#header.content-location" id="rfc.xref.header.content-location.2" title="Content-Location">Section&nbsp;14.14</a>) differs from Location in that the Content-Location identifies the original location of the entity enclosed in the request.
     4735      <ul class="empty">
     4736         <li> <b>Note:</b> The Content-Location header field (<a href="#header.content-location" id="rfc.xref.header.content-location.2" title="Content-Location">Section&nbsp;14.14</a>) differs from Location in that the Content-Location identifies the original location of the entity enclosed in the request.
    47274737            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.
    4728          </dd>
    4729       </dl>
     4738         </li>
     4739      </ul>
    47304740      <div id="rfc.iref.m.15"></div>
    47314741      <div id="rfc.iref.h.35"></div>
    … …  
    47614771         HTTP.
    47624772      </p>
    4763       <dl class="empty">
    4764          <dd> <b>Note:</b> because the meaning of "Pragma: no-cache as a response header field is not actually specified, it does not provide a reliable
     4773      <ul class="empty">
     4774         <li> <b>Note:</b> because the meaning of "Pragma: no-cache as a response header field is not actually specified, it does not provide a reliable
    47654775            replacement for "Cache-Control: no-cache" in a response
    4766          </dd>
    4767       </dl>
     4776         </li>
     4777      </ul>
    47684778      <div id="rfc.iref.p.8"></div>
    47694779      <div id="rfc.iref.h.37"></div>
    … …  
    48994909</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>).
    49004910      </p>
    4901       <dl class="empty">
    4902          <dd> <b>Note:</b> Revealing the specific software version of the server might allow the server machine to become more vulnerable to attacks
     4911      <ul class="empty">
     4912         <li> <b>Note:</b> Revealing the specific software version of the server might allow the server machine to become more vulnerable to attacks
    49034913            against software that is known to contain security holes. Server implementors are encouraged to make this field a configurable
    49044914            option.
    4905          </dd>
    4906       </dl>
     4915         </li>
     4916      </ul>
    49074917      <div id="rfc.iref.t.3"></div>
    49084918      <div id="rfc.iref.h.43"></div>
    … …  
    51405150      <p id="rfc.section.14.46.p.12"> <span id="rfc.iref.395"></span>  <span id="rfc.iref.w.2"></span> 110 Response is stale
    51415151      </p>
    5142       <dl class="empty">
    5143          <dd> <em class="bcp14">MUST</em> be included whenever the returned response is stale.
    5144          </dd>
    5145       </dl>
     5152      <ul class="empty">
     5153         <li> <em class="bcp14">MUST</em> be included whenever the returned response is stale.
     5154         </li>
     5155      </ul>
    51465156      <p id="rfc.section.14.46.p.13"> <span id="rfc.iref.396"></span>  <span id="rfc.iref.w.3"></span> 111 Revalidation failed
    51475157      </p>
    5148       <dl class="empty">
    5149          <dd> <em class="bcp14">MUST</em> be included if a cache returns a stale response because an attempt to revalidate the response failed, due to an inability
     5158      <ul class="empty">
     5159         <li> <em class="bcp14">MUST</em> be included if a cache returns a stale response because an attempt to revalidate the response failed, due to an inability
    51505160            to reach the server.
    5151          </dd>
    5152       </dl>
     5161         </li>
     5162      </ul>
    51535163      <p id="rfc.section.14.46.p.14"> <span id="rfc.iref.397"></span>  <span id="rfc.iref.w.4"></span> 112 Disconnected operation
    51545164      </p>
    5155       <dl class="empty">
    5156          <dd> <em class="bcp14">SHOULD</em> be included if the cache is intentionally disconnected from the rest of the network for a period of time.
    5157          </dd>
    5158       </dl>
     5165      <ul class="empty">
     5166         <li> <em class="bcp14">SHOULD</em> be included if the cache is intentionally disconnected from the rest of the network for a period of time.
     5167         </li>
     5168      </ul>
    51595169      <p id="rfc.section.14.46.p.15"> <span id="rfc.iref.398"></span>  <span id="rfc.iref.w.5"></span> 113 Heuristic expiration
    51605170      </p>
    5161       <dl class="empty">
    5162          <dd> <em class="bcp14">MUST</em> be included if the cache heuristically chose a freshness lifetime greater than 24 hours and the response's age is greater
     5171      <ul class="empty">
     5172         <li> <em class="bcp14">MUST</em> be included if the cache heuristically chose a freshness lifetime greater than 24 hours and the response's age is greater
    51635173            than 24 hours.
    5164          </dd>
    5165       </dl>
     5174         </li>
     5175      </ul>
    51665176      <p id="rfc.section.14.46.p.16"> <span id="rfc.iref.399"></span>  <span id="rfc.iref.w.6"></span> 199 Miscellaneous warning
    51675177      </p>
    5168       <dl class="empty">
    5169          <dd>The warning text <em class="bcp14">MAY</em> include arbitrary information to be presented to a human user, or logged. A system receiving this warning <em class="bcp14">MUST NOT</em> take any automated action, besides presenting the warning to the user.
    5170          </dd>
    5171       </dl>
     5178      <ul class="empty">
     5179         <li>The warning text <em class="bcp14">MAY</em> include arbitrary information to be presented to a human user, or logged. A system receiving this warning <em class="bcp14">MUST NOT</em> take any automated action, besides presenting the warning to the user.
     5180         </li>
     5181      </ul>
    51725182      <p id="rfc.section.14.46.p.17"> <span id="rfc.iref.400"></span>  <span id="rfc.iref.w.7"></span> 214 Transformation applied
    51735183      </p>
    5174       <dl class="empty">
    5175          <dd> <em class="bcp14">MUST</em> be added by an intermediate cache or proxy if it applies any transformation changing the content-coding (as specified in 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
    51765186            Content-Encoding header) or media-type (as specified in the Content-Type header) of the response, or the entity-body of the
    51775187            response, unless this Warning code already appears in the response.
    5178          </dd>
    5179       </dl>
     5188         </li>
     5189      </ul>
    51805190      <p id="rfc.section.14.46.p.18"> <span id="rfc.iref.401"></span>  <span id="rfc.iref.w.8"></span> 299 Miscellaneous persistent warning
    51815191      </p>
    5182       <dl class="empty">
    5183          <dd>The warning text <em class="bcp14">MAY</em> include arbitrary information to be presented to a human user, or logged. A system receiving this warning <em class="bcp14">MUST NOT</em> take any automated action.
    5184          </dd>
    5185       </dl>
     5192      <ul class="empty">
     5193         <li>The warning text <em class="bcp14">MAY</em> include arbitrary information to be presented to a human user, or logged. A system receiving this warning <em class="bcp14">MUST NOT</em> take any automated action.
     5194         </li>
     5195      </ul>
    51865196      <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.
    51875197      </p>
    … …  
    54155425      <h1 class="np" id="rfc.references"><a href="#rfc.section.17" id="rfc.section.17">17.</a> References
    54165426      </h1>
    5417       <table summary="References">
     5427      <table>
    54185428         <tr>
    54195429            <td class="reference"><b id="RFC1766">[1]</b></td>
    … …  
    54375447            </td>
    54385448         </tr> 
    5439          <!--WARNING: unused reference 'RFC1866'-->
    54405449         <tr>
    54415450            <td class="reference"><b id="RFC1866">[5]</b></td>
    5442             <td class="top"><a href="mailto:timbl@w3.org" title="MIT Laboratory for Computer Science">Berners-Lee, T.</a> and <a href="mailto:connolly@w3.org" title="MIT Laboratory for Computer Science, W3 Consortium">D.W. Connolly</a>, “<a href="http://tools.ietf.org/html/rfc1866">Hypertext Markup Language - 2.0</a>”, RFC&nbsp;1866, November&nbsp;1995.
     5451            <td class="top"><a href="mailto:timbl@w3.org" title="MIT Laboratory for Computer Science">Berners-Lee, T.</a> and <a href="mailto:connolly@w3.org" title="MIT Laboratory for Computer Science, W3 Consortium">D. Connolly</a>, “<a href="http://tools.ietf.org/html/rfc1866">Hypertext Markup Language - 2.0</a>”, RFC&nbsp;1866, November&nbsp;1995.
    54435452            </td>
    54445453         </tr> 
    54455454         <tr>
    54465455            <td class="reference"><b id="RFC1945">[6]</b></td>
    5447             <td class="top"><a href="mailto:timbl@w3.org" title="MIT, Laboratory for Computer Science">Berners-Lee, T.</a>, <a href="mailto:fielding@ics.uci.edu" title="University of California, Irvine, Department of Information and Computer Science">Fielding, R.T.</a>, and <a href="mailto:frystyk@w3.org" title="W3 Consortium, MIT Laboratory for Computer Science">H.F. Nielsen</a>, “<a href="http://tools.ietf.org/html/rfc1945">Hypertext Transfer Protocol -- HTTP/1.0</a>”, RFC&nbsp;1945, May&nbsp;1996.
     5456            <td class="top"><a href="mailto:timbl@w3.org" title="MIT, Laboratory for Computer Science">Berners-Lee, T.</a>, <a href="mailto:fielding@ics.uci.edu" title="University of California, Irvine, Department of Information and Computer Science">Fielding, R.</a>, and <a href="mailto:frystyk@w3.org" title="W3 Consortium, MIT Laboratory for Computer Science">H. Nielsen</a>, “<a href="http://tools.ietf.org/html/rfc1945">Hypertext Transfer Protocol -- HTTP/1.0</a>”, RFC&nbsp;1945, May&nbsp;1996.
    54485457            </td>
    54495458         </tr> 
    54505459         <tr>
    54515460            <td class="reference"><b id="RFC2045">[7]</b></td>
    5452             <td class="top"><a href="mailto:ned@innosoft.com" title="Innosoft International, Inc.">Freed, N.</a> and <a href="mailto:nsb@nsb.fv.com" title="First Virtual Holdings">N.S. Borenstein</a>, “<a href="http://tools.ietf.org/html/rfc2045">Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies</a>”, RFC&nbsp;2045, November&nbsp;1996.
     5461            <td class="top"><a href="mailto:ned@innosoft.com" title="Innosoft International, Inc.">Freed, N.</a> and <a href="mailto:nsb@nsb.fv.com" title="First Virtual Holdings">N. Borenstein</a>, “<a href="http://tools.ietf.org/html/rfc2045">Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies</a>”, RFC&nbsp;2045, November&nbsp;1996.
    54535462            </td>
    54545463         </tr> 
    … …  
    54605469         <tr>
    54615470            <td class="reference"><b id="RFC822">[9]</b></td>
    5462             <td class="top"><a href="mailto:DCrocker@UDel-Relay" title="University of Delaware, Dept. of Electrical Engineering">Crocker, D.H.</a>, “<a href="http://tools.ietf.org/html/rfc822">Standard for the format of ARPA Internet text messages</a>”, STD&nbsp;11, RFC&nbsp;822, August&nbsp;1982.
     5471            <td class="top"><a href="mailto:DCrocker@UDel-Relay" title="University of Delaware, Dept. of Electrical Engineering">Crocker, D.</a>, “<a href="http://tools.ietf.org/html/rfc822">Standard for the format of ARPA Internet text messages</a>”, STD&nbsp;11, RFC&nbsp;822, August&nbsp;1982.
    54635472            </td>
    54645473         </tr> 
    … …  
    54945503         <tr>
    54955504            <td class="reference"><b id="RFC821">[16]</b></td>
    5496             <td class="top">Postel, J.B., “<a href="http://tools.ietf.org/html/rfc821">Simple Mail Transfer Protocol</a>”, STD&nbsp;10, RFC&nbsp;821, August&nbsp;1982.
     5505            <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.
    54975506            </td>
    54985507         </tr> 
    … …  
    55235532         <tr>
    55245533            <td class="reference"><b id="ISO-8859">[22]</b></td>
    5525             <td class="top">International Organization for Standardization, “Information technology - 8-bit single byte coded graphic - character sets”
    5526                <!--WARNING: date/@year should be a number: '1987-1990' in reference 'ISO-8859'-->, 1987-1990.<br>Part 1: Latin alphabet No. 1, ISO-8859-1:1987. Part 2: Latin alphabet No. 2, ISO-8859-2, 1987. Part 3: Latin alphabet No.
     5534            <td class="top">International Organization for Standardization, “Information technology - 8-bit single byte coded graphic - character sets”, 1987-1990.<br>Part 1: Latin alphabet No. 1, ISO-8859-1:1987. Part 2: Latin alphabet No. 2, ISO-8859-2, 1987. Part 3: Latin alphabet No.
    55275535               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
    55285536               6: Latin/Arabic alphabet, ISO-8859-6, 1987. Part 7: Latin/Greek alphabet, ISO-8859-7, 1987. Part 8: Latin/Hebrew alphabet,
    … …  
    55425550         <tr>
    55435551            <td class="reference"><b id="RFC1952">[25]</b></td>
    5544             <td class="top"><a href="mailto:ghost@aladdin.com" title="Aladdin Enterprises">Deutsch, P.</a>, <a href="mailto:gzip@prep.ai.mit.edu">Gailly, J-L.</a>, <a href="mailto:madler@alumni.caltech.edu">Adler, M.</a>, <a href="mailto:ghost@aladdin.com">Deutsch, L.P.</a>, and <a href="mailto:randeg@alumni.rpi.edu">G. Randers-Pehrson</a>, “<a href="http://tools.ietf.org/html/rfc1952">GZIP file format specification version 4.3</a>”, RFC&nbsp;1952, May&nbsp;1996.
     5552            <td class="top"><a href="mailto:ghost@aladdin.com" title="Aladdin Enterprises">Deutsch, P.</a>, <a href="mailto:gzip@prep.ai.mit.edu">Gailly, J-L.</a>, <a href="mailto:madler@alumni.caltech.edu">Adler, M.</a>, <a href="mailto:ghost@aladdin.com">Deutsch, L.</a>, and <a href="mailto:randeg@alumni.rpi.edu">G. Randers-Pehrson</a>, “<a href="http://tools.ietf.org/html/rfc1952">GZIP file format specification version 4.3</a>”, RFC&nbsp;1952, May&nbsp;1996.
    55455553            </td>
    55465554         </tr> 
    55475555         <tr>
    55485556            <td class="reference"><b id="Pad1995">[26]</b></td>
    5549             <td class="top">Padmanabhan, V.N. and J.C. Mogul, “Improving HTTP Latency”, Computer Networks and ISDN Systems&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
     5557            <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
    55505558               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;.
    55515559            </td>
    … …  
    55735581         <tr>
    55745582            <td class="reference"><b id="RFC1950">[31]</b></td>
    5575             <td class="top"><a href="mailto:ghost@aladdin.com" title="Aladdin Enterprises">Deutsch, L.P.</a> and J-L. Gailly, “<a href="http://tools.ietf.org/html/rfc1950">ZLIB Compressed Data Format Specification version 3.3</a>”, RFC&nbsp;1950, May&nbsp;1996.
     5583            <td class="top"><a href="mailto:ghost@aladdin.com" title="Aladdin Enterprises">Deutsch, L.</a> and J-L. Gailly, “<a href="http://tools.ietf.org/html/rfc1950">ZLIB Compressed Data Format Specification version 3.3</a>”, RFC&nbsp;1950, May&nbsp;1996.
    55765584            </td>
    55775585         </tr> 
    5578          <!--WARNING: unused reference 'RFC2069'-->
    55795586         <tr>
    55805587            <td class="reference"><b id="RFC2069">[32]</b></td>
    … …  
    55995606         <tr>
    56005607            <td class="reference"><b id="RFC2145">[36]</b></td>
    5601             <td class="top"><a href="mailto:mogul@wrl.dec.com" title="Western Research Laboratory">Mogul, J.C.</a>, <a href="mailto:fielding@ics.uci.edu" title="Department of Information and Computer Science">Fielding, R.T.</a>, <a href="mailto:jg@w3.org" title="MIT Laboratory for Computer Science">Gettys, J.</a>, and <a href="mailto:frystyk@w3.org" title="W3 Consortium">H.F. Nielsen</a>, “<a href="http://tools.ietf.org/html/rfc2145">Use and Interpretation of HTTP Version Numbers</a>”, RFC&nbsp;2145, May&nbsp;1997.
     5608            <td class="top"><a href="mailto:mogul@wrl.dec.com" title="Western Research Laboratory">Mogul, J.</a>, <a href="mailto:fielding@ics.uci.edu" title="Department of Information and Computer Science">Fielding, R.</a>, <a href="mailto:jg@w3.org" title="MIT Laboratory for Computer Science">Gettys, J.</a>, and <a href="mailto:frystyk@w3.org" title="W3 Consortium">H. Nielsen</a>, “<a href="http://tools.ietf.org/html/rfc2145">Use and Interpretation of HTTP Version Numbers</a>”, RFC&nbsp;2145, May&nbsp;1997.
    56025609            </td>
    56035610         </tr> 
    … …  
    56145621         <tr>
    56155622            <td class="reference"><b id="Nie1997">[39]</b></td>
    5616             <td class="top">Nielsen, H.F.., Gettys, J., Prud'hommeaux, E., Lie, H., and C. Lilley, “Network Performance Effects of HTTP/1.1, CSS1, and PNG”, Proceedings of ACM SIGCOMM '97, Cannes France, Sep&nbsp;1997.</td>
     5623            <td class="top">Nielsen, H., Gettys, J., Prud'hommeaux, E., Lie, H., and C. Lilley, “Network Performance Effects of HTTP/1.1, CSS1, and PNG”, Proceedings of ACM SIGCOMM '97, Cannes France, Sep&nbsp;1997.</td>
    56175624         </tr> 
    56185625         <tr>
    … …  
    56235630         <tr>
    56245631            <td class="reference"><b id="RFC2277">[41]</b></td>
    5625             <td class="top"><a href="mailto:Harald.T.Alvestrand@uninett.no" title="UNINETT">Alvestrand, H.T.</a>, “<a href="http://tools.ietf.org/html/rfc2277">IETF Policy on Character Sets and Languages</a>”, BCP&nbsp;18, RFC&nbsp;2277, January&nbsp;1998.
     5632            <td class="top"><a href="mailto:Harald.T.Alvestrand@uninett.no" title="UNINETT">Alvestrand, H.</a>, “<a href="http://tools.ietf.org/html/rfc2277">IETF Policy on Character Sets and Languages</a>”, BCP&nbsp;18, RFC&nbsp;2277, January&nbsp;1998.
    56265633            </td>
    56275634         </tr> 
    56285635         <tr>
    56295636            <td class="reference"><b id="RFC2396">[42]</b></td>
    5630             <td class="top"><a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</a>, <a href="mailto:fielding@ics.uci.edu" title="Department of Information and Computer Science">Fielding, R.T.</a>, and <a href="mailto:masinter@parc.xerox.com" title="Xerox PARC">L. Masinter</a>, “<a href="http://tools.ietf.org/html/rfc2396">Uniform Resource Identifiers (URI): Generic Syntax</a>”, RFC&nbsp;2396, August&nbsp;1998.
     5637            <td class="top"><a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</a>, <a href="mailto:fielding@ics.uci.edu" title="Department of Information and Computer Science">Fielding, R.</a>, and <a href="mailto:masinter@parc.xerox.com" title="Xerox PARC">L. Masinter</a>, “<a href="http://tools.ietf.org/html/rfc2396">Uniform Resource Identifiers (URI): Generic Syntax</a>”, RFC&nbsp;2396, August&nbsp;1998.
    56315638            </td>
    56325639         </tr> 
    56335640         <tr>
    56345641            <td class="reference"><b id="RFC2617">[43]</b></td>
    5635             <td class="top"><a href="mailto:john@math.nwu.edu" title="Northwestern University, Department of Mathematics">Franks, J.</a>, <a href="mailto:pbaker@verisign.com" title="Verisign Inc.">Hallam-Baker, P.M.</a>, <a href="mailto:jeff@AbiSource.com" title="AbiSource, Inc.">Hostetler, J.L.</a>, <a href="mailto:lawrence@agranat.com" title="Agranat Systems, Inc.">Lawrence, S.D.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.J.</a>, Luotonen, A., and <a href="mailto:stewart@OpenMarket.com" title="Open Market, Inc.">L. Stewart</a>, “<a href="http://tools.ietf.org/html/rfc2617">HTTP Authentication: Basic and Digest Access Authentication</a>”, RFC&nbsp;2617, June&nbsp;1999.
     5642            <td class="top"><a href="mailto:john@math.nwu.edu" title="Northwestern University, Department of Mathematics">Franks, J.</a>, <a href="mailto:pbaker@verisign.com" title="Verisign Inc.">Hallam-Baker, P.</a>, <a href="mailto:jeff@AbiSource.com" title="AbiSource, Inc.">Hostetler, J.</a>, <a href="mailto:lawrence@agranat.com" title="Agranat Systems, Inc.">Lawrence, S.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, Luotonen, A., and <a href="mailto:stewart@OpenMarket.com" title="Open Market, Inc.">L. Stewart</a>, “<a href="http://tools.ietf.org/html/rfc2617">HTTP Authentication: Basic and Digest Access Authentication</a>”, RFC&nbsp;2617, June&nbsp;1999.
    56365643            </td>
    56375644         </tr> 
    … …  
    56455652            </td>
    56465653         </tr> 
    5647          <!--WARNING: unused reference 'RFC2026'-->
    56485654         <tr>
    56495655            <td class="reference"><b id="RFC2026">[46]</b></td>
    … …  
    56585664         <tr>
    56595665            <td class="reference"><b id="RFC2049">[48]</b></td>
    5660             <td class="top"><a href="mailto:ned@innosoft.com" title="Innosoft International, Inc.">Freed, N.</a> and <a href="mailto:nsb@nsb.fv.com" title="First Virtual Holdings">N.S. Borenstein</a>, “<a href="http://tools.ietf.org/html/rfc2049">Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples</a>”, RFC&nbsp;2049, November&nbsp;1996.
     5666            <td class="top"><a href="mailto:ned@innosoft.com" title="Innosoft International, Inc.">Freed, N.</a> and <a href="mailto:nsb@nsb.fv.com" title="First Virtual Holdings">N. Borenstein</a>, “<a href="http://tools.ietf.org/html/rfc2049">Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples</a>”, RFC&nbsp;2049, November&nbsp;1996.
    56615667            </td>
    56625668         </tr> 
    … …  
    56685674      </table>
    56695675      <hr class="noprint">
    5670       <h1 id="rfc.authors" class="np"><a href="#rfc.section.18" id="rfc.section.18">18.</a> <a href="#rfc.authors">Authors' Addresses</a></h1>
    5671       <address class="vcard"><span class="vcardline"><span class="fn">Roy T. Fielding</span><span class="n hidden"><span class="family-name">Fielding</span><span class="given-name">Roy T.</span></span></span><span class="org vcardline">Department of Information and Computer Science</span><span class="adr"><span class="street-address vcardline">University of California, Irvine</span><span class="vcardline"><span class="locality">Irvine</span>, <span class="region">CA</span>&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>
    5672       <address class="vcard"><span class="vcardline"><span class="fn">James Gettys</span><span class="n hidden"><span class="family-name">Gettys</span><span class="given-name">James</span></span></span><span class="org vcardline">World Wide Web Consortium</span><span class="adr"><span class="street-address vcardline">MIT Laboratory for Computer Science, NE43-356</span><span class="street-address vcardline">545 Technology Square</span><span class="vcardline"><span class="locality">Cambridge</span>, <span class="region">MA</span>&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>
    5673       <address class="vcard"><span class="vcardline"><span class="fn">Jeffrey C. Mogul</span><span class="n hidden"><span class="family-name">Mogul</span><span class="given-name">Jeffrey C.</span></span></span><span class="org vcardline">Compaq Computer Corporation</span><span class="adr"><span class="street-address vcardline">Western Research Laboratory</span><span class="street-address vcardline">250 University Avenue</span><span class="vcardline"><span class="locality">Palo Alto</span>, <span class="region">CA</span>&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>
    5674       <address class="vcard"><span class="vcardline"><span class="fn">Henrik Frystyk Nielsen</span><span class="n hidden"><span class="family-name">Frystyk</span></span></span><span class="org vcardline">World Wide Web Consortium</span><span class="adr"><span class="street-address vcardline">MIT Laboratory for Computer Science, NE43-356</span><span class="street-address vcardline">545 Technology Square</span><span class="vcardline"><span class="locality">Cambridge</span>, <span class="region">MA</span>&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>
    5675       <address class="vcard"><span class="vcardline"><span class="fn">Larry Masinter</span><span class="n hidden"><span class="family-name">Masinter</span><span class="given-name">Larry</span></span></span><span class="org vcardline">Xerox Corporation</span><span class="adr"><span class="street-address vcardline">MIT Laboratory for Computer Science, NE43-356</span><span class="street-address vcardline">3333 Coyote Hill Road</span><span class="vcardline"><span class="locality">Palo Alto</span>, <span class="region">CA</span>&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>
    5676       <address class="vcard"><span class="vcardline"><span class="fn">Paul J. Leach</span><span class="n hidden"><span class="family-name">Leach</span><span class="given-name">Paul J.</span></span></span><span class="org vcardline">Microsoft Corporation</span><span class="adr"><span class="street-address vcardline">1 Microsoft Way</span><span class="vcardline"><span class="locality">Redmond</span>, <span class="region">WA</span>&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>
    5677       <address class="vcard"><span class="vcardline"><span class="fn">Tim Berners-Lee</span><span class="n hidden"><span class="family-name">Berners-Lee</span><span class="given-name">Tim</span></span></span><span class="org vcardline">World Wide Web Consortium</span><span class="adr"><span class="street-address vcardline">MIT Laboratory for Computer Science, NE43-356</span><span class="street-address vcardline">545 Technology Square</span><span class="vcardline"><span class="locality">Cambridge</span>, <span class="region">MA</span>&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>
     5676      <div class="avoidbreak">
     5677         <h1 id="rfc.authors" class="np"><a href="#rfc.section.18" id="rfc.section.18">18.</a> <a href="#rfc.authors">Authors' Addresses</a></h1>
     5678         <address class="vcard"><span class="vcardline"><span class="fn">Roy T. Fielding</span><span class="n hidden"><span class="family-name">Fielding</span><span class="given-name">Roy T.</span></span></span><span class="org vcardline">Department of Information and Computer Science</span><span class="adr"><span class="street-address vcardline">University of California, Irvine</span><span class="vcardline"><span class="locality">Irvine</span>, <span class="region">CA</span>&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>
     5679         <address class="vcard"><span class="vcardline"><span class="fn">James Gettys</span><span class="n hidden"><span class="family-name">Gettys</span><span class="given-name">James</span></span></span><span class="org vcardline">World Wide Web Consortium</span><span class="adr"><span class="street-address vcardline">MIT Laboratory for Computer Science, NE43-356</span><span class="street-address vcardline">545 Technology Square</span><span class="vcardline"><span class="locality">Cambridge</span>, <span class="region">MA</span>&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>
     5680         <address class="vcard"><span class="vcardline"><span class="fn">Jeffrey C. Mogul</span><span class="n hidden"><span class="family-name">Mogul</span><span class="given-name">Jeffrey C.</span></span></span><span class="org vcardline">Compaq Computer Corporation</span><span class="adr"><span class="street-address vcardline">Western Research Laboratory</span><span class="street-address vcardline">250 University Avenue</span><span class="vcardline"><span class="locality">Palo Alto</span>, <span class="region">CA</span>&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>
     5681         <address class="vcard"><span class="vcardline"><span class="fn">Henrik Frystyk Nielsen</span><span class="n hidden"><span class="family-name">Frystyk</span></span></span><span class="org vcardline">World Wide Web Consortium</span><span class="adr"><span class="street-address vcardline">MIT Laboratory for Computer Science, NE43-356</span><span class="street-address vcardline">545 Technology Square</span><span class="vcardline"><span class="locality">Cambridge</span>, <span class="region">MA</span>&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>
     5682         <address class="vcard"><span class="vcardline"><span class="fn">Larry Masinter</span><span class="n hidden"><span class="family-name">Masinter</span><span class="given-name">Larry</span></span></span><span class="org vcardline">Xerox Corporation</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>
     5683         <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>
     5684         <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>
     5685      </div>
    56785686      <hr class="noprint">
    56795687      <h1 id="rfc.section.19" class="np"><a href="#rfc.section.19">19.</a>&nbsp;Appendices
    … …  
    60646072      </h1>
    60656073      <p id="rfc.section.20.p.1">Please see the PostScript version of this RFC for the INDEX.</p>
    6066       <h1><a id="rfc.copyright" href="#rfc.copyright">Full Copyright Statement</a></h1>
    6067       <p>Copyright © The Internet Society (1999). All Rights Reserved.</p>
    6068       <p>This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise
    6069          explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without
    6070          restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative
    6071          works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references
    6072          to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards
    6073          in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to
    6074          translate it into languages other than English.
    6075       </p>
    6076       <p>The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.</p>
    6077       <p>This document and the information contained herein is provided on an “AS IS” basis and THE INTERNET SOCIETY AND THE INTERNET
    6078          ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE
    6079          OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
    6080          PURPOSE.
    6081       </p>
    6082       <hr class="noprint">
    6083       <h1 class="np"><a id="rfc.ipr" href="#rfc.ipr">Intellectual Property</a></h1>
    6084       <p>The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed
    6085          to pertain to the implementation or use of the technology described in this document or the extent to which any license under
    6086          such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights.
    6087          Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be
    6088          found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available,
    6089          or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors
    6090          or users of this specification can be obtained from the IETF Secretariat.
    6091       </p>
    6092       <p>The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary
    6093          rights which may cover technology that may be required to practice this standard. Please address the information to the IETF
    6094          Executive Director.
    6095       </p>
    6096       <h1>Acknowledgment</h1>
    6097       <p>Funding for the RFC Editor function is currently provided by the Internet Society.</p>
    60986074      <hr class="noprint">
    60996075      <h1 id="rfc.index" class="np"><a href="#rfc.index">Index</a></h1>
    … …  
    68106786         </ul>
    68116787      </div>
     6788      <h1><a id="rfc.copyright" href="#rfc.copyright">Full Copyright Statement</a></h1>
     6789      <p>Copyright © The Internet Society (1999). All Rights Reserved.</p>
     6790      <p>This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise
     6791         explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without
     6792         restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative
     6793         works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references
     6794         to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards
     6795         in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to
     6796         translate it into languages other than English.
     6797      </p>
     6798      <p>The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.</p>
     6799      <p>This document and the information contained herein is provided on an “AS IS” basis and THE INTERNET SOCIETY AND THE INTERNET
     6800         ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE
     6801         OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
     6802         PURPOSE.
     6803      </p>
     6804      <hr class="noprint">
     6805      <h1 class="np"><a id="rfc.ipr" href="#rfc.ipr">Intellectual Property</a></h1>
     6806      <p>The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed
     6807         to pertain to the implementation or use of the technology described in this document or the extent to which any license under
     6808         such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights.
     6809         Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be
     6810         found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available,
     6811         or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors
     6812         or users of this specification can be obtained from the IETF Secretariat.
     6813      </p>
     6814      <p>The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary
     6815         rights which may cover technology that may be required to practice this standard. Please address the information to the IETF
     6816         Executive Director.
     6817      </p>
     6818      <h1>Acknowledgment</h1>
     6819      <p>Funding for the RFC Editor function is currently provided by the Internet Society.</p>
    68126820   </body>
    68136821</html>
Note: See TracChangeset for help on using the changeset viewer.