Ignore:
Timestamp:
26/07/09 09:47:10 (11 years ago)
Author:
fielding@…
Message:

Define http and https URI schemes: addresses #58, #128, #159
Resolves #157: removed reference to RFC1900 use of IP addresses in URI.

File:
1 edited

Legend:

Unmodified
Added
Removed

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

    r609 r621  
    273273   <xref target="RFC2616"/>.
    274274   Part 1 describes the architectural elements that are used or
    275    referred to in HTTP and defines the URI schemes specific to
    276    HTTP-based resources, overall network operation, connection
    277    management, and HTTP message framing and forwarding requirements.
     275   referred to in HTTP, defines the "http" and "https" URI schemes,
     276   describes overall network operation and connection management,
     277   and defines HTTP message framing and forwarding requirements.
    278278   Our goal is to define all of the mechanisms necessary for HTTP message
    279279   handling that are independent of message semantics, thereby defining the
    … …  
    502502<section title="HTTP architecture" anchor="architecture">
    503503<t>
    504    HTTP was created with a specific architecture in mind, the World Wide Web,
     504   HTTP was created for the World Wide Web architecture
    505505   and has evolved over time to support the scalability needs of a worldwide
    506506   hypertext system. Much of that architecture is reflected in the terminology
    … …  
    509509
    510510<section title="Uniform Resource Identifiers" anchor="uri">
     511<iref primary="true" item="resource"/>
    511512<t>
    512513   Uniform Resource Identifiers (URIs) <xref target="RFC3986"/> are used
    513514   throughout HTTP as the means for identifying resources. URI references
    514    are used to target requests, redirect responses, and define relationships.
     515   are used to target requests, indicate redirects, and define relationships.
    515516   HTTP does not limit what a resource may be; it merely defines an interface
    516517   that can be used to interact with a resource via HTTP. More information on
    … …  
    565566  <iref item="URI scheme" subitem="http" primary="true"/>
    566567<t>
    567    The "http" scheme is used to locate network resources via the HTTP
    568    protocol.
     568   The "http" URI scheme is hereby defined for the purpose of minting
     569   identifiers according to their association with the hierarchical
     570   namespace governed by a potential HTTP origin server listening for
     571   TCP connections on a given port.
     572   The HTTP server is identified via the generic syntax's
     573   <x:ref>authority</x:ref> component, which includes a host
     574   identifier and optional TCP port, and the remainder of the URI is
     575   considered to be identifying data corresponding to a resource for
     576   which that server might provide an HTTP interface.
    569577</t>
    570578<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="http-URI"/>
    … …  
    572580</artwork></figure>
    573581<t>
    574    If the port is empty or not given, port 80 is assumed. The semantics
    575    are that the identified resource is located at the server listening
    576    for TCP connections on that port of that host, and the request-target
    577    for the resource is path-absolute (<xref target="request-target"/>). The use of IP addresses
    578    in URLs &SHOULD; be avoided whenever possible (see <xref target="RFC1900"/>). If
    579    the path-absolute is not present in the URL, it &MUST; be given as "/" when
    580    used as a request-target for a resource (<xref target="request-target"/>). If a proxy
     582   The host identifier within an <x:ref>authority</x:ref> component is
     583   defined in <xref target="RFC3986" x:fmt="," x:sec="3.2.2"/>.  If host is
     584   provided as an IP literal or IPv4 address, then the HTTP server is any
     585   listener on the indicated TCP port at that IP address. If host is a
     586   registered name, then that name is considered an indirect identifier
     587   and the recipient might use a name resolution service, such as DNS,
     588   to find the address of a listener for that host.
     589   The host &MUST-NOT; be empty; if an "http" URI is received with an
     590   empty host, then it &MUST; be rejected as invalid.
     591   If the port subcomponent is empty or not given, then TCP port 80 is
     592   assumed (the default reserved port for WWW services).
     593</t>
     594<t>
     595   Regardless of the form of host identifier, access to that host is not
     596   implied by the mere presence of its name or address. The host may or may
     597   not exist and, even when it does exist, may or may not be running an
     598   HTTP server or listening to the indicated port. The "http" URI scheme
     599   makes use of the delegated nature of Internet names and addresses to
     600   establish a naming authority (whatever entity has the ability to place
     601   an HTTP server at that Internet name or address) and allows that
     602   authority to determine which names are valid and how they might be used.
     603</t>
     604<t>
     605   When an "http" URI is used within a context that calls for access to the
     606   indicated resource, a client &MAY; attempt access by resolving
     607   the host to an IP address, establishing a TCP connection to that address
     608   on the indicated port, and sending an HTTP request message to the server
     609   containing the URI's identifying data as described in <xref target="request"/>.
     610   If the server responds to that request with a non-interim HTTP response
     611   message, as described in <xref target="response"/>, then that response
     612   is considered an authoritative answer to the client's request.
     613</t>
     614<t>
     615   Although HTTP is independent of the transport protocol, the "http"
     616   scheme is specific to TCP-based services because the name delegation
     617   process depends on TCP for establishing authority.
     618   An HTTP service based on some other underlying connection protocol
     619   would presumably be identified using a different URI scheme, just as
     620   the "https" scheme (below) is used for servers that require an SSL/TLS
     621   transport layer on a connection. Other protocols may also be used to
     622   provide access to "http" identified resources --- it is only the
     623   authoritative interface used for mapping the namespace that is
     624   specific to TCP.
     625</t>
     626</section>
     627
     628<section title="https URI scheme" anchor="https.uri">
     629   <iref item="https URI scheme"/>
     630   <iref item="URI scheme" subitem="https"/>
     631<t>
     632   The "https" URI scheme is hereby defined for the purpose of minting
     633   identifiers according to their association with the hierarchical
     634   namespace governed by a potential HTTP origin server listening for
     635   SSL/TLS-secured connections on a given TCP port.
     636   The host and port are determined in the same way
     637   as for the "http" scheme, except that a default TCP port of 443
     638   is assumed if the port subcomponent is empty or not given.
     639</t>
     640<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="https-URI"/>
     641  <x:ref>https-URI</x:ref> = "https:" "//" <x:ref>authority</x:ref> <x:ref>path-abempty</x:ref> [ "?" <x:ref>query</x:ref> ]
     642</artwork></figure>
     643<t>
     644   The primary difference between the "http" and "https" schemes is
     645   that interaction with the latter is required to be secured for
     646   privacy through the use of strong encryption. The URI cannot be
     647   sent in a request until the connection is secure. Likewise, the
     648   default for caching is that each response that would be considered
     649   "public" under the "http" scheme is instead treated as "private"
     650   and thus not eligible for shared caching.
     651</t>
     652<t>
     653   The process for authoritative access to an "https" identified
     654   resource is defined in <xref target="RFC2818"/>.
     655</t>
     656</section>
     657
     658<section title="http and https URI Normalization and Comparison" anchor="uri.comparison">
     659<t>
     660   Since the "http" and "https" schemes conform to the URI generic syntax,
     661   such URIs are normalized and compared according to the algorithm defined
     662   in <xref target="RFC3986" x:fmt="," x:sec="6"/>, using the defaults
     663   described above for each scheme.
     664</t>
     665<t>
     666   If the port is equal to the default port for a scheme, the normal
     667   form is to elide the port subcomponent. Likewise, an empty path
     668   component is equivalent to an absolute path of "/", so the normal
     669   form is to provide a path of "/" instead. The scheme and host
     670   are case-insensitive and normally provided in lowercase; all
     671   other components are compared in a case-sensitive manner.
     672   Characters other than those in the "reserved" set are equivalent
     673   to their percent-encoded octets (see <xref target="RFC3986"
     674   x:fmt="," x:sec="2.1"/>): the normal form is to not encode them.
     675</t>
     676<t>
     677   For example, the following three URIs are equivalent:
     678</t>
     679<figure><artwork type="example">
     680   http://example.com:80/~smith/home.html
     681   http://EXAMPLE.com/%7Esmith/home.html
     682   http://EXAMPLE.com:/%7esmith/home.html
     683</artwork></figure>
     684<t>
     685   <cref>[[This paragraph does not belong here. --Roy]]</cref>
     686   If path-abempty is the empty string (i.e., there is no slash "/"
     687   path separator following the authority), then the "http" URI
     688   &MUST; be given as "/" when
     689   used as a request-target (<xref target="request-target"/>). If a proxy
    581690   receives a host name which is not a fully qualified domain name, it
    582691   &MAY; add its domain to the host name it received. If a proxy receives
    … …  
    586695</section>
    587696
    588 <section title="https URI scheme" anchor="https.uri">
    589    <iref item="https URI scheme"/>
    590    <iref item="URI scheme" subitem="https"/>
    591 <t>
    592    <cref>TBD: Define and explain purpose of https scheme.</cref>
    593 </t>
    594 <x:note>
    595   <t>
    596     <x:h>Note:</x:h> the "https" scheme is defined in <xref target="RFC2818"/>.
    597   </t>
    598 </x:note>
    599 </section>
    600 
    601 <section title="URI Comparison" anchor="uri.comparison">
    602 <t>
    603    When comparing two URIs to decide if they match or not, a client
    604    &SHOULD; use a case-sensitive octet-by-octet comparison of the entire
    605    URIs, with these exceptions:
    606   <list style="symbols">
    607     <t>A port that is empty or not given is equivalent to the default
    608         port for that URI-reference;</t>
    609     <t>Comparisons of host names &MUST; be case-insensitive;</t>
    610     <t>Comparisons of scheme names &MUST; be case-insensitive;</t>
    611     <t>An empty path-absolute is equivalent to a path-absolute of "/".</t>
    612     <t>Characters other than those in the "reserved" set are equivalent to their
    613        percent-encoded octets (see <xref target="RFC3986" x:fmt="," x:sec="2.1"/>).
    614     </t>
    615   </list>
    616 </t>
    617 <t>
    618    For example, the following three URIs are equivalent:
    619 </t>
    620 <figure><artwork type="example">
    621    http://example.com:80/~smith/home.html
    622    http://EXAMPLE.com/%7Esmith/home.html
    623    http://EXAMPLE.com:/%7esmith/home.html
    624 </artwork></figure>
    625 </section>
    626 
    627697<section title="Scheme aliases considered harmful" anchor="scheme.aliases">
    628698<t>
     699   <cref>TBS: describe why aliases like webcal are harmful.</cref>
    629700</t>
    630701</section>
    … …  
    640711   including the message's protocol version and a success or error code,
    641712   followed by a MIME-like message containing server information, entity
    642    metainformation, and possible entity-body content.
     713   metadata, and possible entity-body content.
    643714</t>
    644715<t>
    645716   Most HTTP communication is initiated by a user agent and consists of
    646    a request to be applied to a resource on some origin server. In the
     717   a request to be applied to a resource via the HTTP interface provided
     718   by some origin server. In the
    647719   simplest case, this may be accomplished via a single connection (v)
    648720   between the user agent (UA) and the origin server (O).
    … …  
    41954267    <t>
    41964268      The information transferred as the payload of a request or
    4197       response. An entity consists of metainformation in the form of
     4269      response. An entity consists of metadata in the form of
    41984270      entity-header fields and content in the form of an entity-body, as
    41994271      described in &entity;.
    … …  
    42734345    <t>
    42744346      An HTTP request message, as defined in <xref target="request"/>.
    4275     </t>
    4276   </list>
    4277 </t>
    4278 <t>
    4279   <iref item="resource"/>
    4280   <x:dfn>resource</x:dfn>
    4281   <list>
    4282     <t>
    4283       A network data object or service that can be identified by a URI,
    4284       as defined in <xref target="uri"/>. Resources may be available in multiple
    4285       representations (e.g. multiple languages, data formats, size, and
    4286       resolutions) or vary in other ways.
    42874347    </t>
    42884348  </list>
    … …  
    45734633; generic-message defined but not used
    45744634; http-URI defined but not used
     4635; https-URI defined but not used
    45754636; partial-URI defined but not used
    45764637</artwork></figure></section>
Note: See TracChangeset for help on using the changeset viewer.