Ignore:
Timestamp:
24/03/09 20:48:26 (12 years ago)
Author:
julian.reschke@…
Message:

replace <list> elements used for indentation by <x:note> elements

Location:
draft-ietf-httpbis/latest
Files:
10 edited

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest/p1-messaging.html

    r560 r563  
    471471         <tr>
    472472            <td class="header left"></td>
    473             <td class="header right">March 12, 2009</td>
     473            <td class="header right">March 24, 2009</td>
    474474         </tr>
    475475      </table>
    … …  
    845845      <p id="rfc.section.2.1.2.p.1"> <span class="comment" id="rfc.comment.1">[<a href="#rfc.comment.1" class="smpl">rfc.comment.1</a>: TBD: Define and explain purpose of https scheme.]</span>
    846846      </p>
    847       <dl class="empty">
    848          <dd> <b>Note:</b> the "https" scheme is defined in <a href="#RFC2818" id="rfc.xref.RFC2818.1"><cite title="HTTP Over TLS">[RFC2818]</cite></a>.
    849          </dd>
    850       </dl>
     847      <div class="note">
     848         <p> <b>Note:</b> the "https" scheme is defined in <a href="#RFC2818" id="rfc.xref.RFC2818.1"><cite title="HTTP Over TLS">[RFC2818]</cite></a>.
     849         </p>
     850      </div>
    851851      <h3 id="rfc.section.2.1.3"><a href="#rfc.section.2.1.3">2.1.3</a>&nbsp;<a id="uri.comparison" href="#uri.comparison">URI Comparison</a></h3>
    852852      <p id="rfc.section.2.1.3.p.1">When comparing two URIs to decide if they match or not, a client <em class="bcp14">SHOULD</em> use a case-sensitive octet-by-octet comparison of the entire URIs, with these exceptions:
    … …  
    965965      <p id="rfc.section.3.1.p.8">Due to interoperability problems with HTTP/1.0 proxies discovered since the publication of <a href="#RFC2068" id="rfc.xref.RFC2068.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, caching proxies <em class="bcp14">MUST</em>, gateways <em class="bcp14">MAY</em>, and tunnels <em class="bcp14">MUST NOT</em> upgrade the request to the highest version they support. The proxy/gateway's response to that request <em class="bcp14">MUST</em> be in the same major version as the request.
    966966      </p>
    967       <p id="rfc.section.3.1.p.9"> </p>
    968       <dl class="empty">
    969          <dd> <b>Note:</b> Converting between versions of HTTP may involve modification of header fields required or forbidden by the versions involved.
    970          </dd>
    971       </dl>
     967      <div class="note">
     968         <p> <b>Note:</b> Converting between versions of HTTP may involve modification of header fields required or forbidden by the versions involved.
     969         </p>
     970      </div>
    972971      <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a>&nbsp;<a id="date.time.formats" href="#date.time.formats">Date/Time Formats</a></h2>
    973972      <h3 id="rfc.section.3.2.1"><a href="#rfc.section.3.2.1">3.2.1</a>&nbsp;<a id="full.date" href="#full.date">Full Date</a></h3>
    … …  
    979978         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;A</a> for further information.
    980979      </p>
    981       <dl class="empty">
    982          <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,
     980      <div class="note">
     981         <p> <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,
    983982            as is sometimes the case when retrieving or posting messages via proxies/gateways to SMTP or NNTP.
    984          </dd>
    985       </dl>
     983         </p>
     984      </div>
    986985      <p id="rfc.section.3.2.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
    987986         Universal Time). This is indicated in the first two formats by the inclusion of "GMT" as the three-letter abbreviation for
    … …  
    12191218         thus a proxy <em class="bcp14">MUST NOT</em> change the order of these field values when a message is forwarded.
    12201219      </p>
    1221       <p id="rfc.section.4.2.p.11"> </p>
    1222       <dl class="empty">
    1223          <dd> <b>Note:</b> the "Set-Cookie" header as implemented in practice (as opposed to how it is specified in <a href="#RFC2109" id="rfc.xref.RFC2109.1"><cite title="HTTP State Management Mechanism">[RFC2109]</cite></a>) can occur multiple times, but does not use the list syntax, and thus cannot be combined into a single line. (See Appendix
     1220      <div class="note">
     1221         <p> <b>Note:</b> the "Set-Cookie" header as implemented in practice (as opposed to how it is specified in <a href="#RFC2109" id="rfc.xref.RFC2109.1"><cite title="HTTP State Management Mechanism">[RFC2109]</cite></a>) can occur multiple times, but does not use the list syntax, and thus cannot be combined into a single line. (See Appendix
    12241222            A.2.3 of <a href="#Kri2001" id="rfc.xref.Kri2001.1"><cite title="HTTP Cookies: Standards, Privacy, and Politics">[Kri2001]</cite></a> for details.) Also note that the Set-Cookie2 header specified in <a href="#RFC2965" id="rfc.xref.RFC2965.1"><cite title="HTTP State Management Mechanism">[RFC2965]</cite></a> does not share this problem.
    1225          </dd>
    1226       </dl>
     1223         </p>
     1224      </div>
    12271225      <h2 id="rfc.section.4.3"><a href="#rfc.section.4.3">4.3</a>&nbsp;<a id="message.body" href="#message.body">Message Body</a></h2>
    12281226      <p id="rfc.section.4.3.p.1">The message-body (if any) of an HTTP message is used to carry the entity-body associated with the request or response. The
    … …  
    13731371         above to replace a null path-absolute with "/".
    13741372      </p>
    1375       <p id="rfc.section.5.1.2.p.17"> </p>
    1376       <dl class="empty">
    1377          <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
     1373      <div class="note">
     1374         <p> <b>Note:</b> The "no rewrite" rule prevents the proxy from changing the meaning of the request when the origin server is improperly using
    13781375            a non-reserved URI character for a reserved purpose. Implementors should be aware that some pre-HTTP/1.1 proxies have been
    13791376            known to rewrite the request-target.
    1380          </dd>
    1381       </dl>
     1377         </p>
     1378      </div>
    13821379      <p id="rfc.section.5.1.2.p.18">HTTP does not place a pre-defined limit on the length of a request-target. A server <em class="bcp14">MUST</em> be prepared to receive URIs of unbounded length and respond with the 414 (URI Too Long) status if the received request-target
    13831380         would be longer than the server wishes to handle (see <a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 8.4.15</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).

  • draft-ietf-httpbis/latest/p1-messaging.xml

    r547 r563  
    592592   <cref>TBD: Define and explain purpose of https scheme.</cref>
    593593</t>
    594 <t><list><t>
    595   <x:h>Note:</x:h> the "https" scheme is defined in <xref target="RFC2818"/>.
    596 </t></list></t>
     594<x:note>
     595  <t>
     596    <x:h>Note:</x:h> the "https" scheme is defined in <xref target="RFC2818"/>.
     597  </t>
     598</x:note>
    597599</section>
    598600
    … …  
    825827   the same major version as the request.
    826828</t>
    827 <t>
    828   <list>
    829     <t>
    830       <x:h>Note:</x:h> Converting between versions of HTTP may involve modification
    831       of header fields required or forbidden by the versions involved.
    832     </t>
    833   </list>
    834 </t>
     829<x:note>
     830  <t>
     831    <x:h>Note:</x:h> Converting between versions of HTTP may involve modification
     832    of header fields required or forbidden by the versions involved.
     833  </t>
     834</x:note>
    835835</section>
    836836
    … …  
    869869   in header fields. See <xref target="tolerant.applications"/> for further information.
    870870</t>
    871 <t><list><t>
    872       <x:h>Note:</x:h> Recipients of date values are encouraged to be robust in
    873       accepting date values that may have been sent by non-HTTP
    874       applications, as is sometimes the case when retrieving or posting
    875       messages via proxies/gateways to SMTP or NNTP.
    876 </t></list></t>
     871<x:note>
     872  <t>
     873    <x:h>Note:</x:h> Recipients of date values are encouraged to be robust in
     874    accepting date values that may have been sent by non-HTTP
     875    applications, as is sometimes the case when retrieving or posting
     876    messages via proxies/gateways to SMTP or NNTP.
     877  </t>
     878</x:note>
    877879<t>
    878880   All HTTP date/time stamps &MUST; be represented in Greenwich Mean Time
    … …  
    13081310   change the order of these field values when a message is forwarded.
    13091311</t>
    1310 <t>
    1311   <list><t>
     1312<x:note>
     1313  <t>
    13121314   <x:h>Note:</x:h> the "Set-Cookie" header as implemented in
    13131315   practice (as opposed to how it is specified in <xref target="RFC2109"/>)
    … …  
    13161318   for details.) Also note that the Set-Cookie2 header specified in
    13171319   <xref target="RFC2965"/> does not share this problem.
    1318   </t></list>
    1319 </t>
     1320  </t>
     1321</x:note>
    13201322 
    13211323</section>
    … …  
    16211623   except as noted above to replace a null path-absolute with "/".
    16221624</t>
    1623 <t>
    1624   <list><t>
    1625       <x:h>Note:</x:h> The "no rewrite" rule prevents the proxy from changing the
    1626       meaning of the request when the origin server is improperly using
    1627       a non-reserved URI character for a reserved purpose.  Implementors
    1628       should be aware that some pre-HTTP/1.1 proxies have been known to
    1629       rewrite the request-target.
    1630   </t></list>
    1631 </t>
     1625<x:note>
     1626  <t>
     1627    <x:h>Note:</x:h> The "no rewrite" rule prevents the proxy from changing the
     1628    meaning of the request when the origin server is improperly using
     1629    a non-reserved URI character for a reserved purpose.  Implementors
     1630    should be aware that some pre-HTTP/1.1 proxies have been known to
     1631    rewrite the request-target.
     1632  </t>
     1633</x:note>
    16321634<t>
    16331635   HTTP does not place a pre-defined limit on the length of a request-target.

  • draft-ietf-httpbis/latest/p2-semantics.html

    r560 r563  
    2929cite {
    3030  font-style: normal;
     31}
     32div.note {
     33  margin-left: 2em;
    3134}
    3235dd {
    … …  
    468471         <tr>
    469472            <td class="header left"></td>
    470             <td class="header right">March 12, 2009</td>
     473            <td class="header right">March 24, 2009</td>
    471474         </tr>
    472475      </table>
    … …  
    11661169      <p id="rfc.section.8.3.p.1">This class of status code indicates that further action needs to be taken by the user agent in order to fulfill the request.
    11671170         The action required <em class="bcp14">MAY</em> be carried out by the user agent without interaction with the user if and only if the method used in the second request is
    1168          GET or HEAD. A client <em class="bcp14">SHOULD</em> detect infinite redirection loops, since such loops generate network traffic for each redirection. 
    1169       </p>
    1170       <dl class="empty">
    1171          <dd> <b>Note:</b> previous versions of this specification recommended a maximum of five redirections. Content developers should be aware that
     1171         GET or HEAD. A client <em class="bcp14">SHOULD</em> detect infinite redirection loops, since such loops generate network traffic for each redirection.
     1172      </p>
     1173      <div class="note">
     1174         <p> <b>Note:</b> previous versions of this specification recommended a maximum of five redirections. Content developers should be aware that
    11721175            there might be clients that implement such a fixed limitation.
    1173          </dd>
    1174       </dl>
     1176         </p>
     1177      </div>
    11751178      <div id="rfc.iref.34"></div>
    11761179      <div id="rfc.iref.s.11"></div>
    … …  
    11951198      </p>
    11961199      <p id="rfc.section.8.3.2.p.3">If the 301 status code is received in response to a request method that is known to be "safe", as defined in <a href="#safe.methods" title="Safe Methods">Section&nbsp;7.1.1</a>, then the request <em class="bcp14">MAY</em> be automatically redirected by the user agent without confirmation. Otherwise, the user agent <em class="bcp14">MUST NOT</em> automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which
    1197          the request was issued. 
    1198       </p>
    1199       <dl class="empty">
    1200          <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
     1200         the request was issued.
     1201      </p>
     1202      <div class="note">
     1203         <p> <b>Note:</b> When automatically redirecting a POST request after receiving a 301 status code, some existing HTTP/1.0 user agents will erroneously
    12011204            change it into a GET request.
    1202          </dd>
    1203       </dl>
     1205         </p>
     1206      </div>
    12041207      <div id="rfc.iref.36"></div>
    12051208      <div id="rfc.iref.s.13"></div>
    … …  
    12121215      </p>
    12131216      <p id="rfc.section.8.3.3.p.3">If the 302 status code is received in response to a request method that is known to be "safe", as defined in <a href="#safe.methods" title="Safe Methods">Section&nbsp;7.1.1</a>, then the request <em class="bcp14">MAY</em> be automatically redirected by the user agent without confirmation. Otherwise, the user agent <em class="bcp14">MUST NOT</em> automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which
    1214          the request was issued. 
    1215       </p>
    1216       <dl class="empty">
    1217          <dd> <b>Note:</b>  <a href="#RFC1945" id="rfc.xref.RFC1945.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.0">[RFC1945]</cite></a> and <a href="#RFC2068" id="rfc.xref.RFC2068.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> specify that the client is not allowed to change the method on the redirected request. However, most existing user agent implementations
     1217         the request was issued.
     1218      </p>
     1219      <div class="note">
     1220         <p> <b>Note:</b>  <a href="#RFC1945" id="rfc.xref.RFC1945.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.0">[RFC1945]</cite></a> and <a href="#RFC2068" id="rfc.xref.RFC2068.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> specify that the client is not allowed to change the method on the redirected request. However, most existing user agent implementations
    12181221            treat 302 as if it were a 303 response, performing a GET on the Location field-value regardless of the original request method.
    12191222            The status codes 303 and 307 have been added for servers that wish to make unambiguously clear which kind of reaction is expected
    12201223            of the client.
    1221          </dd>
    1222       </dl>
     1224         </p>
     1225      </div>
    12231226      <div id="rfc.iref.37"></div>
    12241227      <div id="rfc.iref.s.14"></div>
    … …  
    13211324      <p id="rfc.section.8.4.7.p.2">Unless it was a HEAD request, the response <em class="bcp14">SHOULD</em> include an entity containing a list of available entity characteristics and location(s) from which the user or user agent
    13221325         can choose the one most appropriate. The entity format is specified by the media type given in the Content-Type header field.
    1323          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. 
    1324       </p>
    1325       <dl class="empty">
    1326          <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.
     1326         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.
     1327      </p>
     1328      <div class="note">
     1329         <p> <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.
    13271330            In some cases, this may even be preferable to sending a 406 response. User agents are encouraged to inspect the headers of
    13281331            an incoming response to determine if it is acceptable.
    1329          </dd>
    1330       </dl>
    1331       <p id="rfc.section.8.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.
     1332         </p>
     1333      </div>
     1334      <p id="rfc.section.8.4.7.p.4">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.
    13321335      </p>
    13331336      <div id="rfc.iref.49"></div>
    … …  
    14381441      <h3 id="rfc.section.8.5.4"><a href="#rfc.section.8.5.4">8.5.4</a>&nbsp;<a id="status.503" href="#status.503">503 Service Unavailable</a></h3>
    14391442      <p id="rfc.section.8.5.4.p.1">The server is currently unable to handle the request due to a temporary overloading or maintenance of the server. The implication
    1440          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. 
    1441       </p>
    1442       <dl class="empty">
    1443          <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
     1443         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.
     1444      </p>
     1445      <div class="note">
     1446         <p> <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
    14441447            to simply refuse the connection.
    1445          </dd>
    1446       </dl>
     1448         </p>
     1449      </div>
    14471450      <div id="rfc.iref.64"></div>
    14481451      <div id="rfc.iref.s.41"></div>
    14491452      <h3 id="rfc.section.8.5.5"><a href="#rfc.section.8.5.5">8.5.5</a>&nbsp;<a id="status.504" href="#status.504">504 Gateway Timeout</a></h3>
    14501453      <p id="rfc.section.8.5.5.p.1">The server, while acting as a gateway or proxy, did not receive a timely response from the upstream server specified by the
    1451          URI (e.g. HTTP, FTP, LDAP) or some other auxiliary server (e.g. DNS) it needed to access in attempting to complete the request. 
    1452       </p>
    1453       <dl class="empty">
    1454          <dd> <b>Note:</b> Note to implementors: some deployed proxies are known to return 400 or 500 when DNS lookups time out.
    1455          </dd>
    1456       </dl>
     1454         URI (e.g. HTTP, FTP, LDAP) or some other auxiliary server (e.g. DNS) it needed to access in attempting to complete the request.
     1455      </p>
     1456      <div class="note">
     1457         <p> <b>Note:</b> Note to implementors: some deployed proxies are known to return 400 or 500 when DNS lookups time out.
     1458         </p>
     1459      </div>
    14571460      <div id="rfc.iref.65"></div>
    14581461      <div id="rfc.iref.s.42"></div>
    … …  
    15421545</pre><p id="rfc.section.9.4.p.3">An example is:</p>
    15431546      <div id="rfc.figure.u.18"></div><pre class="text">  Location: http://www.example.org/pub/WWW/People.html
    1544 </pre><p id="rfc.section.9.4.p.5"> </p>
    1545       <dl class="empty">
    1546          <dd> <b>Note:</b> The Content-Location header field (<a href="p3-payload.html#header.content-location" title="Content-Location">Section 5.7</a> of <a href="#Part3" id="rfc.xref.Part3.11"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) differs from Location in that the Content-Location identifies the original location of the entity enclosed in the response.
     1547</pre><div class="note">
     1548         <p> <b>Note:</b> The Content-Location header field (<a href="p3-payload.html#header.content-location" title="Content-Location">Section 5.7</a> of <a href="#Part3" id="rfc.xref.Part3.11"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) differs from Location in that the Content-Location identifies the original location of the entity enclosed in the response.
    15471549            It is therefore possible for a response to contain header fields for both Location and Content-Location.
    1548          </dd>
    1549       </dl>
     1550         </p>
     1551      </div>
    15501552      <p id="rfc.section.9.4.p.6">There are circumstances in which a fragment identifier in a Location URL would not be appropriate: </p>
    15511553      <ul>
    … …  
    16141616</pre><p id="rfc.section.9.8.p.3">Example:</p>
    16151617      <div id="rfc.figure.u.26"></div><pre class="text">  Server: CERN/3.0 libwww/2.17
    1616 </pre><p id="rfc.section.9.8.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">MUST</em> include a Via field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 8.9</a> of <a href="#Part1" id="rfc.xref.Part1.26"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 
    1617       </p>
    1618       <dl class="empty">
    1619          <dd> <b>Note:</b> Revealing the specific software version of the server might allow the server machine to become more vulnerable to attacks
     1618</pre><p id="rfc.section.9.8.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">MUST</em> include a Via field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 8.9</a> of <a href="#Part1" id="rfc.xref.Part1.26"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
     1619      </p>
     1620      <div class="note">
     1621         <p> <b>Note:</b> Revealing the specific software version of the server might allow the server machine to become more vulnerable to attacks
    16201622            against software that is known to contain security holes. Server implementors are encouraged to make this field a configurable
    16211623            option.
    1622          </dd>
    1623       </dl>
     1624         </p>
     1625      </div>
    16241626      <div id="rfc.iref.u.1"></div>
    16251627      <div id="rfc.iref.h.10"></div>

  • draft-ietf-httpbis/latest/p2-semantics.xml

    r547 r563  
    12441244   GET or HEAD. A client &SHOULD; detect infinite redirection loops, since
    12451245   such loops generate network traffic for each redirection.
    1246   <list><t>
    1247       <x:h>Note:</x:h> previous versions of this specification recommended a
    1248       maximum of five redirections. Content developers should be aware
    1249       that there might be clients that implement such a fixed
    1250       limitation.
    1251   </t></list>
    1252 </t>
     1246</t>
     1247<x:note>
     1248  <t>
     1249    <x:h>Note:</x:h> previous versions of this specification recommended a
     1250    maximum of five redirections. Content developers should be aware
     1251    that there might be clients that implement such a fixed
     1252    limitation.
     1253  </t>
     1254</x:note>
    12531255
    12541256<section title="300 Multiple Choices" anchor="status.300">
    … …  
    13041306   request unless it can be confirmed by the user, since this might
    13051307   change the conditions under which the request was issued.
    1306   <list><t>
    1307       <x:h>Note:</x:h> When automatically redirecting a POST request after
    1308       receiving a 301 status code, some existing HTTP/1.0 user agents
    1309       will erroneously change it into a GET request.
    1310   </t></list>
    1311 </t>
     1308</t>
     1309<x:note>
     1310  <t>
     1311    <x:h>Note:</x:h> When automatically redirecting a POST request after
     1312    receiving a 301 status code, some existing HTTP/1.0 user agents
     1313    will erroneously change it into a GET request.
     1314  </t>
     1315</x:note>
    13121316</section>
    13131317
    … …  
    13351339   request unless it can be confirmed by the user, since this might
    13361340   change the conditions under which the request was issued.
    1337   <list><t>
    1338       <x:h>Note:</x:h> <xref target="RFC1945"/> and <xref target="RFC2068"/> specify that the client is not allowed
    1339       to change the method on the redirected request.  However, most
    1340       existing user agent implementations treat 302 as if it were a 303
    1341       response, performing a GET on the Location field-value regardless
    1342       of the original request method. The status codes 303 and 307 have
    1343       been added for servers that wish to make unambiguously clear which
    1344       kind of reaction is expected of the client.
    1345   </t></list>
    1346 </t>
     1341</t>
     1342<x:note>
     1343  <t>
     1344    <x:h>Note:</x:h> <xref target="RFC1945"/> and <xref target="RFC2068"/> specify that the client is not allowed
     1345    to change the method on the redirected request.  However, most
     1346    existing user agent implementations treat 302 as if it were a 303
     1347    response, performing a GET on the Location field-value regardless
     1348    of the original request method. The status codes 303 and 307 have
     1349    been added for servers that wish to make unambiguously clear which
     1350    kind of reaction is expected of the client.
     1351  </t>
     1352</x:note>
    13471353</section>
    13481354
    … …  
    15461552   choice &MAY; be performed automatically. However, this specification
    15471553   does not define any standard for such automatic selection.
    1548   <list><t>
    1549       <x:h>Note:</x:h> HTTP/1.1 servers are allowed to return responses which are
    1550       not acceptable according to the accept headers sent in the
    1551       request. In some cases, this may even be preferable to sending a
    1552       406 response. User agents are encouraged to inspect the headers of
    1553       an incoming response to determine if it is acceptable.
    1554   </t></list>
    1555 </t>
     1554</t>
     1555<x:note>
     1556  <t>
     1557    <x:h>Note:</x:h> HTTP/1.1 servers are allowed to return responses which are
     1558    not acceptable according to the accept headers sent in the
     1559    request. In some cases, this may even be preferable to sending a
     1560    406 response. User agents are encouraged to inspect the headers of
     1561    an incoming response to determine if it is acceptable.
     1562  </t>
     1563</x:note>
    15561564<t>
    15571565   If the response could be unacceptable, a user agent &SHOULD;
    … …  
    17661774   Retry-After header. If no Retry-After is given, the client &SHOULD;
    17671775   handle the response as it would for a 500 response.
    1768   <list><t>
    1769       <x:h>Note:</x:h> The existence of the 503 status code does not imply that a
    1770       server must use it when becoming overloaded. Some servers may wish
    1771       to simply refuse the connection.
    1772   </t></list>
    1773 </t>
     1776</t>
     1777<x:note>
     1778  <t>
     1779    <x:h>Note:</x:h> The existence of the 503 status code does not imply that a
     1780    server must use it when becoming overloaded. Some servers may wish
     1781    to simply refuse the connection.
     1782  </t>
     1783</x:note>
    17741784</section>
    17751785
    … …  
    17821792   HTTP, FTP, LDAP) or some other auxiliary server (e.g. DNS) it needed
    17831793   to access in attempting to complete the request.
    1784   <list><t>
    1785       <x:h>Note:</x:h> Note to implementors: some deployed proxies are known to
    1786       return 400 or 500 when DNS lookups time out.
    1787   </t></list>
    1788 </t>
     1794</t>
     1795<x:note>
     1796  <t>
     1797    <x:h>Note:</x:h> Note to implementors: some deployed proxies are known to
     1798    return 400 or 500 when DNS lookups time out.
     1799  </t>
     1800</x:note>
    17891801</section>
    17901802
    … …  
    19791991  Location: http://www.example.org/pub/WWW/People.html
    19801992</artwork></figure>
    1981 <t>
    1982   <list><t>
    1983       <x:h>Note:</x:h> The Content-Location header field (&header-content-location;) differs
    1984       from Location in that the Content-Location identifies the original
    1985       location of the entity enclosed in the response. It is therefore
    1986       possible for a response to contain header fields for both Location
    1987       and Content-Location.
    1988   </t></list>
    1989 </t>
     1993<x:note>
     1994  <t>
     1995    <x:h>Note:</x:h> The Content-Location header field (&header-content-location;) differs
     1996    from Location in that the Content-Location identifies the original
     1997    location of the entity enclosed in the response. It is therefore
     1998    possible for a response to contain header fields for both Location
     1999    and Content-Location.
     2000  </t>
     2001</x:note>
    19902002<t>
    19912003   There are circumstances in which a fragment identifier in a Location URL would not be appropriate:
    … …  
    21342146   application &MUST-NOT; modify the Server response-header. Instead, it
    21352147   &MUST; include a Via field (as described in &header-via;).
    2136   <list><t>
    2137       <x:h>Note:</x:h> Revealing the specific software version of the server might
    2138       allow the server machine to become more vulnerable to attacks
    2139       against software that is known to contain security holes. Server
    2140       implementors are encouraged to make this field a configurable
    2141       option.
    2142   </t></list>
    2143 </t>
     2148</t>
     2149<x:note>
     2150  <t>
     2151    <x:h>Note:</x:h> Revealing the specific software version of the server might
     2152    allow the server machine to become more vulnerable to attacks
     2153    against software that is known to contain security holes. Server
     2154    implementors are encouraged to make this field a configurable
     2155    option.
     2156  </t>
     2157</x:note>
    21442158</section>
    21452159

  • draft-ietf-httpbis/latest/p3-payload.html

    r560 r563  
    3636cite {
    3737  font-style: normal;
     38}
     39div.note {
     40  margin-left: 2em;
    3841}
    3942dd {
    … …  
    475478         <tr>
    476479            <td class="header left"></td>
    477             <td class="header right">March 12, 2009</td>
     480            <td class="header right">March 24, 2009</td>
    478481         </tr>
    479482      </table>
    … …  
    670673         to determine the exact mapping is not permitted.
    671674      </p>
    672       <dl class="empty">
    673          <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
     675      <div class="note">
     676         <p> <b>Note:</b> This use of the term "character set" is more commonly referred to as a "character encoding." However, since HTTP and MIME
    674677            share the same registry, it is important that the terminology also be shared.
    675          </dd>
    676       </dl>
     678         </p>
     679      </div>
    677680      <div id="rule.charset">
    678681         <p id="rfc.section.2.1.p.4">  HTTP character sets are identified by case-insensitive tokens. The complete set of tokens is defined by the IANA Character
    … …  
    800803         an unrecognized multipart subtype, the application <em class="bcp14">MUST</em> treat it as being equivalent to "multipart/mixed".
    801804      </p>
    802       <dl class="empty">
    803          <dd> <b>Note:</b> The "multipart/form-data" type has been specifically defined for carrying form data suitable for processing via the POST request
     805      <div class="note">
     806         <p> <b>Note:</b> The "multipart/form-data" type has been specifically defined for carrying form data suitable for processing via the POST request
    804807            method, as described in <a href="#RFC2388" id="rfc.xref.RFC2388.1"><cite title="Returning Values from Forms: multipart/form-data">[RFC2388]</cite></a>.
    805          </dd>
    806       </dl>
     808         </p>
     809      </div>
    807810      <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a>&nbsp;<a id="language.tags" href="#language.tags">Language Tags</a></h2>
    808811      <p id="rfc.section.2.4.p.1">A language tag identifies a natural language spoken, written, or otherwise conveyed by human beings for communication of information
    … …  
    876879         all users have the same preferences for what is "best," and not all user agents are equally capable of rendering all entity
    877880         types. For that reason, HTTP has provisions for several mechanisms for "content negotiation" -- the process of selecting the
    878          best representation for a given response when there are multiple representations available. 
    879       </p>
    880       <dl class="empty">
    881          <dd> <b>Note:</b> This is not called "format negotiation" because the alternate representations may be of the same media type, but use different
     881         best representation for a given response when there are multiple representations available.
     882      </p>
     883      <div class="note">
     884         <p> <b>Note:</b> This is not called "format negotiation" because the alternate representations may be of the same media type, but use different
    882885            capabilities of that type, be in different languages, etc.
    883          </dd>
    884       </dl>
    885       <p id="rfc.section.4.p.2">Any response containing an entity-body <em class="bcp14">MAY</em> be subject to negotiation, including error responses.
    886       </p>
    887       <p id="rfc.section.4.p.3">There are two kinds of content negotiation which are possible in HTTP: server-driven and agent-driven negotiation. These two
     886         </p>
     887      </div>
     888      <p id="rfc.section.4.p.3">Any response containing an entity-body <em class="bcp14">MAY</em> be subject to negotiation, including error responses.
     889      </p>
     890      <p id="rfc.section.4.p.4">There are two kinds of content negotiation which are possible in HTTP: server-driven and agent-driven negotiation. These two
    888891         kinds of negotiation are orthogonal and thus may be used separately or in combination. One method of combination, referred
    889892         to as transparent negotiation, occurs when a cache uses the agent-driven negotiation information provided by the origin server
    … …  
    978981      <p id="rfc.section.5.1.p.4">Each media-range <em class="bcp14">MAY</em> be followed by one or more accept-params, beginning with the "q" parameter for indicating a relative quality factor. The first
    979982         "q" parameter (if any) separates the media-range parameter(s) from the accept-params. Quality factors allow the user or user
    980          agent to indicate the relative degree of preference for that media-range, using the qvalue scale from 0 to 1 (<a href="p1-messaging.html#quality.values" title="Quality Values">Section 3.5</a> of <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The default value is q=1. 
    981       </p>
    982       <dl class="empty">
    983          <dd> <b>Note:</b> Use of the "q" parameter name to separate media type parameters from Accept extension parameters is due to historical practice.
     983         agent to indicate the relative degree of preference for that media-range, using the qvalue scale from 0 to 1 (<a href="p1-messaging.html#quality.values" title="Quality Values">Section 3.5</a> of <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The default value is q=1.
     984      </p>
     985      <div class="note">
     986         <p> <b>Note:</b> Use of the "q" parameter name to separate media type parameters from Accept extension parameters is due to historical practice.
    984987            Although this prevents any media type parameter named "q" from being used with a media range, such an event is believed to
    985988            be unlikely given the lack of any "q" parameters in the IANA media type registry and the rare usage of any media type parameters
    986989            in Accept. Future media types are discouraged from registering any parameter named "q".
    987          </dd>
    988       </dl>
    989       <p id="rfc.section.5.1.p.5">The example</p>
     990         </p>
     991      </div>
     992      <p id="rfc.section.5.1.p.6">The example</p>
    990993      <div id="rfc.figure.u.16"></div><pre class="text">  Accept: audio/*; q=0.2, audio/basic
    991 </pre><p id="rfc.section.5.1.p.7"> <em class="bcp14">SHOULD</em> be interpreted as "I prefer audio/basic, but send me any audio type if it is the best available after an 80% mark-down in
     994</pre><p id="rfc.section.5.1.p.8"> <em class="bcp14">SHOULD</em> be interpreted as "I prefer audio/basic, but send me any audio type if it is the best available after an 80% mark-down in
    992995         quality."
    993996      </p>
    994       <p id="rfc.section.5.1.p.8">If no Accept header field is present, then it is assumed that the client accepts all media types. If an Accept header field
     997      <p id="rfc.section.5.1.p.9">If no Accept header field is present, then it is assumed that the client accepts all media types. If an Accept header field
    995998         is present, and if the server cannot send a response which is acceptable according to the combined Accept field value, then
    996999         the server <em class="bcp14">SHOULD</em> send a 406 (Not Acceptable) response.
    9971000      </p>
    998       <p id="rfc.section.5.1.p.9">A more elaborate example is</p>
     1001      <p id="rfc.section.5.1.p.10">A more elaborate example is</p>
    9991002      <div id="rfc.figure.u.17"></div><pre class="text">  Accept: text/plain; q=0.5, text/html,
    10001003          text/x-dvi; q=0.8, text/x-c
    1001 </pre><p id="rfc.section.5.1.p.11">Verbally, this would be interpreted as "text/html and text/x-c are the preferred media types, but if they do not exist, then
     1004</pre><p id="rfc.section.5.1.p.12">Verbally, this would be interpreted as "text/html and text/x-c are the preferred media types, but if they do not exist, then
    10021005         send the text/x-dvi entity, and if that does not exist, send the text/plain entity."
    10031006      </p>
    1004       <p id="rfc.section.5.1.p.12">Media ranges can be overridden by more specific media ranges or specific media types. If more than one media range applies
     1007      <p id="rfc.section.5.1.p.13">Media ranges can be overridden by more specific media ranges or specific media types. If more than one media range applies
    10051008         to a given type, the most specific reference has precedence. For example,
    10061009      </p>
    10071010      <div id="rfc.figure.u.18"></div><pre class="text">  Accept: text/*, text/html, text/html;level=1, */*
    1008 </pre><p id="rfc.section.5.1.p.14">have the following precedence: </p>
     1011</pre><p id="rfc.section.5.1.p.15">have the following precedence: </p>
    10091012      <ol>
    10101013         <li>text/html;level=1</li>
    … …  
    10131016         <li>*/*</li>
    10141017      </ol>
    1015       <p id="rfc.section.5.1.p.15">The media type quality factor associated with a given type is determined by finding the media range with the highest precedence
     1018      <p id="rfc.section.5.1.p.16">The media type quality factor associated with a given type is determined by finding the media range with the highest precedence
    10161019         which matches that type. For example,
    10171020      </p>
    10181021      <div id="rfc.figure.u.19"></div><pre class="text">  Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,
    10191022          text/html;level=2;q=0.4, */*;q=0.5
    1020 </pre><p id="rfc.section.5.1.p.17">would cause the following values to be associated:</p>
     1023</pre><p id="rfc.section.5.1.p.18">would cause the following values to be associated:</p>
    10211024      <div id="rfc.table.u.1">
    10221025         <table summary="" class="tt full" cellpadding="3" cellspacing="0">
    … …  
    10551058         </table>
    10561059      </div>
    1057       <p id="rfc.section.5.1.p.18"> <b>Note:</b> A user agent might be provided with a default set of quality values for certain media ranges. However, unless the user agent
     1060      <p id="rfc.section.5.1.p.19"> <b>Note:</b> A user agent might be provided with a default set of quality values for certain media ranges. However, unless the user agent
    10581061         is a closed system which cannot interact with other rendering agents, this default set ought to be configurable by the user.
    10591062      </p>
    … …  
    11181121      <p id="rfc.section.5.3.p.8">If no Accept-Encoding field is present in a request, the server <em class="bcp14">MAY</em> assume that the client will accept any content coding. In this case, if "identity" is one of the available content-codings,
    11191122         then the server <em class="bcp14">SHOULD</em> use the "identity" content-coding, unless it has additional information that a different content-coding is meaningful to the
    1120          client. 
    1121       </p>
    1122       <dl class="empty">
    1123          <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
     1123         client.
     1124      </p>
     1125      <div class="note">
     1126         <p> <b>Note:</b> If the request does not include an Accept-Encoding field, and if the "identity" content-coding is unavailable, then content-codings
    11241127            commonly understood by HTTP/1.0 clients (i.e., "gzip" and "compress") are preferred; some older clients improperly display
    11251128            messages sent with other content-codings. The server might also make this decision based on information about the particular
    11261129            user-agent or client.
    1127          </dd>
    1128          <dd> <b>Note:</b> Most HTTP/1.0 applications do not recognize or obey qvalues associated with content-codings. This means that qvalues will
     1130         </p>
     1131      </div>
     1132      <div class="note">
     1133         <p> <b>Note:</b> Most HTTP/1.0 applications do not recognize or obey qvalues associated with content-codings. This means that qvalues will
    11291134            not work and are not permitted with x-gzip or x-compress.
    1130          </dd>
    1131       </dl>
     1135         </p>
     1136      </div>
    11321137      <div id="rfc.iref.a.4"></div>
    11331138      <div id="rfc.iref.h.4"></div>
    … …  
    11551160      </blockquote>
    11561161      <p id="rfc.section.5.4.p.8">The special range "*", if present in the Accept-Language field, matches every tag not matched by any other range present in
    1157          the Accept-Language field. 
    1158       </p>
    1159       <dl class="empty">
    1160          <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
     1162         the Accept-Language field.
     1163      </p>
     1164      <div class="note">
     1165         <p> <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
    11611166            true that if a user understands a language with a certain tag, then this user will also understand all languages with tags
    11621167            for which this tag is a prefix. The prefix rule simply allows the use of prefix tags if this is the case.
    1163          </dd>
    1164       </dl>
    1165       <p id="rfc.section.5.4.p.9">The language quality factor assigned to a language-tag by the Accept-Language field is the quality value of the longest language-range
     1168         </p>
     1169      </div>
     1170      <p id="rfc.section.5.4.p.10">The language quality factor assigned to a language-tag by the Accept-Language field is the quality value of the longest language-range
    11661171         in the field that matches the language-tag. If no language-range in the field matches the tag, the language quality factor
    11671172         assigned is 0. If no Accept-Language header is present in the request, the server <em class="bcp14">SHOULD</em> assume that all languages are equally acceptable. If an Accept-Language header is present, then all languages which are assigned
    11681173         a quality factor greater than 0 are acceptable.
    11691174      </p>
    1170       <p id="rfc.section.5.4.p.10">It might be contrary to the privacy expectations of the user to send an Accept-Language header with the complete linguistic
     1175      <p id="rfc.section.5.4.p.11">It might be contrary to the privacy expectations of the user to send an Accept-Language header with the complete linguistic
    11711176         preferences of the user in every request. For a discussion of this issue, see <a href="#privacy.issues.connected.to.accept.headers" title="Privacy Issues Connected to Accept Headers">Section&nbsp;7.1</a>.
    11721177      </p>
    1173       <p id="rfc.section.5.4.p.11">As intelligibility is highly dependent on the individual user, it is recommended that client applications make the choice
    1174          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. 
    1175       </p>
    1176       <dl class="empty">
    1177          <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
     1178      <p id="rfc.section.5.4.p.12">As intelligibility is highly dependent on the individual user, it is recommended that client applications make the choice
     1179         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.
     1180      </p>
     1181      <div class="note">
     1182         <p> <b>Note:</b> When making the choice of linguistic preference available to the user, we remind implementors of the fact that users are not
    11781183            familiar with the details of language matching as described above, and should provide appropriate guidance. As an example,
    11791184            users might assume that on selecting "en-gb", they will be served any kind of English document if British English is not available.
    11801185            A user agent might suggest in such a case to add "en" to get the best matching behavior.
    1181          </dd>
    1182       </dl>
     1186         </p>
     1187      </div>
    11831188      <div id="rfc.iref.c.2"></div>
    11841189      <div id="rfc.iref.h.5"></div>
    … …  
    12791284         The Transfer-Encoding header field is not allowed within body-parts.
    12801285      </p>
    1281       <p id="rfc.section.5.8.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. 
    1282       </p>
    1283       <dl class="empty">
    1284          <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
     1286      <p id="rfc.section.5.8.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.
     1287      </p>
     1288      <div class="note">
     1289         <p> <b>Note:</b> while the definition of Content-MD5 is exactly the same for HTTP as in RFC 1864 for MIME entity-bodies, there are several
    12851290            ways in which the application of Content-MD5 to HTTP entity-bodies differs from its application to MIME entity-bodies. One
    12861291            is that HTTP, unlike MIME, does not use Content-Transfer-Encoding, and does use Transfer-Encoding and Content-Encoding. Another
    … …  
    12881293            used to compute the digest is the transmission byte order defined for the type. Lastly, HTTP allows transmission of text types
    12891294            with any of several line break conventions and not just the canonical form using CRLF.
    1290          </dd>
    1291       </dl>
     1295         </p>
     1296      </div>
    12921297      <div id="rfc.iref.c.6"></div>
    12931298      <div id="rfc.iref.h.9"></div>

  • draft-ietf-httpbis/latest/p3-payload.xml

    r547 r563  
    350350   to determine the exact mapping is not permitted.
    351351</t>
    352 <t><list><t>
    353       <x:h>Note:</x:h> This use of the term "character set" is more commonly
    354       referred to as a "character encoding." However, since HTTP and
    355       MIME share the same registry, it is important that the terminology
    356       also be shared.
    357 </t></list></t>
     352<x:note>
     353  <t>
     354    <x:h>Note:</x:h> This use of the term "character set" is more commonly
     355    referred to as a "character encoding." However, since HTTP and
     356    MIME share the same registry, it is important that the terminology
     357    also be shared.
     358  </t>
     359</x:note>
    358360<t anchor="rule.charset">
    359361  <x:anchor-alias value="charset"/>
    … …  
    603605   application &MUST; treat it as being equivalent to "multipart/mixed".
    604606</t>
    605 <t><list><t>
    606       <x:h>Note:</x:h> The "multipart/form-data" type has been specifically defined
    607       for carrying form data suitable for processing via the POST
    608       request method, as described in <xref target="RFC2388"/>.
    609 </t></list></t>
     607<x:note>
     608  <t>
     609    <x:h>Note:</x:h> The "multipart/form-data" type has been specifically defined
     610    for carrying form data suitable for processing via the POST
     611    request method, as described in <xref target="RFC2388"/>.
     612  </t>
     613</x:note>
    610614</section>
    611615</section>
    … …  
    756760   the process of selecting the best representation for a given response
    757761   when there are multiple representations available.
    758   <list><t>
    759       <x:h>Note:</x:h> This is not called "format negotiation" because the
    760       alternate representations may be of the same media type, but use
    761       different capabilities of that type, be in different languages,
    762       etc.
    763   </t></list>
    764 </t>
     762</t>
     763<x:note>
     764  <t>
     765    <x:h>Note:</x:h> This is not called "format negotiation" because the
     766    alternate representations may be of the same media type, but use
     767    different capabilities of that type, be in different languages,
     768    etc.
     769  </t>
     770</x:note>
    765771<t>
    766772   Any response containing an entity-body &MAY; be subject to negotiation,
    … …  
    954960   media-range, using the qvalue scale from 0 to 1 (&qvalue;). The
    955961   default value is q=1.
    956   <list><t>
    957       <x:h>Note:</x:h> Use of the "q" parameter name to separate media type
    958       parameters from Accept extension parameters is due to historical
    959       practice. Although this prevents any media type parameter named
    960       "q" from being used with a media range, such an event is believed
    961       to be unlikely given the lack of any "q" parameters in the IANA
    962       media type registry and the rare usage of any media type
    963       parameters in Accept. Future media types are discouraged from
    964       registering any parameter named "q".
    965   </t></list>
    966 </t>
     962</t>
     963<x:note>
     964  <t>
     965    <x:h>Note:</x:h> Use of the "q" parameter name to separate media type
     966    parameters from Accept extension parameters is due to historical
     967    practice. Although this prevents any media type parameter named
     968    "q" from being used with a media range, such an event is believed
     969    to be unlikely given the lack of any "q" parameters in the IANA
     970    media type registry and the rare usage of any media type
     971    parameters in Accept. Future media types are discouraged from
     972    registering any parameter named "q".
     973  </t>
     974</x:note>
    967975<t>
    968976   The example
    … …  
    11541162   additional information that a different content-coding is meaningful
    11551163   to the client.
    1156   <list><t>
    1157       <x:h>Note:</x:h> If the request does not include an Accept-Encoding field,
    1158       and if the "identity" content-coding is unavailable, then
    1159       content-codings commonly understood by HTTP/1.0 clients (i.e.,
    1160       "gzip" and "compress") are preferred; some older clients
    1161       improperly display messages sent with other content-codings.  The
    1162       server might also make this decision based on information about
    1163       the particular user-agent or client.
    1164     </t><t>
    1165       <x:h>Note:</x:h> Most HTTP/1.0 applications do not recognize or obey qvalues
    1166       associated with content-codings. This means that qvalues will not
    1167       work and are not permitted with x-gzip or x-compress.
    1168     </t></list>
    1169 </t>
     1164</t>
     1165<x:note>
     1166  <t>
     1167    <x:h>Note:</x:h> If the request does not include an Accept-Encoding field,
     1168    and if the "identity" content-coding is unavailable, then
     1169    content-codings commonly understood by HTTP/1.0 clients (i.e.,
     1170    "gzip" and "compress") are preferred; some older clients
     1171    improperly display messages sent with other content-codings.  The
     1172    server might also make this decision based on information about
     1173    the particular user-agent or client.
     1174  </t>
     1175</x:note>
     1176<x:note>
     1177  <t>
     1178    <x:h>Note:</x:h> Most HTTP/1.0 applications do not recognize or obey qvalues
     1179    associated with content-codings. This means that qvalues will not
     1180    work and are not permitted with x-gzip or x-compress.
     1181  </t>
     1182</x:note>
    11701183</section>
    11711184
    … …  
    12181231   matches every tag not matched by any other range present in the
    12191232   Accept-Language field.
    1220   <list><t>
    1221       <x:h>Note:</x:h> This use of a prefix matching rule does not imply that
    1222       language tags are assigned to languages in such a way that it is
    1223       always true that if a user understands a language with a certain
    1224       tag, then this user will also understand all languages with tags
    1225       for which this tag is a prefix. The prefix rule simply allows the
    1226       use of prefix tags if this is the case.
    1227   </t></list>
    1228 </t>
     1233</t>
     1234<x:note>
     1235  <t>
     1236    <x:h>Note:</x:h> This use of a prefix matching rule does not imply that
     1237    language tags are assigned to languages in such a way that it is
     1238    always true that if a user understands a language with a certain
     1239    tag, then this user will also understand all languages with tags
     1240    for which this tag is a prefix. The prefix rule simply allows the
     1241    use of prefix tags if this is the case.
     1242  </t>
     1243</x:note>
    12291244<t>
    12301245   The language quality factor assigned to a language-tag by the
    … …  
    12501265   available, then the Accept-Language header field &MUST-NOT; be given in
    12511266   the request.
    1252   <list><t>
    1253       <x:h>Note:</x:h> When making the choice of linguistic preference available to
    1254       the user, we remind implementors of  the fact that users are not
    1255       familiar with the details of language matching as described above,
    1256       and should provide appropriate guidance. As an example, users
    1257       might assume that on selecting "en-gb", they will be served any
    1258       kind of English document if British English is not available. A
    1259       user agent might suggest in such a case to add "en" to get the
    1260       best matching behavior.
    1261   </t></list>
    1262 </t>
     1267</t>
     1268<x:note>
     1269  <t>
     1270    <x:h>Note:</x:h> When making the choice of linguistic preference available to
     1271    the user, we remind implementors of  the fact that users are not
     1272    familiar with the details of language matching as described above,
     1273    and should provide appropriate guidance. As an example, users
     1274    might assume that on selecting "en-gb", they will be served any
     1275    kind of English document if British English is not available. A
     1276    user agent might suggest in such a case to add "en" to get the
     1277    best matching behavior.
     1278  </t>
     1279</x:note>
    12631280</section>
    12641281
    … …  
    14771494   the text actually transmitted &MUST; be left unaltered when computing
    14781495   the digest.
    1479   <list><t>
    1480       <x:h>Note:</x:h> while the definition of Content-MD5 is exactly the same for
    1481       HTTP as in RFC 1864 for MIME entity-bodies, there are several ways
    1482       in which the application of Content-MD5 to HTTP entity-bodies
    1483       differs from its application to MIME entity-bodies. One is that
    1484       HTTP, unlike MIME, does not use Content-Transfer-Encoding, and
    1485       does use Transfer-Encoding and Content-Encoding. Another is that
    1486       HTTP more frequently uses binary content types than MIME, so it is
    1487       worth noting that, in such cases, the byte order used to compute
    1488       the digest is the transmission byte order defined for the type.
    1489       Lastly, HTTP allows transmission of text types with any of several
    1490       line break conventions and not just the canonical form using CRLF.
    1491   </t></list>
    1492 </t>
     1496</t>
     1497<x:note>
     1498  <t>
     1499    <x:h>Note:</x:h> while the definition of Content-MD5 is exactly the same for
     1500    HTTP as in RFC 1864 for MIME entity-bodies, there are several ways
     1501    in which the application of Content-MD5 to HTTP entity-bodies
     1502    differs from its application to MIME entity-bodies. One is that
     1503    HTTP, unlike MIME, does not use Content-Transfer-Encoding, and
     1504    does use Transfer-Encoding and Content-Encoding. Another is that
     1505    HTTP more frequently uses binary content types than MIME, so it is
     1506    worth noting that, in such cases, the byte order used to compute
     1507    the digest is the transmission byte order defined for the type.
     1508    Lastly, HTTP allows transmission of text types with any of several
     1509    line break conventions and not just the canonical form using CRLF.
     1510  </t>
     1511</x:note>
    14931512</section>
    14941513

  • draft-ietf-httpbis/latest/p4-conditional.html

    r560 r563  
    2929cite {
    3030  font-style: normal;
     31}
     32div.note {
     33  margin-left: 2em;
    3134}
    3235dd {
    … …  
    464467         <tr>
    465468            <td class="header left"></td>
    466             <td class="header right">March 12, 2009</td>
     469            <td class="header right">March 24, 2009</td>
    467470         </tr>
    468471      </table>
    … …  
    792795         value.
    793796      </p>
    794       <p id="rfc.section.5.p.4">In order to be legal, a strong entity tag <em class="bcp14">MUST</em> change whenever the associated entity changes in any way. A weak entity tag <em class="bcp14">SHOULD</em> change whenever the associated entity changes in a semantically significant way. 
    795       </p>
    796       <dl class="empty">
    797          <dd> <b>Note:</b> in order to provide semantically transparent caching, an origin server must avoid reusing a specific strong entity tag value
     797      <p id="rfc.section.5.p.4">In order to be legal, a strong entity tag <em class="bcp14">MUST</em> change whenever the associated entity changes in any way. A weak entity tag <em class="bcp14">SHOULD</em> change whenever the associated entity changes in a semantically significant way.
     798      </p>
     799      <div class="note">
     800         <p> <b>Note:</b> in order to provide semantically transparent caching, an origin server must avoid reusing a specific strong entity tag value
    798801            for two different entities, or reusing a specific weak entity tag value for two semantically different entities. Cache entries
    799802            might persist for arbitrarily long periods, regardless of expiration times, so it might be inappropriate to expect that a
    800803            cache will never again attempt to validate an entry using a validator that it obtained at some point in the past.
    801          </dd>
    802       </dl>
    803       <p id="rfc.section.5.p.5">HTTP/1.1 clients: </p>
     804         </p>
     805      </div>
     806      <p id="rfc.section.5.p.6">HTTP/1.1 clients: </p>
    804807      <ul>
    805808         <li>If an entity tag has been provided by the origin server, <em class="bcp14">MUST</em> use that entity tag in any cache-conditional request (using If-Match or If-None-Match).
    … …  
    812815         </li>
    813816      </ul>
    814       <p id="rfc.section.5.p.6">An HTTP/1.1 origin server, upon receiving a conditional request that includes both a Last-Modified date (e.g., in an If-Modified-Since
     817      <p id="rfc.section.5.p.7">An HTTP/1.1 origin server, upon receiving a conditional request that includes both a Last-Modified date (e.g., in an If-Modified-Since
    815818         or If-Unmodified-Since header field) and one or more entity tags (e.g., in an If-Match, If-None-Match, or If-Range header
    816819         field) as cache validators, <em class="bcp14">MUST NOT</em> return a response status of 304 (Not Modified) unless doing so is consistent with all of the conditional header fields in
    817820         the request.
    818821      </p>
    819       <p id="rfc.section.5.p.7">An HTTP/1.1 caching proxy, upon receiving a conditional request that includes both a Last-Modified date and one or more entity
     822      <p id="rfc.section.5.p.8">An HTTP/1.1 caching proxy, upon receiving a conditional request that includes both a Last-Modified date and one or more entity
    820823         tags as cache validators, <em class="bcp14">MUST NOT</em> return a locally cached response to the client unless that cached response is consistent with all of the conditional header
    821824         fields in the request.

  • draft-ietf-httpbis/latest/p4-conditional.xml

    r547 r563  
    602602   change whenever the associated entity changes in a semantically
    603603   significant way.
    604   <list><t>
    605       <x:h>Note:</x:h> in order to provide semantically transparent caching, an
    606       origin server must avoid reusing a specific strong entity tag
    607       value for two different entities, or reusing a specific weak
    608       entity tag value for two semantically different entities. Cache
    609       entries might persist for arbitrarily long periods, regardless of
    610       expiration times, so it might be inappropriate to expect that a
    611       cache will never again attempt to validate an entry using a
    612       validator that it obtained at some point in the past.
    613   </t></list>
    614 </t>
     604</t>
     605<x:note>
     606  <t>
     607    <x:h>Note:</x:h> in order to provide semantically transparent caching, an
     608    origin server must avoid reusing a specific strong entity tag
     609    value for two different entities, or reusing a specific weak
     610    entity tag value for two semantically different entities. Cache
     611    entries might persist for arbitrarily long periods, regardless of
     612    expiration times, so it might be inappropriate to expect that a
     613    cache will never again attempt to validate an entry using a
     614    validator that it obtained at some point in the past.
     615  </t>
     616</x:note>
    615617<t>
    616618   HTTP/1.1 clients:

  • draft-ietf-httpbis/latest/p5-range.html

    r560 r563  
    2929cite {
    3030  font-style: normal;
     31}
     32div.note {
     33  margin-left: 2em;
    3134}
    3235dd {
    … …  
    464467         <tr>
    465468            <td class="header left"></td>
    466             <td class="header right">March 12, 2009</td>
     469            <td class="header right">March 24, 2009</td>
    467470         </tr>
    468471      </table>
    … …  
    761764      <p id="rfc.section.5.2.p.14">If the server receives a request (other than one including an If-Range request-header field) with an unsatisfiable Range request-header
    762765         field (that is, all of whose byte-range-spec values have a first-byte-pos value greater than the current length of the selected
    763          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.1" title="416 Requested Range Not Satisfiable">Section&nbsp;3.2</a>). 
    764       </p>
    765       <dl class="empty">
    766          <dd> <b>Note:</b> clients cannot depend on servers to send a 416 (Requested range not satisfiable) response instead of a 200 (OK) response for
     766         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.1" title="416 Requested Range Not Satisfiable">Section&nbsp;3.2</a>).
     767      </p>
     768      <div class="note">
     769         <p> <b>Note:</b> clients cannot depend on servers to send a 416 (Requested range not satisfiable) response instead of a 200 (OK) response for
    767770            an unsatisfiable Range request-header, since not all servers implement this request-header.
    768          </dd>
    769       </dl>
     771         </p>
     772      </div>
    770773      <div id="rfc.iref.i.1"></div>
    771774      <div id="rfc.iref.h.3"></div>

  • draft-ietf-httpbis/latest/p5-range.xml

    r547 r563  
    629629   resource), it &SHOULD; return a response code of 416 (Requested range
    630630   not satisfiable) (<xref target="status.416"/>).
    631   <list><t>
    632       <x:h>Note:</x:h> clients cannot depend on servers to send a 416 (Requested
    633       range not satisfiable) response instead of a 200 (OK) response for
    634       an unsatisfiable Range request-header, since not all servers
    635       implement this request-header.
    636   </t></list>
    637 </t>
     631</t>
     632<x:note>
     633  <t>
     634    <x:h>Note:</x:h> clients cannot depend on servers to send a 416 (Requested
     635    range not satisfiable) response instead of a 200 (OK) response for
     636    an unsatisfiable Range request-header, since not all servers
     637    implement this request-header.
     638  </t>
     639</x:note>
    638640</section>
    639641
Note: See TracChangeset for help on using the changeset viewer.