Changeset 1514 for draft-ietf-httpbis/latest/p1-messaging.html
- Timestamp:
- 26/01/12 14:54:04 (10 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r1511 r1514 358 358 } 359 359 @bottom-center { 360 content: "Expires July 2 8, 2012";360 content: "Expires July 29, 2012"; 361 361 } 362 362 @bottom-right { … … 408 408 <meta name="dct.creator" content="Reschke, J. F."> 409 409 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest"> 410 <meta name="dct.issued" scheme="ISO8601" content="2012-01-2 5">410 <meta name="dct.issued" scheme="ISO8601" content="2012-01-26"> 411 411 <meta name="dct.replaces" content="urn:ietf:rfc:2145"> 412 412 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> … … 440 440 </tr> 441 441 <tr> 442 <td class="left">Expires: July 2 8, 2012</td>442 <td class="left">Expires: July 29, 2012</td> 443 443 <td class="right">HP</td> 444 444 </tr> … … 493 493 <tr> 494 494 <td class="left"></td> 495 <td class="right">January 2 5, 2012</td>495 <td class="right">January 26, 2012</td> 496 496 </tr> 497 497 </tbody> … … 526 526 in progress”. 527 527 </p> 528 <p>This Internet-Draft will expire on July 2 8, 2012.</p>528 <p>This Internet-Draft will expire on July 29, 2012.</p> 529 529 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 530 530 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 1053 1053 by a proxy <em class="bcp14">MUST</em> be forwarded downstream unless the header field's field-name is listed in the message's Connection header-field (see <a href="#header.connection" id="rfc.xref.header.connection.2" title="Connection">Section 8.1</a>). These requirements allow HTTP's functionality to be enhanced without requiring prior update of all compliant intermediaries. 1054 1054 </p> 1055 <p id="rfc.section.2.6.p.8">Intermediaries that process HTTP messages (i.e., all intermediaries other than those acting as a tunnel) <em class="bcp14">MUST</em> send their own HTTP-Version in forwarded messages. In other words, they <em class="bcp14">MUST NOT</em> blindly forward the first line of an HTTP message without ensuring that the protocol version matches what the intermediary1055 <p id="rfc.section.2.6.p.8">Intermediaries that process HTTP messages (i.e., all intermediaries other than those acting as tunnels) <em class="bcp14">MUST</em> send their own HTTP-Version in forwarded messages. In other words, they <em class="bcp14">MUST NOT</em> blindly forward the first line of an HTTP message without ensuring that the protocol version matches what the intermediary 1056 1056 understands, and is at least conditionally compliant to, for both the receiving and sending of messages. Forwarding an HTTP 1057 1057 message without rewriting the HTTP-Version might result in communication errors when downstream recipients use the message … … 1964 1964 request includes a request body, and the server responds with a final status code before reading the entire request body from 1965 1965 the transport connection, then the server <em class="bcp14">SHOULD NOT</em> close the transport connection until it has read the entire request, or until the client closes the connection. Otherwise, 1966 the client might not reliably receive the response message. However, this requirement is not be construed as preventing a1967 server from defending itself against denial-of-service attacks, or from badly broken client implementations.1966 the client might not reliably receive the response message. However, this requirement ought not be construed as preventing 1967 a server from defending itself against denial-of-service attacks, or from badly broken client implementations. 1968 1968 </li> 1969 1969 </ul> … … 2138 2138 <div id="rfc.iref.h.10"></div> 2139 2139 <h2 id="rfc.section.8.4"><a href="#rfc.section.8.4">8.4</a> <a id="header.te" href="#header.te">TE</a></h2> 2140 <p id="rfc.section.8.4.p.1">The "TE" header field indicates what extension transfer-codings it is willing to accept in the response, and whether or not2141 it is willing to accept trailer fields in a chunked transfer-coding.2140 <p id="rfc.section.8.4.p.1">The "TE" header field indicates what extension transfer-codings the client is willing to accept in the response, and whether 2141 or not it is willing to accept trailer fields in a chunked transfer-coding. 2142 2142 </p> 2143 2143 <p id="rfc.section.8.4.p.2">Its value consists of the keyword "trailers" and/or a comma-separated list of extension transfer-coding names with optional … … 2180 2180 </li> 2181 2181 </ol> 2182 <p id="rfc.section.8.4.p.9">If the TE field-value is empty or if no TE field is present, the only transfer-coding is "chunked". A message with no transfer-coding2183 is always acceptable.2182 <p id="rfc.section.8.4.p.9">If the TE field-value is empty or if no TE field is present, the only acceptable transfer-coding is "chunked". A message with 2183 no transfer-coding is always acceptable. 2184 2184 </p> 2185 2185 <div id="rfc.iref.t.6"></div> … … 2225 2225 </pre><p id="rfc.section.8.7.p.3">For example,</p> 2226 2226 <div id="rfc.figure.u.60"></div><pre class="text"> Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 2227 </pre><p id="rfc.section.8.7.p.5">The Upgrade header field is intended to provide a simple mechanism for transition from HTTP/1.1 to some other, incompatible2227 </pre><p id="rfc.section.8.7.p.5">The Upgrade header field is intended to provide a simple mechanism for transitioning from HTTP/1.1 to some other, incompatible 2228 2228 protocol. It does so by allowing the client to advertise its desire to use another protocol, such as a later version of HTTP 2229 2229 with a higher major version number, even though the current request has been made using HTTP/1.1. This eases the difficult … … 2648 2648 configuration options they provide to proxy operators (especially the default configuration). 2649 2649 </p> 2650 <p id="rfc.section.10.5.p.4">Users of a proxy need to be aware that proxies are no trustworthierthan the people who run them; HTTP itself cannot solve2650 <p id="rfc.section.10.5.p.4">Users of a proxy need to be aware that proxies are no more trustworthy than the people who run them; HTTP itself cannot solve 2651 2651 this problem. 2652 2652 </p> … … 2918 2918 designed, however, to make supporting previous versions easy. We would expect a general-purpose HTTP/1.1 server to understand 2919 2919 any valid request in the format of HTTP/1.0 and respond appropriately with an HTTP/1.1 message that only uses features understood 2920 (or safely ignored) by HTTP/1.0 clients. Likewise, w ould expect an HTTP/1.1 client to understand any valid HTTP/1.0 response.2920 (or safely ignored) by HTTP/1.0 clients. Likewise, we would expect an HTTP/1.1 client to understand any valid HTTP/1.0 response. 2921 2921 </p> 2922 2922 <p id="rfc.section.A.p.4">Since HTTP/0.9 did not support header fields in a request, there is no mechanism for it to support name-based virtual hosts
Note: See TracChangeset
for help on using the changeset viewer.