Changeset 978 for draft-ietf-httpbis/orig/rfc2817.html
- Timestamp:
- 04/08/10 15:03:20 (12 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/orig/rfc2817.html
r598 r978 37 37 } 38 38 39 dl.empty dd { 39 ul.empty { 40 list-style-type: none; 41 } 42 ul.empty li { 40 43 margin-top: .5em; 41 44 } … … 118 121 } 119 122 table.header { 123 border-spacing: 1px; 120 124 width: 95%; 121 125 font-size: 10pt; … … 129 133 white-space: nowrap; 130 134 } 131 t d.header{135 table.header td { 132 136 background-color: gray; 133 137 width: 50%; 134 138 } 135 t d.header a {139 table.header a { 136 140 color: white; 137 141 } … … 311 315 <link rel="Alternate" title="Authorative ASCII Version" href="http://www.ietf.org/rfc/rfc2817.txt"> 312 316 <link rel="Help" title="Additional Information on tools.ietf.org" href="http://tools.ietf.org/html/rfc2817"> 313 <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.438, 2009-05-27 13:34:05, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/"> 314 <link rel="schema.DC" href="http://purl.org/dc/elements/1.1/"> 315 <meta name="DC.Creator" content="Khare, R."> 316 <meta name="DC.Creator" content="Lawrence, S."> 317 <meta name="DC.Identifier" content="urn:ietf:rfc:2817"> 318 <meta name="DC.Date.Issued" scheme="ISO8601" content="2000-05"> 319 <meta name="DC.Description.Abstract" content="This memo explains how to use the Upgrade mechanism in HTTP/1.1 to initiate Transport Layer Security (TLS) over an existing TCP connection. This allows unsecured and secured HTTP traffic to share the same well known port (in this case, http: at 80 rather than https: at 443). It also enables "virtual hosting", so a single HTTP + TLS server can disambiguate traffic intended for several hostnames at a single IP address. Since HTTP/1.1 defines Upgrade as a hop-by-hop mechanism, this memo also documents the HTTP CONNECT method for establishing end-to-end tunnels across HTTP proxies. Finally, this memo establishes new IANA registries for public HTTP status codes, as well as public or private Upgrade product tokens. This memo does NOT affect the current definition of the 'https' URI scheme, which already defines a separate namespace (http://example.org/ and https://example.org/ are not equivalent)."> 320 <meta name="DC.isPartOf" content="urn:ISSN:2070-1721"> 317 <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.520, 2010-07-14 12:36:35, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/"> 318 <link rel="schema.dct" href="http://purl.org/dc/terms/"> 319 <meta name="dct.creator" content="Khare, R."> 320 <meta name="dct.creator" content="Lawrence, S."> 321 <meta name="dct.identifier" content="urn:ietf:rfc:2817"> 322 <meta name="dct.issued" scheme="ISO8601" content="2000-05"> 323 <meta name="dct.abstract" content="This memo explains how to use the Upgrade mechanism in HTTP/1.1 to initiate Transport Layer Security (TLS) over an existing TCP connection. This allows unsecured and secured HTTP traffic to share the same well known port (in this case, http: at 80 rather than https: at 443). It also enables "virtual hosting", so a single HTTP + TLS server can disambiguate traffic intended for several hostnames at a single IP address. Since HTTP/1.1 defines Upgrade as a hop-by-hop mechanism, this memo also documents the HTTP CONNECT method for establishing end-to-end tunnels across HTTP proxies. Finally, this memo establishes new IANA registries for public HTTP status codes, as well as public or private Upgrade product tokens. This memo does NOT affect the current definition of the 'https' URI scheme, which already defines a separate namespace (http://example.org/ and https://example.org/ are not equivalent)."> 324 <meta name="dct.isPartOf" content="urn:issn:2070-1721"> 325 <meta name="description" content="This memo explains how to use the Upgrade mechanism in HTTP/1.1 to initiate Transport Layer Security (TLS) over an existing TCP connection. This allows unsecured and secured HTTP traffic to share the same well known port (in this case, http: at 80 rather than https: at 443). It also enables "virtual hosting", so a single HTTP + TLS server can disambiguate traffic intended for several hostnames at a single IP address. Since HTTP/1.1 defines Upgrade as a hop-by-hop mechanism, this memo also documents the HTTP CONNECT method for establishing end-to-end tunnels across HTTP proxies. Finally, this memo establishes new IANA registries for public HTTP status codes, as well as public or private Upgrade product tokens. This memo does NOT affect the current definition of the 'https' URI scheme, which already defines a separate namespace (http://example.org/ and https://example.org/ are not equivalent)."> 321 326 </head> 322 327 <body> 323 <table summary="header information" class="header" border="0" cellpadding="1" cellspacing="1"> 324 <tr> 325 <td class="header left">Network Working Group</td> 326 <td class="header right">R. Khare</td> 327 </tr> 328 <tr> 329 <td class="header left">Request for Comments: 2817</td> 330 <td class="header right">4K Associates / UC Irvine</td> 331 </tr> 332 <tr> 333 <td class="header left">Updates: <a href="http://tools.ietf.org/html/rfc2616">2616</a></td> 334 <td class="header right">S. Lawrence</td> 335 </tr> 336 <tr> 337 <td class="header left">Category: Standards Track</td> 338 <td class="header right">Agranat Systems, Inc.</td> 339 </tr> 340 <tr> 341 <td class="header left"></td> 342 <td class="header right">May 2000</td> 343 </tr> 328 <table class="header"> 329 <tbody> 330 <tr> 331 <td class="left">Network Working Group</td> 332 <td class="right">R. Khare</td> 333 </tr> 334 <tr> 335 <td class="left">Request for Comments: 2817</td> 336 <td class="right">4K Associates / UC Irvine</td> 337 </tr> 338 <tr> 339 <td class="left">Updates: <a href="http://tools.ietf.org/html/rfc2616">2616</a></td> 340 <td class="right">S. Lawrence</td> 341 </tr> 342 <tr> 343 <td class="left">Category: Standards Track</td> 344 <td class="right">Agranat Systems, Inc.</td> 345 </tr> 346 <tr> 347 <td class="left"></td> 348 <td class="right">May 2000</td> 349 </tr> 350 </tbody> 344 351 </table> 345 352 <p class="title">Upgrading to TLS Within HTTP/1.1</p> … … 680 687 <h1 class="np" id="rfc.references"><a href="#rfc.section.9" id="rfc.section.9">9.</a> References 681 688 </h1> 682 <table summary="References">689 <table> 683 690 <tr> 684 691 <td class="reference"><b id="RFC2616">[1]</b></td> … … 688 695 <tr> 689 696 <td class="reference"><b id="RFC2396">[2]</b></td> 690 <td class="top"><a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</a>, <a href="mailto:fielding@ics.uci.edu" title="University of California, Irvine">Fielding, R. T.</a>, and <a href="mailto:masinter@parc.xerox.com" title="Xerox PARC">L. Masinter</a>, “<a href="http://tools.ietf.org/html/rfc2396">Uniform Resource Identifiers (URI): Generic Syntax</a>”, RFC 2396, August 1998.697 <td class="top"><a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</a>, <a href="mailto:fielding@ics.uci.edu" title="University of California, Irvine">Fielding, R.</a>, and <a href="mailto:masinter@parc.xerox.com" title="Xerox PARC">L. Masinter</a>, “<a href="http://tools.ietf.org/html/rfc2396">Uniform Resource Identifiers (URI): Generic Syntax</a>”, RFC 2396, August 1998. 691 698 </td> 692 699 </tr> … … 698 705 <tr> 699 706 <td class="reference"><b id="RFC2518">[4]</b></td> 700 <td class="top"><a href="mailto:yarong@microsoft.com" title="Microsoft Corporation">Goland, Y.</a>, <a href="mailto:ejw@ics.uci.edu" title="Dept. Of Information and Computer Science, University of California, Irvine">Whitehead, E.</a>, <a href="mailto:asad@netscape.com" title="Netscape">Faizi, A.</a>, <a href="mailto:srcarter@novell.com" title="Novell">Carter, S. R.</a>, and <a href="mailto:dcjensen@novell.com" title="Novell">D. Jensen</a>, “<a href="http://tools.ietf.org/html/rfc2518">HTTP Extensions for Distributed Authoring -- WEBDAV</a>”, RFC 2518, February 1999.707 <td class="top"><a href="mailto:yarong@microsoft.com" title="Microsoft Corporation">Goland, Y.</a>, <a href="mailto:ejw@ics.uci.edu" title="Dept. Of Information and Computer Science, University of California, Irvine">Whitehead, E.</a>, <a href="mailto:asad@netscape.com" title="Netscape">Faizi, A.</a>, <a href="mailto:srcarter@novell.com" title="Novell">Carter, S.</a>, and <a href="mailto:dcjensen@novell.com" title="Novell">D. Jensen</a>, “<a href="http://tools.ietf.org/html/rfc2518">HTTP Extensions for Distributed Authoring -- WEBDAV</a>”, RFC 2518, February 1999. 701 708 </td> 702 709 </tr> 703 710 <tr> 704 711 <td class="reference"><b id="ADVCOL">[5]</b></td> 705 <td class="top">Slein, J. and E. J.Whitehead, “WebDAV Advanced Collection Protocol”.<br>Work In Progress.712 <td class="top">Slein, J. and E. Whitehead, “WebDAV Advanced Collection Protocol”.<br>Work In Progress. 706 713 </td> 707 714 </tr> … … 723 730 <tr> 724 731 <td class="reference"><b id="RFC2629">[9]</b></td> 725 <td class="top"><a href="mailto:mrose@not.invisible.net" title="Invisible Worlds, Inc.">Rose, M. T.</a>, “<a href="http://tools.ietf.org/html/rfc2629">Writing I-Ds and RFCs using XML</a>”, RFC 2629, June 1999.732 <td class="top"><a href="mailto:mrose@not.invisible.net" title="Invisible Worlds, Inc.">Rose, M.</a>, “<a href="http://tools.ietf.org/html/rfc2629">Writing I-Ds and RFCs using XML</a>”, RFC 2629, June 1999. 726 733 </td> 727 734 </tr> 728 735 <tr> 729 736 <td class="reference"><b id="RFC2434">[10]</b></td> 730 <td class="top"><a href="mailto:narten@raleigh.ibm.com" title="IBM Corporation">Narten, T.</a> and <a href="mailto:Harald@Alvestrand.no" title="Maxware">H. T.Alvestrand</a>, “<a href="http://tools.ietf.org/html/rfc2434">Guidelines for Writing an IANA Considerations Section in RFCs</a>”, BCP 26, RFC 2434, October 1998.737 <td class="top"><a href="mailto:narten@raleigh.ibm.com" title="IBM Corporation">Narten, T.</a> and <a href="mailto:Harald@Alvestrand.no" title="Maxware">H. Alvestrand</a>, “<a href="http://tools.ietf.org/html/rfc2434">Guidelines for Writing an IANA Considerations Section in RFCs</a>”, BCP 26, RFC 2434, October 1998. 731 738 </td> 732 739 </tr> … … 738 745 </table> 739 746 <hr class="noprint"> 740 <h1 id="rfc.authors" class="np"><a href="#rfc.authors">Authors' Addresses</a></h1> 741 <address class="vcard"><span class="vcardline"><span class="fn">Rohit Khare</span><span class="n hidden"><span class="family-name">Khare</span><span class="given-name">Rohit</span></span></span><span class="org vcardline">4K Associates / UC Irvine</span><span class="vcardline">EMail: <a href="mailto:rohit@4K-associates.com"><span class="email">rohit@4K-associates.com</span></a></span></address> 742 <address class="vcard"><span class="vcardline"><span class="fn">Scott Lawrence</span><span class="n hidden"><span class="family-name">Lawrence</span><span class="given-name">Scott</span></span></span><span class="org vcardline">Agranat Systems, Inc.</span><span class="vcardline">EMail: <a href="mailto:lawrence@agranat.com"><span class="email">lawrence@agranat.com</span></a></span></address> 747 <div class="avoidbreak"> 748 <h1 id="rfc.authors" class="np"><a href="#rfc.authors">Authors' Addresses</a></h1> 749 <address class="vcard"><span class="vcardline"><span class="fn">Rohit Khare</span><span class="n hidden"><span class="family-name">Khare</span><span class="given-name">Rohit</span></span></span><span class="org vcardline">4K Associates / UC Irvine</span><span class="vcardline">EMail: <a href="mailto:rohit@4K-associates.com"><span class="email">rohit@4K-associates.com</span></a></span></address> 750 <address class="vcard"><span class="vcardline"><span class="fn">Scott Lawrence</span><span class="n hidden"><span class="family-name">Lawrence</span><span class="given-name">Scott</span></span></span><span class="org vcardline">Agranat Systems, Inc.</span><span class="vcardline">EMail: <a href="mailto:lawrence@agranat.com"><span class="email">lawrence@agranat.com</span></a></span></address> 751 </div> 743 752 <hr class="noprint"> 744 753 <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a> Acknowledgments … … 772 781 translate it into languages other than English. 773 782 </p> 774 <p>The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assign ees.</p>783 <p>The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.</p> 775 784 <p>This document and the information contained herein is provided on an “AS IS” basis and THE INTERNET SOCIETY AND THE INTERNET 776 785 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE
Note: See TracChangeset
for help on using the changeset viewer.