Changeset 1903
- Timestamp:
- 18/09/12 07:53:38 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r1901 r1903 449 449 } 450 450 @bottom-center { 451 content: "Expires March 2 1, 2013";451 content: "Expires March 22, 2013"; 452 452 } 453 453 @bottom-right { … … 492 492 <meta name="dct.creator" content="Reschke, J. F."> 493 493 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest"> 494 <meta name="dct.issued" scheme="ISO8601" content="2012-09-1 7">494 <meta name="dct.issued" scheme="ISO8601" content="2012-09-18"> 495 495 <meta name="dct.replaces" content="urn:ietf:rfc:2145"> 496 496 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> … … 524 524 </tr> 525 525 <tr> 526 <td class="left">Expires: March 2 1, 2013</td>526 <td class="left">Expires: March 22, 2013</td> 527 527 <td class="right">greenbytes</td> 528 528 </tr> 529 529 <tr> 530 530 <td class="left"></td> 531 <td class="right">September 1 7, 2012</td>531 <td class="right">September 18, 2012</td> 532 532 </tr> 533 533 </tbody> … … 556 556 in progress”. 557 557 </p> 558 <p>This Internet-Draft will expire on March 2 1, 2013.</p>558 <p>This Internet-Draft will expire on March 22, 2013.</p> 559 559 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 560 560 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 1081 1081 <p id="rfc.section.2.7.1.p.7">Although HTTP is independent of the transport protocol, the "http" scheme is specific to TCP-based services because the name 1082 1082 delegation process depends on TCP for establishing authority. An HTTP service based on some other underlying connection protocol 1083 would presumably be identified using a different URI scheme, just as the "https" scheme (below) is used for servers that require1084 an SSL/TLS transport layer on aconnection. Other protocols might also be used to provide access to "http" identified resources1083 would presumably be identified using a different URI scheme, just as the "https" scheme (below) is used for resources that 1084 require an end-to-end secured connection. Other protocols might also be used to provide access to "http" identified resources 1085 1085 — it is only the authoritative interface used for mapping the namespace that is specific to TCP. 1086 1086 </p> … … 1095 1095 <div id="rfc.iref.u.4"></div> 1096 1096 <p id="rfc.section.2.7.2.p.1">The "https" URI scheme is hereby defined for the purpose of minting identifiers according to their association with the hierarchical 1097 namespace governed by a potential HTTP origin server listening for SSL/TLS-secured connections on a given TCP port.1097 namespace governed by a potential HTTP origin server listening to a given TCP port for TLS-secured connections <a href="#RFC5246" id="rfc.xref.RFC5246.2"><cite title="The Transport Layer Security (TLS) Protocol Version 1.2">[RFC5246]</cite></a>. 1098 1098 </p> 1099 1099 <p id="rfc.section.2.7.2.p.2">All of the requirements listed above for the "http" scheme are also requirements for the "https" scheme, except that a default 1100 TCP port of 443 is assumed if the port subcomponent is empty or not given, and the TCP connection <em class="bcp14">MUST</em> be secured through the use of strong encryption prior to sending the first HTTP request.1100 TCP port of 443 is assumed if the port subcomponent is empty or not given, and the TCP connection <em class="bcp14">MUST</em> be secured, end-to-end, through the use of strong encryption prior to sending the first HTTP request. 1101 1101 </p> 1102 1102 <div id="rfc.figure.u.9"></div><pre class="inline"><span id="rfc.iref.g.25"></span> <a href="#https.uri" class="smpl">https-URI</a> = "https:" "//" <a href="#uri" class="smpl">authority</a> <a href="#uri" class="smpl">path-abempty</a> [ "?" <a href="#uri" class="smpl">query</a> ] … … 1790 1790 effective request URI is constructed as follows. 1791 1791 </p> 1792 <p id="rfc.section.5.5.p.4">If the request is received over a n SSL/TLS-secured TCP connection, then the effective request URI's scheme is "https"; otherwise,1792 <p id="rfc.section.5.5.p.4">If the request is received over a TLS-secured TCP connection, then the effective request URI's scheme is "https"; otherwise, 1793 1793 the scheme is "http". 1794 1794 </p> … … 1810 1810 <p>has an effective request URI of</p> <pre class="text">http://www.example.org:8080/pub/WWW/TheProject.html 1811 1811 </pre> <div id="rfc.figure.u.49"></div> 1812 <p>Example 2: the following message received over a n SSL/TLS-secured TCP connection</p> <pre class="text">OPTIONS * HTTP/1.11812 <p>Example 2: the following message received over a TLS-secured TCP connection</p> <pre class="text">OPTIONS * HTTP/1.1 1813 1813 Host: www.example.org 1814 1814 </pre> <div id="rfc.figure.u.50"></div> … … 3737 3737 </ul> 3738 3738 </li> 3739 <li><em>RFC5246</em> <a href="#rfc.xref.RFC5246.1">2.3</a>, <a href="# RFC5246"><b>10.2</b></a></li>3739 <li><em>RFC5246</em> <a href="#rfc.xref.RFC5246.1">2.3</a>, <a href="#rfc.xref.RFC5246.2">2.7.2</a>, <a href="#RFC5246"><b>10.2</b></a></li> 3740 3740 <li><em>RFC5322</em> <a href="#rfc.xref.RFC5322.1">2.1</a>, <a href="#rfc.xref.RFC5322.2">3</a>, <a href="#rfc.xref.RFC5322.3">5.7</a>, <a href="#RFC5322"><b>10.2</b></a><ul> 3741 3741 <li><em>Section 3.6.7</em> <a href="#rfc.xref.RFC5322.3">5.7</a></li> -
draft-ietf-httpbis/latest/p1-messaging.xml
r1901 r1903 886 886 An HTTP service based on some other underlying connection protocol 887 887 would presumably be identified using a different URI scheme, just as 888 the "https" scheme (below) is used for servers that require an SSL/TLS889 transport layer on aconnection. Other protocols might also be used to888 the "https" scheme (below) is used for resources that require an 889 end-to-end secured connection. Other protocols might also be used to 890 890 provide access to "http" identified resources — it is only the 891 891 authoritative interface used for mapping the namespace that is … … 916 916 The "https" URI scheme is hereby defined for the purpose of minting 917 917 identifiers according to their association with the hierarchical 918 namespace governed by a potential HTTP origin server listening for919 SSL/TLS-secured connections on a given TCP port.918 namespace governed by a potential HTTP origin server listening to a 919 given TCP port for TLS-secured connections <xref target="RFC5246"/>. 920 920 </t> 921 921 <t> … … 923 923 requirements for the "https" scheme, except that a default TCP port 924 924 of 443 is assumed if the port subcomponent is empty or not given, 925 and the TCP connection &MUST; be secured through the925 and the TCP connection &MUST; be secured, end-to-end, through the 926 926 use of strong encryption prior to sending the first HTTP request. 927 927 </t> … … 2362 2362 </t> 2363 2363 <t> 2364 If the request is received over a n SSL/TLS-secured TCP connection,2364 If the request is received over a TLS-secured TCP connection, 2365 2365 then the effective request URI's scheme is "https"; otherwise, the 2366 2366 scheme is "http". … … 2405 2405 <figure> 2406 2406 <preamble> 2407 Example 2: the following message received over an SSL/TLS-secured TCP 2408 connection 2407 Example 2: the following message received over a TLS-secured TCP connection 2409 2408 </preamble> 2410 2409 <artwork type="example" x:indent-with=" ">
Note: See TracChangeset
for help on using the changeset viewer.