![(please configure the [header_logo] section in trac.ini)](https://www.ietf.org/images/ietflogotrans.gif)
Changeset 761
- Timestamp:
- Feb 17, 2010, 5:53:37 AM (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
-
p1-messaging.html (modified) (12 diffs)
-
p1-messaging.xml (modified) (9 diffs)
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>) -
draft-ietf-httpbis/latest/p1-messaging.xml
r756 r761 1313 1313 &MUST-NOT; be used unless the sender knows that the recipient can parse 1314 1314 it; the presence in a request of a Range header with multiple byte-range 1315 specifiers from a 1.1 client implies that the client can parse1315 specifiers from a HTTP/1.1 client implies that the client can parse 1316 1316 multipart/byteranges responses. 1317 1317 <list style="empty"><t> 1318 A range header might be forwarded by a 1.0 proxy that does not1318 A range header might be forwarded by a HTTP/1.0 proxy that does not 1319 1319 understand multipart/byteranges; in this case the server &MUST; 1320 1320 delimit the message using methods defined in items 1, 3 or 5 of … … 2116 2116 established to fetch each URL, increasing the load on HTTP servers 2117 2117 and causing congestion on the Internet. The use of inline images and 2118 other associated data often require a client to make multiple2118 other associated data often requires a client to make multiple 2119 2119 requests of the same server in a short amount of time. Analysis of 2120 2120 these performance problems and results from a prototype … … 2185 2185 chooses to close the connection immediately after sending the 2186 2186 response, it &SHOULD; send a Connection header including the 2187 connection-token close.2187 connection-token "close". 2188 2188 </t> 2189 2189 <t> … … 3101 3101 </t> 3102 3102 <t> 3103 Multiple Via field values represent seach proxy or gateway that has3103 Multiple Via field values represent each proxy or gateway that has 3104 3104 forwarded the message. Each recipient &MUST; append its information 3105 3105 such that the end result is ordered according to the sequence of … … 3571 3571 contains highly sensitive personal information, and/or information 3572 3572 about organizations. Log information should be carefully guarded, and 3573 appropriate guidelines for use developed and followed. (<xref target="abuse.of.server.log.information"/>). 3573 appropriate guidelines for use should be developed and followed. 3574 (<xref target="abuse.of.server.log.information"/>). 3574 3575 </t> 3575 3576 <t> … … 3580 3581 </t> 3581 3582 <t> 3582 Users of a proxy need to be aware that theyare no trustworthier than3583 the people who run the proxy; HTTP itself cannot solve this problem.3583 Users of a proxy need to be aware that proxies are no trustworthier than 3584 the people who run them; HTTP itself cannot solve this problem. 3584 3585 </t> 3585 3586 <t> … … 4435 4436 <t> 4436 4437 Clients &SHOULD; be tolerant in parsing the Status-Line and servers 4437 tolerant when parsing the Request-Line. In particular, they &SHOULD;4438 accept any amount of WSP characters between fields, even though4438 &SHOULD; be tolerant when parsing the Request-Line. In particular, they 4439 &SHOULD; accept any amount of WSP characters between fields, even though 4439 4440 only a single SP is required. 4440 4441 </t> … … 4579 4580 experimental implementations of persistent connections are faulty, 4580 4581 and the new facilities in HTTP/1.1 are designed to rectify these 4581 problems. The problem was that some existing 1.0 clients may be4582 problems. The problem was that some existing HTTP/1.0 clients may be 4582 4583 sending Keep-Alive to a proxy server that doesn't understand 4583 4584 Connection, which would then erroneously forward it to the next … … 4661 4662 </t> 4662 4663 <t> 4663 Remove reference to non-exist ant identity transfer-coding value tokens.4664 Remove reference to non-existent identity transfer-coding value tokens. 4664 4665 (Sections <xref format="counter" target="transfer.codings"/> and 4665 4666 <xref format="counter" target="message.length"/>)
Note: See TracChangeset
for help on using the changeset viewer.
