* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Changeset 877


Ignore:
Timestamp:
2010-07-23 00:51:05 (4 years ago)
Author:
fielding@gbiv.com
Message:

Addresses #159: HTTP(s) URI scheme definitions

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

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p1-messaging.xml

    r876 r877  
    960960   specific to TCP. 
    961961</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> 
    962972</section> 
    963973 
     
    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. 
     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. 
    976990</t> 
    977991<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="https-URI"/> 
     
    979993</artwork></figure> 
    980994<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. 
    9881008</t> 
    9891009<t> 
Note: See TracChangeset for help on using the changeset viewer.