Ignore:
Timestamp:
Mar 24, 2009, 1:48:26 PM (11 years ago)
Author:
julian.reschke@…
Message:

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

File:
1 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>).
Note: See TracChangeset for help on using the changeset viewer.