Changeset 563 for draft-ietf-httpbis/latest/p1-messaging.html
- Timestamp:
- 24/03/09 20:48:26 (13 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r560 r563 471 471 <tr> 472 472 <td class="header left"></td> 473 <td class="header right">March 12, 2009</td>473 <td class="header right">March 24, 2009</td> 474 474 </tr> 475 475 </table> … … 845 845 <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> 846 846 </p> 847 <d l 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 </d l>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> 851 851 <h3 id="rfc.section.2.1.3"><a href="#rfc.section.2.1.3">2.1.3</a> <a id="uri.comparison" href="#uri.comparison">URI Comparison</a></h3> 852 852 <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: … … 965 965 <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. 966 966 </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> 972 971 <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a> <a id="date.time.formats" href="#date.time.formats">Date/Time Formats</a></h2> 973 972 <h3 id="rfc.section.3.2.1"><a href="#rfc.section.3.2.1">3.2.1</a> <a id="full.date" href="#full.date">Full Date</a></h3> … … 979 978 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 A</a> for further information. 980 979 </p> 981 <d l 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, 983 982 as is sometimes the case when retrieving or posting messages via proxies/gateways to SMTP or NNTP. 984 </ dd>985 </d l>983 </p> 984 </div> 986 985 <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 987 986 Universal Time). This is indicated in the first two formats by the inclusion of "GMT" as the three-letter abbreviation for … … 1219 1218 thus a proxy <em class="bcp14">MUST NOT</em> change the order of these field values when a message is forwarded. 1220 1219 </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 1224 1222 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 </d l>1223 </p> 1224 </div> 1227 1225 <h2 id="rfc.section.4.3"><a href="#rfc.section.4.3">4.3</a> <a id="message.body" href="#message.body">Message Body</a></h2> 1228 1226 <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 … … 1373 1371 above to replace a null path-absolute with "/". 1374 1372 </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 1378 1375 a non-reserved URI character for a reserved purpose. Implementors should be aware that some pre-HTTP/1.1 proxies have been 1379 1376 known to rewrite the request-target. 1380 </ dd>1381 </d l>1377 </p> 1378 </div> 1382 1379 <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 1383 1380 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.