Changeset 172
- Timestamp:
- 23/01/08 02:11:10 (14 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 8 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r171 r172 792 792 </dl> 793 793 <h2 id="rfc.section.1.4"><a href="#rfc.section.1.4">1.4</a> <a id="intro.overall.operation" href="#intro.overall.operation">Overall Operation</a></h2> 794 <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,795 URI, and protocol version, followed by a MIME-like message containing request modifiers, client information, and possible796 body content over a connection with a server. The server responds with a status line, including the message's protocol version797 and a success or error code, followed by a MIME-like message containing server information, entity metainformation, and possible798 entity-bodycontent. The relationship between HTTP and MIME is described in <a href="p3-payload.html#differences.between.http.entities.and.rfc.2045.entities" title="Differences Between HTTP Entities and RFC 2045 Entities">Appendix A</a> of <a href="#Part3" id="rfc.xref.Part3.4"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>.794 <p id="rfc.section.1.4.p.1">HTTP is a request/response protocol. A client sends a request to the server in the form of a request method, URI, and protocol 795 version, followed by a MIME-like message containing request modifiers, client information, and possible body content over 796 a connection with a server. The server responds with a status line, including the message's protocol version and a success 797 or error code, followed by a MIME-like message containing server information, entity metainformation, and possible entity-body 798 content. The relationship between HTTP and MIME is described in <a href="p3-payload.html#differences.between.http.entities.and.rfc.2045.entities" title="Differences Between HTTP Entities and RFC 2045 Entities">Appendix A</a> of <a href="#Part3" id="rfc.xref.Part3.4"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>. 799 799 </p> 800 800 <p id="rfc.section.1.4.p.2">Most HTTP communication is initiated by a user agent and consists of a request to be applied to a resource on some origin … … 1019 1019 "rel_path", "query", and "authority" from that specification. 1020 1020 </p> 1021 <p id="rfc.section.3.2.1.p.2"> The HTTP protocoldoes not place any a priori limit on the length of a URI. Servers <em class="bcp14">MUST</em> be able to handle the URI of any resource they serve, and <em class="bcp14">SHOULD</em> be able to handle URIs of unbounded length if they provide GET-based forms that could generate such URIs. A server <em class="bcp14">SHOULD</em> return 414 (Request-URI Too Long) status if a URI is longer than the server can handle (see <a href="p2-semantics.html#status.414" title="414 Request-URI Too Long">Section 9.4.15</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).1021 <p id="rfc.section.3.2.1.p.2">HTTP does not place any a priori limit on the length of a URI. Servers <em class="bcp14">MUST</em> be able to handle the URI of any resource they serve, and <em class="bcp14">SHOULD</em> be able to handle URIs of unbounded length if they provide GET-based forms that could generate such URIs. A server <em class="bcp14">SHOULD</em> return 414 (Request-URI Too Long) status if a URI is longer than the server can handle (see <a href="p2-semantics.html#status.414" title="414 Request-URI Too Long">Section 9.4.15</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). 1022 1022 </p> 1023 1023 <p id="rfc.section.3.2.1.p.3"> </p> … … 1862 1862 <h2 id="rfc.section.10.1"><a href="#rfc.section.10.1">10.1</a> <a id="personal.information" href="#personal.information">Personal Information</a></h2> 1863 1863 <p id="rfc.section.10.1.p.1">HTTP clients are often privy to large amounts of personal information (e.g. the user's name, location, mail address, passwords, 1864 encryption keys, etc.), and <em class="bcp14">SHOULD</em> be very careful to prevent unintentional leakage of this information via the HTTP protocol to other sources. We very strongly1865 recommend that a convenient interface be provided for the user to control dissemination of such information, and that designers1866 and implementors be particularly careful in this area. History shows that errors in this area often create serious security1867 and/or privacy problems and generatehighly adverse publicity for the implementor's company.1864 encryption keys, etc.), and <em class="bcp14">SHOULD</em> be very careful to prevent unintentional leakage of this information. We very strongly recommend that a convenient interface 1865 be provided for the user to control dissemination of such information, and that designers and implementors be particularly 1866 careful in this area. History shows that errors in this area often create serious security and/or privacy problems and generate 1867 highly adverse publicity for the implementor's company. 1868 1868 </p> 1869 1869 <h2 id="rfc.section.10.2"><a href="#rfc.section.10.2">10.2</a> <a id="abuse.of.server.log.information" href="#abuse.of.server.log.information">Abuse of Server Log Information</a></h2> 1870 1870 <p id="rfc.section.10.2.p.1">A server is in the position to save personal data about a user's requests which might identify their reading patterns or subjects 1871 1871 of interest. This information is clearly confidential in nature and its handling can be constrained by law in certain countries. 1872 People using the HTTP protocol to provide data are responsible for ensuring that such material is not distributed without1873 the permissionof any individuals that are identifiable by the published results.1872 People using HTTP to provide data are responsible for ensuring that such material is not distributed without the permission 1873 of any individuals that are identifiable by the published results. 1874 1874 </p> 1875 1875 <h2 id="rfc.section.10.3"><a href="#rfc.section.10.3">10.3</a> <a id="attack.pathname" href="#attack.pathname">Attacks Based On File and Path Names</a></h2> … … 1926 1926 Internet mail message formats. 1927 1927 </p> 1928 <p id="rfc.section.11.p.2"> The HTTP protocol has evolved considerably over the years. It has benefited from a large and active developer community--the1929 many people who have participated on the www-talk mailing list--and it is that community which has been most responsible for1930 the success of HTTP and of the World-Wide Web in general. Marc Andreessen, Robert Cailliau, Daniel W. Connolly, Bob Denny,1931 J ohn Franks, Jean-Francois Groff, Phillip M. Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob McCool, Lou Montulli, Dave Raggett,1932 Tony Sanders,and Marc VanHeyningen deserve special recognition for their efforts in defining early aspects of the protocol.1928 <p id="rfc.section.11.p.2">HTTP has evolved considerably over the years. It has benefited from a large and active developer community--the many people 1929 who have participated on the www-talk mailing list--and it is that community which has been most responsible for the success 1930 of HTTP and of the World-Wide Web in general. Marc Andreessen, Robert Cailliau, Daniel W. Connolly, Bob Denny, John Franks, 1931 Jean-Francois Groff, Phillip M. Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob McCool, Lou Montulli, Dave Raggett, Tony Sanders, 1932 and Marc VanHeyningen deserve special recognition for their efforts in defining early aspects of the protocol. 1933 1933 </p> 1934 1934 <p id="rfc.section.11.p.3">This document has benefited greatly from the comments of all those participating in the HTTP-WG. In addition to those already … … 2156 2156 <span class="n hidden"><span class="family-name">Reschke</span><span class="given-name">Julian F.</span></span></span><span class="org vcardline">greenbytes GmbH</span><span class="adr"><span class="street-address vcardline">Hafenweg 16</span><span class="vcardline"><span class="locality">Muenster</span>, <span class="region">NW</span> <span class="postal-code">48155</span></span><span class="country-name vcardline">Germany</span></span><span class="vcardline tel">Phone: <a href="tel:+492512807760"><span class="value">+49 251 2807760</span></a></span><span class="vcardline tel"><span class="type">Fax</span>: <a href="fax:+492512807761"><span class="value">+49 251 2807761</span></a></span><span class="vcardline">EMail: <a><span class="email">julian.reschke@greenbytes.de</span></a></span><span class="vcardline">URI: <a href="http://greenbytes.de/tech/webdav/" class="url">http://greenbytes.de/tech/webdav/</a></span></address> 2157 2157 <h1 id="rfc.section.A"><a href="#rfc.section.A">A.</a> <a id="internet.media.type.http" href="#internet.media.type.http">Internet Media Types</a></h1> 2158 <p id="rfc.section.A.p.1">In addition to defining the HTTP/1.1 protocol, this document serves as the specification for the Internet media type "message/http"2159 and"application/http". The following is to be registered with IANA <a href="#RFC4288" id="rfc.xref.RFC4288.1"><cite title="Media Type Specifications and Registration Procedures">[RFC4288]</cite></a>.2158 <p id="rfc.section.A.p.1">In addition to defining HTTP/1.1, this document serves as the specification for the Internet media type "message/http" and 2159 "application/http". The following is to be registered with IANA <a href="#RFC4288" id="rfc.xref.RFC4288.1"><cite title="Media Type Specifications and Registration Procedures">[RFC4288]</cite></a>. 2160 2160 </p> 2161 2161 <div id="rfc.iref.m.2"></div> -
draft-ietf-httpbis/latest/p1-messaging.xml
r171 r172 556 556 <section title="Overall Operation" anchor="intro.overall.operation"> 557 557 <t> 558 The HTTP protocolis a request/response protocol. A client sends a558 HTTP is a request/response protocol. A client sends a 559 559 request to the server in the form of a request method, URI, and 560 560 protocol version, followed by a MIME-like message containing request … … 1031 1031 </t> 1032 1032 <t> 1033 The HTTP protocoldoes not place any a priori limit on the length of1033 HTTP does not place any a priori limit on the length of 1034 1034 a URI. Servers &MUST; be able to handle the URI of any resource they 1035 1035 serve, and &SHOULD; be able to handle URIs of unbounded length if they … … 2745 2745 (e.g. the user's name, location, mail address, passwords, encryption 2746 2746 keys, etc.), and &SHOULD; be very careful to prevent unintentional 2747 leakage of this information via the HTTP protocol to other sources.2747 leakage of this information. 2748 2748 We very strongly recommend that a convenient interface be provided 2749 2749 for the user to control dissemination of such information, and that … … 2761 2761 interest. This information is clearly confidential in nature and its 2762 2762 handling can be constrained by law in certain countries. People using 2763 the HTTP protocolto provide data are responsible for ensuring that2763 HTTP to provide data are responsible for ensuring that 2764 2764 such material is not distributed without the permission of any 2765 2765 individuals that are identifiable by the published results. … … 2881 2881 </t> 2882 2882 <t> 2883 The HTTP protocolhas evolved considerably over the years. It has2883 HTTP has evolved considerably over the years. It has 2884 2884 benefited from a large and active developer community--the many 2885 2885 people who have participated on the www-talk mailing list--and it is … … 3664 3664 <section title="Internet Media Types" anchor="internet.media.type.http"> 3665 3665 <t> 3666 In addition to defining the HTTP/1.1 protocol, this document serves3666 In addition to defining HTTP/1.1, this document serves 3667 3667 as the specification for the Internet media type "message/http" and 3668 3668 "application/http". The following is to be registered with IANA <xref target="RFC4288"/>. -
draft-ietf-httpbis/latest/p2-semantics.html
r170 r172 1342 1342 <div id="rfc.iref.s.41"></div> 1343 1343 <h3 id="rfc.section.9.5.6"><a href="#rfc.section.9.5.6">9.5.6</a> <a id="status.505" href="#status.505">505 HTTP Version Not Supported</a></h3> 1344 <p id="rfc.section.9.5.6.p.1">The server does not support, or refuses to support, the HTTPprotocol version that was used in the request message. The server1344 <p id="rfc.section.9.5.6.p.1">The server does not support, or refuses to support, the protocol version that was used in the request message. The server 1345 1345 is indicating that it is unable or unwilling to complete the request using the same major version as the client, as described 1346 1346 in <a href="p1-messaging.html#http.version" title="HTTP Version">Section 3.1</a> of <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, other than with this error message. The response <em class="bcp14">SHOULD</em> contain an entity describing why that version is not supported and what other protocols are supported by that server. … … 1546 1546 <p id="rfc.section.12.2.p.2">Clients <em class="bcp14">SHOULD NOT</em> include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol. 1547 1547 </p> 1548 <p id="rfc.section.12.2.p.3">Authors of services which use the HTTP protocol <em class="bcp14">SHOULD NOT</em> use GET based forms for the submission of sensitive data, because this will cause this data to be encoded in the Request-URI.1549 Many existing servers, proxies, and user agents will log the request URI in some place where it might be visible to third1550 parties. Servers can use POST-based form submission instead1548 <p id="rfc.section.12.2.p.3">Authors of services should not use GET-based forms for the submission of sensitive data because that data will be encoded 1549 in the Request-URI. Many existing servers, proxies, and user agents log or display the Request-URI in places where it might 1550 be visible to third parties. Such services can use POST-based form submission instead. 1551 1551 </p> 1552 1552 <h2 id="rfc.section.12.3"><a href="#rfc.section.12.3">12.3</a> <a id="location.spoofing" href="#location.spoofing">Location Headers and Spoofing</a></h2> -
draft-ietf-httpbis/latest/p2-semantics.xml
r170 r172 1627 1627 <iref primary="true" item="Status Codes" subitem="505 HTTP Version Not Supported" x:for-anchor=""/> 1628 1628 <t> 1629 The server does not support, or refuses to support, the HTTPprotocol1629 The server does not support, or refuses to support, the protocol 1630 1630 version that was used in the request message. The server is 1631 1631 indicating that it is unable or unwilling to complete the request … … 2055 2055 </t> 2056 2056 <t> 2057 Clients &SHOULD-NOT; 2057 Clients &SHOULD-NOT; include a Referer header field in a (non-secure) 2058 2058 HTTP request if the referring page was transferred with a secure 2059 2059 protocol. 2060 2060 </t> 2061 2061 <t> 2062 Authors of services which use the HTTP protocol &SHOULD-NOT; use GET2063 based forms for the submission of sensitive data, because this will2064 cause this data tobe encoded in the Request-URI. Many existing2065 servers, proxies, and user agents will log the request URI in some2066 place where it might be visible to third parties. Servers can use2067 POST-based form submission instead2062 Authors of services should not use 2063 GET-based forms for the submission of sensitive data because that 2064 data will be encoded in the Request-URI. Many existing 2065 servers, proxies, and user agents log or display the Request-URI in 2066 places where it might be visible to third parties. Such services can 2067 use POST-based form submission instead. 2068 2068 </t> 2069 2069 </section> -
draft-ietf-httpbis/latest/p4-conditional.html
r170 r172 624 624 <p id="rfc.section.4.p.6">Clients <em class="bcp14">MAY</em> issue simple (non-subrange) GET requests with either weak validators or strong validators. Clients <em class="bcp14">MUST NOT</em> use weak validators in other forms of request. 625 625 </p> 626 <p id="rfc.section.4.p.7">The only function that the HTTP/1.1 protocol defines on validators is comparison. There are two validator comparison functions,627 dependingon whether the comparison context allows the use of weak validators or not:626 <p id="rfc.section.4.p.7">The only function that HTTP/1.1 defines on validators is comparison. There are two validator comparison functions, depending 627 on whether the comparison context allows the use of weak validators or not: 628 628 </p> 629 629 <ul> -
draft-ietf-httpbis/latest/p4-conditional.xml
r170 r172 402 402 </t> 403 403 <t> 404 The only function that the HTTP/1.1 protocoldefines on validators is404 The only function that HTTP/1.1 defines on validators is 405 405 comparison. There are two validator comparison functions, depending 406 406 on whether the comparison context allows the use of weak validators -
draft-ietf-httpbis/latest/p6-cache.html
r170 r172 934 934 origin server (or possibly an intermediate cache with a fresh response) to see if its cached entry is still usable. We call 935 935 this "validating" the cache entry. Since we do not want to have to pay the overhead of retransmitting the full response if 936 the cached entry is good, and we do not want to pay the overhead of an extra round trip if the cached entry is invalid, the937 HTTP/1.1 protocolsupports the use of conditional methods.936 the cached entry is good, and we do not want to pay the overhead of an extra round trip if the cached entry is invalid, HTTP/1.1 937 supports the use of conditional methods. 938 938 </p> 939 939 <p id="rfc.section.4.p.2">The key protocol features for supporting conditional methods are those concerned with "cache validators." When an origin server … … 1029 1029 </p> 1030 1030 <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a> <a id="non-modifiable.headers" href="#non-modifiable.headers">Non-modifiable Headers</a></h2> 1031 <p id="rfc.section.6.2.p.1">Some features of the HTTP/1.1 protocol, such as Digest Authentication, depend on the value of certain end-to-end headers.1032 A transparentproxy <em class="bcp14">SHOULD NOT</em> modify an end-to-end header unless the definition of that header requires or specifically allows that.1031 <p id="rfc.section.6.2.p.1">Some features of HTTP/1.1, such as Digest Authentication, depend on the value of certain end-to-end headers. A transparent 1032 proxy <em class="bcp14">SHOULD NOT</em> modify an end-to-end header unless the definition of that header requires or specifically allows that. 1033 1033 </p> 1034 1034 <p id="rfc.section.6.2.p.2">A transparent proxy <em class="bcp14">MUST NOT</em> modify any of the following fields in a request or response, and it <em class="bcp14">MUST NOT</em> add any of these fields if not already present: … … 1155 1155 the origin server would return for a new request on that resource. 1156 1156 </p> 1157 <p id="rfc.section.11.p.2">There is no way for the HTTP protocol to guarantee that all such cache entries are marked invalid. For example, the request1158 th at caused the change at the origin server might not have gone through the proxy where a cache entry is stored. However,1159 several ruleshelp reduce the likelihood of erroneous behavior.1157 <p id="rfc.section.11.p.2">There is no way for HTTP to guarantee that all such cache entries are marked invalid. For example, the request that caused 1158 the change at the origin server might not have gone through the proxy where a cache entry is stored. However, several rules 1159 help reduce the likelihood of erroneous behavior. 1160 1160 </p> 1161 1161 <p id="rfc.section.11.p.3">In this section, the phrase "invalidate an entity" means that the cache will either remove all instances of that entity from … … 1277 1277 </pre><p id="rfc.section.15.2.p.4">When a directive appears without any 1#field-name parameter, the directive applies to the entire request or response. When 1278 1278 such a directive appears with a 1#field-name parameter, it applies only to the named field or fields, and not to the rest 1279 of the request or response. This mechanism supports extensibility; implementations of future versions of the HTTP protocol1280 might applythese directives to header fields not defined in HTTP/1.1.1279 of the request or response. This mechanism supports extensibility; implementations of future versions of HTTP might apply 1280 these directives to header fields not defined in HTTP/1.1. 1281 1281 </p> 1282 1282 <p id="rfc.section.15.2.p.5">The cache-control directives can be broken down into these general categories: </p> -
draft-ietf-httpbis/latest/p6-cache.xml
r170 r172 964 964 retransmitting the full response if the cached entry is good, and we 965 965 do not want to pay the overhead of an extra round trip if the cached 966 entry is invalid, the HTTP/1.1 protocolsupports the use of966 entry is invalid, HTTP/1.1 supports the use of 967 967 conditional methods. 968 968 </t> … … 1141 1141 <section title="Non-modifiable Headers" anchor="non-modifiable.headers"> 1142 1142 <t> 1143 Some features of the HTTP/1.1 protocol, such as Digest1143 Some features of HTTP/1.1, such as Digest 1144 1144 Authentication, depend on the value of certain end-to-end headers. A 1145 1145 transparent proxy &SHOULD-NOT; modify an end-to-end header unless the … … 1393 1393 </t> 1394 1394 <t> 1395 There is no way for the HTTP protocolto guarantee that all such1395 There is no way for HTTP to guarantee that all such 1396 1396 cache entries are marked invalid. For example, the request that 1397 1397 caused the change at the origin server might not have gone through … … 1609 1609 the named field or fields, and not to the rest of the request or 1610 1610 response. This mechanism supports extensibility; implementations of 1611 future versions of the HTTP protocolmight apply these directives to1611 future versions of HTTP might apply these directives to 1612 1612 header fields not defined in HTTP/1.1. 1613 1613 </t>
Note: See TracChangeset
for help on using the changeset viewer.