Changeset 563 for draft-ietf-httpbis/latest/p1-messaging.xml
- Timestamp:
- 24/03/09 20:48:26 (13 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.xml
r547 r563 592 592 <cref>TBD: Define and explain purpose of https scheme.</cref> 593 593 </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> 597 599 </section> 598 600 … … 825 827 the same major version as the request. 826 828 </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> 835 835 </section> 836 836 … … 869 869 in header fields. See <xref target="tolerant.applications"/> for further information. 870 870 </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> 877 879 <t> 878 880 All HTTP date/time stamps &MUST; be represented in Greenwich Mean Time … … 1308 1310 change the order of these field values when a message is forwarded. 1309 1311 </t> 1310 < t>1311 < list><t>1312 <x:note> 1313 <t> 1312 1314 <x:h>Note:</x:h> the "Set-Cookie" header as implemented in 1313 1315 practice (as opposed to how it is specified in <xref target="RFC2109"/>) … … 1316 1318 for details.) Also note that the Set-Cookie2 header specified in 1317 1319 <xref target="RFC2965"/> does not share this problem. 1318 </t> </list>1319 </ t>1320 </t> 1321 </x:note> 1320 1322 1321 1323 </section> … … 1621 1623 except as noted above to replace a null path-absolute with "/". 1622 1624 </t> 1623 < t>1624 < list><t>1625 1626 1627 1628 1629 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> 1632 1634 <t> 1633 1635 HTTP does not place a pre-defined limit on the length of a request-target.
Note: See TracChangeset
for help on using the changeset viewer.