Changeset 877
- Timestamp:
- 23/07/10 07:51:05 (13 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.xml
r876 r877 960 960 specific to TCP. 961 961 </t> 962 <t> 963 The URI generic syntax for authority also includes a deprecated 964 userinfo subcomponent (<xref target="RFC3986" x:fmt="," x:sec="3.2.1"/>) 965 for including user authentication information in the URI. The userinfo 966 subcomponent (and its "@" delimiter) &MUST-NOT; be used in an "http" 967 URI. URI reference recipients &SHOULD; parse for the existence of 968 userinfo and treat its presence as an error, likely indicating that 969 the deprecated subcomponent is being used to obscure the authority 970 for the sake of phishing attacks. 971 </t> 962 972 </section> 963 973 … … 971 981 namespace governed by a potential HTTP origin server listening for 972 982 SSL/TLS-secured connections on a given TCP port. 973 The host and port are determined in the same way 974 as for the "http" scheme, except that a default TCP port of 443 975 is assumed if the port subcomponent is empty or not given. 983 </t> 984 <t> 985 All of the requirements listed above for the "http" scheme are also 986 requirements for the "https" scheme, except that a default TCP port 987 of 443 is assumed if the port subcomponent is empty or not given, 988 and the TCP connection &MUST; be secured for privacy through the 989 use of strong encryption prior to sending the first HTTP request. 976 990 </t> 977 991 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="https-URI"/> … … 979 993 </artwork></figure> 980 994 <t> 981 The primary difference between the "http" and "https" schemes is 982 that interaction with the latter is required to be secured for 983 privacy through the use of strong encryption. The URI cannot be 984 sent in a request until the connection is secure. Likewise, the 985 default for caching is that each response that would be considered 986 "public" under the "http" scheme is instead treated as "private" 987 and thus not eligible for shared caching. 995 Unlike the "http" scheme, responses to "https" identified requests 996 are never "public" and thus are ineligible for shared caching. 997 Their default is "private" and may be further constrained via use 998 of the Cache-Control header field. 999 </t> 1000 <t> 1001 Resources made available via the "https" scheme have no shared 1002 identity with the "http" scheme even if their resource identifiers 1003 only differ by the single "s" in the scheme name. They are 1004 different services governed by different authorities. However, 1005 some extensions to HTTP that apply to entire host domains, such 1006 as the Cookie protocol, do allow one service to effect communication 1007 with the other services based on host domain matching. 988 1008 </t> 989 1009 <t>
Note: See TracChangeset
for help on using the changeset viewer.