Changeset 877

Jul 23, 2010, 12:51:05 AM (9 years ago)

Addresses #159: HTTP(s) URI scheme definitions

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

1 edited


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

    r876 r877  
    960960   specific to TCP.
     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.
    971981   namespace governed by a potential HTTP origin server listening for
    972982   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.
     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.
    977991<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="https-URI"/>
    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.
     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.
Note: See TracChangeset for help on using the changeset viewer.