Changeset 761 for draft-ietf-httpbis/latest/p1-messaging.html
- Timestamp:
- 17/02/10 13:53:37 (12 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r756 r761 404 404 <meta name="dct.creator" content="Reschke, J. F."> 405 405 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest"> 406 <meta name="dct.issued" scheme="ISO8601" content="2010-02- 02">406 <meta name="dct.issued" scheme="ISO8601" content="2010-02-17"> 407 407 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 408 408 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 1 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 1 provides an overview of HTTP and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the generic message syntax and parsing requirements for HTTP message frames, and describes general security concerns for implementations."> … … 435 435 </tr> 436 436 <tr> 437 <td class="left">Expires: August 6, 2010</td>437 <td class="left">Expires: August 21, 2010</td> 438 438 <td class="right">HP</td> 439 439 </tr> … … 488 488 <tr> 489 489 <td class="left"></td> 490 <td class="right">February 2, 2010</td>490 <td class="right">February 17, 2010</td> 491 491 </tr> 492 492 </tbody> … … 520 520 <p>The list of Internet-Draft Shadow Directories can be accessed at <a href="http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html</a>. 521 521 </p> 522 <p>This Internet-Draft will expire in August 6, 2010.</p>522 <p>This Internet-Draft will expire in August 21, 2010.</p> 523 523 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 524 524 <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 1240 1240 <p>If the message uses the media type "multipart/byteranges", and the transfer-length is not otherwise specified, then this self-delimiting 1241 1241 media type defines the transfer-length. This media type <em class="bcp14">MUST NOT</em> be used unless the sender knows that the recipient can parse it; the presence in a request of a Range header with multiple 1242 byte-range specifiers from a 1.1 client implies that the client can parse multipart/byteranges responses.1242 byte-range specifiers from a HTTP/1.1 client implies that the client can parse multipart/byteranges responses. 1243 1243 </p> 1244 1244 <ul class="empty"> 1245 <li>A range header might be forwarded by a 1.0 proxy that does not understand multipart/byteranges; in this case the server <em class="bcp14">MUST</em> delimit the message using methods defined in items 1, 3 or 5 of this section.1245 <li>A range header might be forwarded by a HTTP/1.0 proxy that does not understand multipart/byteranges; in this case the server <em class="bcp14">MUST</em> delimit the message using methods defined in items 1, 3 or 5 of this section. 1246 1246 </li> 1247 1247 </ul> … … 1653 1653 <h3 id="rfc.section.7.1.1"><a href="#rfc.section.7.1.1">7.1.1</a> <a id="persistent.purpose" href="#persistent.purpose">Purpose</a></h3> 1654 1654 <p id="rfc.section.7.1.1.p.1">Prior to persistent connections, a separate TCP connection was established to fetch each URL, increasing the load on HTTP 1655 servers and causing congestion on the Internet. The use of inline images and other associated data often require a client1655 servers and causing congestion on the Internet. The use of inline images and other associated data often requires a client 1656 1656 to make multiple requests of the same server in a short amount of time. Analysis of these performance problems and results 1657 1657 from a prototype implementation are available <a href="#Pad1995" id="rfc.xref.Pad1995.1"><cite title="Improving HTTP Latency">[Pad1995]</cite></a> <a href="#Spe" id="rfc.xref.Spe.1"><cite title="Analysis of HTTP Performance Problems">[Spe]</cite></a>. Implementation experience and measurements of actual HTTP/1.1 implementations show good results <a href="#Nie1997" id="rfc.xref.Nie1997.1"><cite title="Network Performance Effects of HTTP/1.1, CSS1, and PNG">[Nie1997]</cite></a>. Alternatives have also been explored, for example, T/TCP <a href="#Tou1998" id="rfc.xref.Tou1998.1"><cite title="Analysis of HTTP Performance">[Tou1998]</cite></a>. … … 1685 1685 <h4 id="rfc.section.7.1.2.1"><a href="#rfc.section.7.1.2.1">7.1.2.1</a> <a id="persistent.negotiation" href="#persistent.negotiation">Negotiation</a></h4> 1686 1686 <p id="rfc.section.7.1.2.1.p.1">An HTTP/1.1 server <em class="bcp14">MAY</em> assume that a HTTP/1.1 client intends to maintain a persistent connection unless a Connection header including the connection-token 1687 "close" was sent in the request. If the server chooses to close the connection immediately after sending the response, it <em class="bcp14">SHOULD</em> send a Connection header including the connection-token close.1687 "close" was sent in the request. If the server chooses to close the connection immediately after sending the response, it <em class="bcp14">SHOULD</em> send a Connection header including the connection-token "close". 1688 1688 </p> 1689 1689 <p id="rfc.section.7.1.2.1.p.2">An HTTP/1.1 client <em class="bcp14">MAY</em> expect a connection to remain open, but would decide to keep it open based on whether the response from a server contains … … 2129 2129 be sensitive information, it <em class="bcp14">MAY</em> be replaced by a pseudonym. If the port is not given, it <em class="bcp14">MAY</em> be assumed to be the default port of the received-protocol. 2130 2130 </p> 2131 <p id="rfc.section.9.9.p.5">Multiple Via field values represent seach proxy or gateway that has forwarded the message. Each recipient <em class="bcp14">MUST</em> append its information such that the end result is ordered according to the sequence of forwarding applications.2131 <p id="rfc.section.9.9.p.5">Multiple Via field values represent each proxy or gateway that has forwarded the message. Each recipient <em class="bcp14">MUST</em> append its information such that the end result is ordered according to the sequence of forwarding applications. 2132 2132 </p> 2133 2133 <p id="rfc.section.9.9.p.6">Comments <em class="bcp14">MAY</em> be used in the Via header field to identify the software of the recipient proxy or gateway, analogous to the User-Agent and … … 2471 2471 <p id="rfc.section.11.5.p.2">Proxy operators should protect the systems on which proxies run as they would protect any system that contains or transports 2472 2472 sensitive information. In particular, log information gathered at proxies often contains highly sensitive personal information, 2473 and/or information about organizations. Log information should be carefully guarded, and appropriate guidelines for use developed2474 and followed. (<a href="#abuse.of.server.log.information" title="Abuse of Server Log Information">Section 11.2</a>).2473 and/or information about organizations. Log information should be carefully guarded, and appropriate guidelines for use should 2474 be developed and followed. (<a href="#abuse.of.server.log.information" title="Abuse of Server Log Information">Section 11.2</a>). 2475 2475 </p> 2476 2476 <p id="rfc.section.11.5.p.3">Proxy implementors should consider the privacy and security implications of their design and coding decisions, and of the 2477 2477 configuration options they provide to proxy operators (especially the default configuration). 2478 2478 </p> 2479 <p id="rfc.section.11.5.p.4">Users of a proxy need to be aware that they are no trustworthier than the people who run the proxy; HTTP itself cannot solve2479 <p id="rfc.section.11.5.p.4">Users of a proxy need to be aware that proxies are no trustworthier than the people who run them; HTTP itself cannot solve 2480 2480 this problem. 2481 2481 </p> … … 2729 2729 can be interpreted unambiguously. 2730 2730 </p> 2731 <p id="rfc.section.A.p.2">Clients <em class="bcp14">SHOULD</em> be tolerant in parsing the Status-Line and servers tolerant when parsing the Request-Line. In particular, they <em class="bcp14">SHOULD</em> accept any amount of WSP characters between fields, even though only a single SP is required.2731 <p id="rfc.section.A.p.2">Clients <em class="bcp14">SHOULD</em> be tolerant in parsing the Status-Line and servers <em class="bcp14">SHOULD</em> be tolerant when parsing the Request-Line. In particular, they <em class="bcp14">SHOULD</em> accept any amount of WSP characters between fields, even though only a single SP is required. 2732 2732 </p> 2733 2733 <p id="rfc.section.A.p.3">The line terminator for header fields is the sequence CRLF. However, we recommend that applications, when parsing such headers, … … 2807 2807 clients and servers. Persistent connections in HTTP/1.0 are explicitly negotiated as they are not the default behavior. HTTP/1.0 2808 2808 experimental implementations of persistent connections are faulty, and the new facilities in HTTP/1.1 are designed to rectify 2809 these problems. The problem was that some existing 1.0 clients may be sending Keep-Alive to a proxy server that doesn't understand2810 Connection, which would then erroneously forward it to the next inbound server, which would establish the Keep-Alive connection2811 and result in a hung HTTP/1.0 proxy waiting for the close on the response. The result is that HTTP/1.0 clients must be prevented2812 from using Keep-Alive when talking to proxies.2809 these problems. The problem was that some existing HTTP/1.0 clients may be sending Keep-Alive to a proxy server that doesn't 2810 understand Connection, which would then erroneously forward it to the next inbound server, which would establish the Keep-Alive 2811 connection and result in a hung HTTP/1.0 proxy waiting for the close on the response. The result is that HTTP/1.0 clients 2812 must be prevented from using Keep-Alive when talking to proxies. 2813 2813 </p> 2814 2814 <p id="rfc.section.B.2.p.2">However, talking to proxies is the most important use of persistent connections, so that prohibition is clearly unacceptable. … … 2848 2848 <p id="rfc.section.B.4.p.3">Clarify that HTTP-Version is case sensitive. (<a href="#http.version" title="HTTP Version">Section 2.5</a>) 2849 2849 </p> 2850 <p id="rfc.section.B.4.p.4">Remove reference to non-exist ant identity transfer-coding value tokens. (Sections <a href="#transfer.codings" title="Transfer Codings">6.2</a> and <a href="#message.length" title="Message Length">3.4</a>)2850 <p id="rfc.section.B.4.p.4">Remove reference to non-existent identity transfer-coding value tokens. (Sections <a href="#transfer.codings" title="Transfer Codings">6.2</a> and <a href="#message.length" title="Message Length">3.4</a>) 2851 2851 </p> 2852 2852 <p id="rfc.section.B.4.p.5">Require that invalid whitespace around field-names be rejected. (<a href="#header.fields" title="Header Fields">Section 3.2</a>)
Note: See TracChangeset
for help on using the changeset viewer.