Changeset 1575 for draft-ietf-httpbis/latest/p1-messaging.xml

Timestamp:

Mar 10, 2012, 2:57:18 AM (8 years ago)

Author:

fielding@…

Message:

Explain first half of message routing. Related to #218.

File:

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

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

@@ -1136 +1136 @@
 </section>
 
-<section title="request-target" anchor="request-target">
+<section title="Request Target" anchor="request-target">
   <x:anchor-alias value="request-target"/>
 <t>
@@ -2295 +2295 @@
 <section title="Message Routing" anchor="message.routing">
 <t>
-   In most cases, the user agent is provided a URI reference
-   from which it determines an absolute URI for identifying the target
-   resource.  When a request to the resource is initiated, all or part
-   of that URI is used to construct the HTTP request-target.
-</t>
+   HTTP request message routing is determined by each client based on the
+   target resource, the client's proxy configuration, and
+   establishment or reuse of an inbound connection.  The corresponding
+   response routing follows the same connection chain back to the client.
+</t>
+
+<section title="Identifying a Target Resource" anchor="target-resource">
+<t>
+   HTTP is used in a wide variety of applications, ranging from
+   general-purpose computers to home appliances.  In some cases,
+   communication options are hard-coded in a client's configuration.
+   However, most HTTP clients rely on the same resource identification
+   mechanism and configuration techniques as general-purpose Web browsers.
+</t>
+<t>
+   HTTP communication is initiated by a user agent for some purpose.
+   The purpose is a combination of request semantics, which are defined in
+   <xref target="Part2"/>, and a target resource upon which to apply those
+   semantics.  A URI reference (<xref target="uri"/>) is typically used as
+   an identifier for the target resource, which a user agent would resolve to
+   its absolute form in order to obtain the target URI.  The target URI
+   excludes the reference's fragment identifier component, if any,
+   since fragment identifiers are for client-side processing only.
+</t>
+<t>
+   HTTP intermediaries obtain the request semantics and target URI
+   from the request-line of an incoming request message.
+</t>
+</section>
+
+<section title="Connecting Inbound" anchor="connecting.inbound">
+<t>
+   Once the target URI is determined, a client needs to decide whether
+   a network request is necessary to accomplish the desired semantics and,
+   if so, where that request is to be directed.
+</t>
+<t>
+   If the client has a response cache and the request semantics can be
+   satisfied by a cache (<xref target="Part6"/>), then the request is
+   usually directed to the cache first.
+</t>
+<t>
+   If the request is not satisfied by a cache, then a typical client will
+   check its configuration to determine whether a proxy is to be used to
+   satisfy the request.  Proxy configuration is implementation-dependent,
+   but is often based on URI prefix matching, selective authority matching,
+   or both, and the proxy itself is usually identified by an "http" or
+   "https" URI.  If a proxy is applicable, the client connects inbound by 
+   establishing (or reusing) a connection to that proxy.
+</t>
+<t>
+   If no proxy is applicable, a typical client will invoke a handler routine,
+   usually specific to the target URI's scheme, to connect directly
+   to an authority for the target resource.  How that is accomplished is
+   dependent on the target URI scheme and defined by its associated
+   specification, similar to how this specification defines origin server
+   access for resolution of the "http" (<xref target="http.uri"/>) and
+   "https" (<xref target="https.uri"/>) schemes.
+</t>
+</section>
 
 <section title="Types of Request Target" anchor="request-target-types">
 <t>
-   The proper format choice of the four options available to request-target
-   depends on the method being requested and if the request is being made to
-   a proxy.
+   Once an inbound connection is obtained, the client sends an HTTP request
+   message (<xref target="http.message"/>) with a request-target derived from
+   the target URI.  There are four distinct formats for the request-target
+   (<xref target="request-target"/>), depending on both the method being
+   requested and whether the request is to a proxy.
 </t>   
 <t anchor="origin-form"><iref item="origin form (of request-target)"/>