Changeset 877

Timestamp:

23/07/10 07:51:05 (13 years ago)

Author:

fielding@…

Message:

Addresses #159: HTTP(s) URI scheme definitions

Make clear that userinfo is not allowed.
Clarify the differences between "http" and "https".

File:

• draft-ietf-httpbis/latest/p1-messaging.xml (modified) (3 diffs)

draft-ietf-httpbis/latest/p1-messaging.xml

@@ -960 +960 @@
    specific to TCP.
 </t>
+<t>
+   The URI generic syntax for authority also includes a deprecated
+   userinfo subcomponent (<xref target="RFC3986" x:fmt="," x:sec="3.2.1"/>)
+   for including user authentication information in the URI.  The userinfo
+   subcomponent (and its "@" delimiter) &MUST-NOT; be used in an "http"
+   URI.  URI reference recipients &SHOULD; parse for the existence of
+   userinfo and treat its presence as an error, likely indicating that
+   the deprecated subcomponent is being used to obscure the authority
+   for the sake of phishing attacks.
+</t>
 </section>
 
@@ -971 +981 @@
    namespace governed by a potential HTTP origin server listening for
    SSL/TLS-secured connections on a given TCP port.
-   The host and port are determined in the same way
-   as for the "http" scheme, except that a default TCP port of 443
-   is assumed if the port subcomponent is empty or not given.
+</t>
+<t>
+   All of the requirements listed above for the "http" scheme are also
+   requirements for the "https" scheme, except that a default TCP port
+   of 443 is assumed if the port subcomponent is empty or not given,
+   and the TCP connection &MUST; be secured for privacy through the
+   use of strong encryption prior to sending the first HTTP request.
 </t>
 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="https-URI"/>
@@ -979 +993 @@
 </artwork></figure>
 <t>
-   The primary difference between the "http" and "https" schemes is
-   that interaction with the latter is required to be secured for
-   privacy through the use of strong encryption. The URI cannot be
-   sent in a request until the connection is secure. Likewise, the
-   default for caching is that each response that would be considered
-   "public" under the "http" scheme is instead treated as "private"
-   and thus not eligible for shared caching.
+   Unlike the "http" scheme, responses to "https" identified requests
+   are never "public" and thus are ineligible for shared caching.
+   Their default is "private" and may be further constrained via use
+   of the Cache-Control header field.
+</t>
+<t>
+   Resources made available via the "https" scheme have no shared
+   identity with the "http" scheme even if their resource identifiers
+   only differ by the single "s" in the scheme name.  They are
+   different services governed by different authorities.  However,
+   some extensions to HTTP that apply to entire host domains, such
+   as the Cookie protocol, do allow one service to effect communication
+   with the other services based on host domain matching.
 </t>
 <t>