Changeset 1570
- Timestamp:
- 09/03/12 08:46:33 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 4 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r1567 r1570 460 460 } 461 461 @bottom-center { 462 content: "Expires September 9, 2012";462 content: "Expires September 10, 2012"; 463 463 } 464 464 @bottom-right { … … 510 510 <meta name="dct.creator" content="Reschke, J. F."> 511 511 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest"> 512 <meta name="dct.issued" scheme="ISO8601" content="2012-03-0 8">512 <meta name="dct.issued" scheme="ISO8601" content="2012-03-09"> 513 513 <meta name="dct.replaces" content="urn:ietf:rfc:2145"> 514 514 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> … … 542 542 </tr> 543 543 <tr> 544 <td class="left">Expires: September 9, 2012</td>544 <td class="left">Expires: September 10, 2012</td> 545 545 <td class="right">HP</td> 546 546 </tr> … … 595 595 <tr> 596 596 <td class="left"></td> 597 <td class="right">March 8, 2012</td>597 <td class="right">March 9, 2012</td> 598 598 </tr> 599 599 </tbody> … … 628 628 in progress”. 629 629 </p> 630 <p>This Internet-Draft will expire on September 9, 2012.</p>630 <p>This Internet-Draft will expire on September 10, 2012.</p> 631 631 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 632 632 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 1463 1463 status code (<a href="#status.code" title="Status Code">Section 3.1.2.1</a>). Responses to the HEAD request method never include a message body because the associated response header fields (e.g., 1464 1464 Transfer-Encoding, Content-Length, etc.) only indicate what their values would have been if the request method had been GET. 1465 All 1xx (Informational), 204 (No Content), and 304 (Not Modified) responses <em class="bcp14">MUST NOT</em> include a message body. All other responses do include a message body, although the body <em class="bcp14">MAY</em> be of zero length. 1465 Successful (2xx) responses to CONNECT switch to tunnel mode instead of having a message body. All 1xx (Informational), 204 1466 (No Content), and 304 (Not Modified) responses <em class="bcp14">MUST NOT</em> include a message body. All other responses do include a message body, although the body <em class="bcp14">MAY</em> be of zero length. 1466 1467 </p> 1467 1468 <div id="rfc.iref.t.4"></div> … … 1513 1514 </pre><p id="rfc.section.3.3.2.p.3">An example is</p> 1514 1515 <div id="rfc.figure.u.37"></div><pre class="text"> Content-Length: 3495 1515 </pre><p id="rfc.section.3.3.2.p.5">In the case of a response to a HEAD request, Content-Length indicates the size of the payload body ( not includingany potential1516 </pre><p id="rfc.section.3.3.2.p.5">In the case of a response to a HEAD request, Content-Length indicates the size of the payload body (without any potential 1516 1517 transfer-coding) that would have been sent had the request been a GET. In the case of a 304 (Not Modified) response to a GET 1517 request, Content-Length indicates the size of the payload body (not including any potential transfer-coding) that would have 1518 been sent in a 200 (OK) response. 1519 </p> 1520 <p id="rfc.section.3.3.2.p.6">Any Content-Length field value greater than or equal to zero is valid. Since there is no predefined limit to the length of 1518 request, Content-Length indicates the size of the payload body (without any potential transfer-coding) that would have been 1519 sent in a 200 (OK) response. 1520 </p> 1521 <p id="rfc.section.3.3.2.p.6">HTTP's use of Content-Length is significantly different from how it is used in MIME, where it is an optional field used only 1522 within the "message/external-body" media-type. 1523 </p> 1524 <p id="rfc.section.3.3.2.p.7">Any Content-Length field value greater than or equal to zero is valid. Since there is no predefined limit to the length of 1521 1525 an HTTP payload, recipients <em class="bcp14">SHOULD</em> anticipate potentially large decimal numerals and prevent parsing errors due to integer conversion overflows (<a href="#attack.protocol.element.size.overflows" title="Protocol Element Size Overflows">Section 10.6</a>). 1522 1526 </p> 1523 <p id="rfc.section.3.3.2.p. 7">If a message is received that has multiple Content-Length header fields (<a href="#header.content-length" id="rfc.xref.header.content-length.1" title="Content-Length">Section 3.3.2</a>) with field-values consisting of the same decimal value, or a single Content-Length header field with a field value containing1527 <p id="rfc.section.3.3.2.p.8">If a message is received that has multiple Content-Length header fields (<a href="#header.content-length" id="rfc.xref.header.content-length.1" title="Content-Length">Section 3.3.2</a>) with field-values consisting of the same decimal value, or a single Content-Length header field with a field value containing 1524 1528 a list of identical decimal values (e.g., "Content-Length: 42, 42"), indicating that duplicate Content-Length header fields 1525 1529 have been generated or combined by an upstream message processor, then the recipient <em class="bcp14">MUST</em> either reject the message as invalid or replace the duplicated field-values with a single valid Content-Length field containing 1526 1530 that decimal value prior to determining the message body length. 1527 </p>1528 <p id="rfc.section.3.3.2.p.8">HTTP's use of Content-Length is significantly different from how it is used in MIME, where it is an optional field used only1529 within the "message/external-body" media-type.1530 1531 </p> 1531 1532 <h3 id="rfc.section.3.3.3"><a href="#rfc.section.3.3.3">3.3.3</a> <a id="message.body.length" href="#message.body.length">Message Body Length</a></h3> … … 1537 1538 empty line after the header fields, regardless of the header fields present in the message, and thus cannot contain a message 1538 1539 body. 1540 </p> 1541 </li> 1542 <li> 1543 <p>Any successful (2xx) response to a CONNECT request implies that the connection will become a tunnel immediately after the 1544 empty line that concludes the header fields. A client <em class="bcp14">MUST</em> ignore any Content-Length or Transfer-Encoding header fields received in such a message. 1539 1545 </p> 1540 1546 </li> -
draft-ietf-httpbis/latest/p1-messaging.xml
r1567 r1570 1576 1576 Content-Length, etc.) only indicate what their values would have been 1577 1577 if the request method had been GET. 1578 Successful (2xx) responses to CONNECT switch to tunnel mode instead of 1579 having a message body. 1578 1580 All 1xx (Informational), 204 (No Content), and 304 (Not Modified) 1579 1581 responses &MUST-NOT; include a message body. … … 1693 1695 <t> 1694 1696 In the case of a response to a HEAD request, Content-Length indicates 1695 the size of the payload body ( not includingany potential transfer-coding)1697 the size of the payload body (without any potential transfer-coding) 1696 1698 that would have been sent had the request been a GET. 1697 1699 In the case of a 304 (Not Modified) response to a GET request, 1698 Content-Length indicates the size of the payload body ( not including1700 Content-Length indicates the size of the payload body (without 1699 1701 any potential transfer-coding) that would have been sent in a 200 (OK) 1700 1702 response. 1703 </t> 1704 <t> 1705 HTTP's use of Content-Length is significantly different from how it is 1706 used in MIME, where it is an optional field used only within the 1707 "message/external-body" media-type. 1701 1708 </t> 1702 1709 <t> … … 1719 1726 length. 1720 1727 </t> 1721 <t>1722 HTTP's use of Content-Length is significantly different from how it is1723 used in MIME, where it is an optional field used only within the1724 "message/external-body" media-type.1725 </t>1726 1728 </section> 1727 1729 … … 1738 1740 empty line after the header fields, regardless of the header 1739 1741 fields present in the message, and thus cannot contain a message body. 1742 </t></x:lt> 1743 <x:lt><t> 1744 Any successful (2xx) response to a CONNECT request implies that the 1745 connection will become a tunnel immediately after the empty line that 1746 concludes the header fields. A client &MUST; ignore any Content-Length 1747 or Transfer-Encoding header fields received in such a message. 1740 1748 </t></x:lt> 1741 1749 <x:lt><t> -
draft-ietf-httpbis/latest/p2-semantics.html
r1567 r1570 460 460 } 461 461 @bottom-center { 462 content: "Expires September 9, 2012";462 content: "Expires September 10, 2012"; 463 463 } 464 464 @bottom-right { … … 513 513 <meta name="dct.creator" content="Reschke, J. F."> 514 514 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest"> 515 <meta name="dct.issued" scheme="ISO8601" content="2012-03-0 8">515 <meta name="dct.issued" scheme="ISO8601" content="2012-03-09"> 516 516 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 517 517 <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 2 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 2 defines the semantics of HTTP messages as expressed by request methods, request header fields, response status codes, and response header fields."> … … 544 544 </tr> 545 545 <tr> 546 <td class="left">Expires: September 9, 2012</td>546 <td class="left">Expires: September 10, 2012</td> 547 547 <td class="right">HP</td> 548 548 </tr> … … 597 597 <tr> 598 598 <td class="left"></td> 599 <td class="right">March 8, 2012</td>599 <td class="right">March 9, 2012</td> 600 600 </tr> 601 601 </tbody> … … 627 627 in progress”. 628 628 </p> 629 <p>This Internet-Draft will expire on September 9, 2012.</p>629 <p>This Internet-Draft will expire on September 10, 2012.</p> 630 630 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 631 631 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 693 693 <li>6.7 <a href="#DELETE">DELETE</a></li> 694 694 <li>6.8 <a href="#TRACE">TRACE</a></li> 695 <li>6.9 <a href="#CONNECT">CONNECT</a><ul> 696 <li>6.9.1 <a href="#rfc.section.6.9.1">Establishing a Tunnel with CONNECT</a></li> 697 </ul> 698 </li> 695 <li>6.9 <a href="#CONNECT">CONNECT</a></li> 699 696 </ul> 700 697 </li> … … 1674 1671 <div id="rfc.iref.m.8"></div> 1675 1672 <h2 id="rfc.section.6.9"><a href="#rfc.section.6.9">6.9</a> <a id="CONNECT" href="#CONNECT">CONNECT</a></h2> 1676 <p id="rfc.section.6.9.p.1">The CONNECT method requests that the proxy establish a tunnel to the request-target and then restrict its behavior to blind1677 forwarding of packets until the connection is closed.1673 <p id="rfc.section.6.9.p.1">The CONNECT method requests that the proxy establish a tunnel to the request-target and, if successful, thereafter restrict 1674 its behavior to blind forwarding of packets until the connection is closed. 1678 1675 </p> 1679 1676 <p id="rfc.section.6.9.p.2">When using CONNECT, the request-target <em class="bcp14">MUST</em> use the authority form (<a href="p1-messaging.html#request-target" title="request-target">Section 3.1.1.2</a> of <a href="#Part1" id="rfc.xref.Part1.30"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>); i.e., the request-target consists of only the host name and port number of the tunnel destination, separated by a colon. … … 1683 1680 Host: server.example.com:80 1684 1681 1685 </pre><p id="rfc.section.6.9.p.4">Other HTTP mechanisms can be used normally with the CONNECT method — except end-to-end protocol Upgrade requests, since the 1686 tunnel must be established first. 1687 </p> 1688 <p id="rfc.section.6.9.p.5">For example, proxy authentication might be used to establish the authority to create a tunnel:</p> 1682 </pre><p id="rfc.section.6.9.p.4">Any successful (2xx) response to a CONNECT request indicates that the proxy has established a connection to the requested 1683 host and port, and has switched to tunneling the current connection to that server connection. The tunneled data from the 1684 server begins immediately after the blank line that concludes the successful response's header block. A server <em class="bcp14">SHOULD NOT</em> send any Transfer-Encoding or Content-Length header fields in a successful response. A client <em class="bcp14">MUST</em> ignore any Content-Length or Transfer-Encoding header fields received in a successful response. 1685 </p> 1686 <p id="rfc.section.6.9.p.5">Any response other than a successful response indicates that the tunnel has not yet been formed and that the connection remains 1687 governed by HTTP. 1688 </p> 1689 <p id="rfc.section.6.9.p.6">Proxy authentication might be used to establish the authority to create a tunnel:</p> 1689 1690 <div id="rfc.figure.u.7"></div><pre class="text2">CONNECT server.example.com:80 HTTP/1.1 1690 1691 Host: server.example.com:80 1691 1692 Proxy-Authorization: basic aGVsbG86d29ybGQ= 1692 1693 1693 </pre><p id="rfc.section.6.9.p.7">Bodies on CONNECT requests have no defined semantics. Note that sending a body on a CONNECT request might cause some existing 1694 implementations to reject the request. 1695 </p> 1696 <p id="rfc.section.6.9.p.8">Like any other pipelined HTTP/1.1 request, data to be tunnel may be sent immediately after the blank line. The usual caveats 1697 also apply: data may be discarded if the eventual response is negative, and the connection may be reset with no response if 1698 more than one TCP segment is outstanding. 1699 </p> 1700 <h3 id="rfc.section.6.9.1"><a href="#rfc.section.6.9.1">6.9.1</a> Establishing a Tunnel with CONNECT 1701 </h3> 1702 <p id="rfc.section.6.9.1.p.1">Any successful (2xx) response to a CONNECT request indicates that the proxy has established a connection to the requested 1703 host and port, and has switched to tunneling the current connection to that server connection. 1704 </p> 1705 <p id="rfc.section.6.9.1.p.2">It may be the case that the proxy itself can only reach the requested origin server through another proxy. In this case, the 1694 </pre><p id="rfc.section.6.9.p.8">A message body on a CONNECT request has no defined semantics. Sending a body on a CONNECT request might cause existing implementations 1695 to reject the request. 1696 </p> 1697 <p id="rfc.section.6.9.p.9">Similar to a pipelined HTTP/1.1 request, data to be tunneled from client to server <em class="bcp14">MAY</em> be sent immediately after the request (before a response is received). The usual caveats also apply: data may be discarded 1698 if the eventual response is negative, and the connection may be reset with no response if more than one TCP segment is outstanding. 1699 </p> 1700 <p id="rfc.section.6.9.p.10">It may be the case that the proxy itself can only reach the requested origin server through another proxy. In this case, the 1706 1701 first proxy <em class="bcp14">SHOULD</em> make a CONNECT request of that next proxy, requesting a tunnel to the authority. A proxy <em class="bcp14">MUST NOT</em> respond with any 2xx status code unless it has either a direct or tunnel connection established to the authority. 1707 1702 </p> 1708 <p id="rfc.section.6.9.1.p.3">An origin server which receives a CONNECT request for itself <em class="bcp14">MAY</em> respond with a 2xx status code to indicate that a connection is established. 1709 </p> 1710 <p id="rfc.section.6.9.1.p.4">If at any point either one of the peers gets disconnected, any outstanding data that came from that peer will be passed to 1703 <p id="rfc.section.6.9.p.11">If at any point either one of the peers gets disconnected, any outstanding data that came from that peer will be passed to 1711 1704 the other one, and after that also the other connection will be terminated by the proxy. If there is outstanding data to that 1712 1705 peer undelivered, that data will be discarded. 1706 </p> 1707 <p id="rfc.section.6.9.p.12">An origin server which receives a CONNECT request for itself <em class="bcp14">MAY</em> respond with a 2xx status code to indicate that a connection is established. However, most origin servers do not implement 1708 CONNECT. 1713 1709 </p> 1714 1710 <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <a id="status.codes" href="#status.codes">Status Code Definitions</a></h1> -
draft-ietf-httpbis/latest/p2-semantics.xml
r1567 r1570 1295 1295 <t> 1296 1296 The CONNECT method requests that the proxy establish a tunnel 1297 to the request-target and then restrict its behavior to blind1298 forwarding of packets until the connection is closed.1297 to the request-target and, if successful, thereafter restrict its behavior 1298 to blind forwarding of packets until the connection is closed. 1299 1299 </t> 1300 1300 <t> … … 1310 1310 </artwork></figure> 1311 1311 <t> 1312 Other HTTP mechanisms can be used normally with the CONNECT method — 1313 except end-to-end protocol Upgrade requests, since the 1314 tunnel must be established first. 1315 </t> 1316 <t> 1317 For example, proxy authentication might be used to establish the 1312 Any successful (2xx) response to a CONNECT request indicates that the 1313 proxy has established a connection to the requested host and port, 1314 and has switched to tunneling the current connection to that server 1315 connection. 1316 The tunneled data from the server begins immediately after the blank line 1317 that concludes the successful response's header block. 1318 A server &SHOULD-NOT; send any Transfer-Encoding or Content-Length 1319 header fields in a successful response. 1320 A client &MUST; ignore any Content-Length or Transfer-Encoding header 1321 fields received in a successful response. 1322 </t> 1323 <t> 1324 Any response other than a successful response indicates that the tunnel 1325 has not yet been formed and that the connection remains governed by HTTP. 1326 </t> 1327 <t> 1328 Proxy authentication might be used to establish the 1318 1329 authority to create a tunnel: 1319 1330 </t> … … 1325 1336 </artwork></figure> 1326 1337 <t> 1327 Bodies on CONNECT requests have no defined semantics. Note that sending a body 1328 on a CONNECT request might cause some existing implementations to reject the 1329 request. 1330 </t> 1331 <t> 1332 Like any other pipelined HTTP/1.1 request, data to be tunnel may be 1333 sent immediately after the blank line. The usual caveats also apply: 1338 A message body on a CONNECT request has no defined semantics. Sending a 1339 body on a CONNECT request might cause existing implementations to reject 1340 the request. 1341 </t> 1342 <t> 1343 Similar to a pipelined HTTP/1.1 request, data to be tunneled from client 1344 to server &MAY; be sent immediately after the request (before a response 1345 is received). The usual caveats also apply: 1334 1346 data may be discarded if the eventual response is negative, and the 1335 1347 connection may be reset with no response if more than one TCP segment 1336 1348 is outstanding. 1337 </t>1338 1339 <section title="Establishing a Tunnel with CONNECT">1340 <t>1341 Any successful (2xx) response to a CONNECT request indicates that the1342 proxy has established a connection to the requested host and port,1343 and has switched to tunneling the current connection to that server1344 connection.1345 1349 </t> 1346 1350 <t> … … 1353 1357 </t> 1354 1358 <t> 1355 An origin server which receives a CONNECT request for itself &MAY;1356 respond with a 2xx status code to indicate that a connection is1357 established.1358 </t>1359 <t>1360 1359 If at any point either one of the peers gets disconnected, any 1361 1360 outstanding data that came from that peer will be passed to the other … … 1364 1363 that data will be discarded. 1365 1364 </t> 1366 1367 </section> 1365 <t> 1366 An origin server which receives a CONNECT request for itself &MAY; 1367 respond with a 2xx status code to indicate that a connection is 1368 established. However, most origin servers do not implement CONNECT. 1369 </t> 1368 1370 </section> 1369 1371 </section>
Note: See TracChangeset
for help on using the changeset viewer.