Ignore:
Timestamp:
Mar 11, 2012, 4:49:08 AM (7 years ago)
Author:
fielding@…
Message:

Finish work on message routing by cleaning up the process of determining
an effective request URI and removing the now redundant old stuff about
"The Resource Identified by a Request". Related to #222

File:
1 edited

Legend:

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

    r1581 r1582  
    23102310   <xref target="Part2"/>, and a target resource upon which to apply those
    23112311   semantics.  A URI reference (<xref target="uri"/>) is typically used as
    2312    an identifier for the target resource, which a user agent would resolve to
    2313    its absolute form in order to obtain the target URI.  The target URI
     2312   an identifier for the "target resource", which a user agent would resolve
     2313   to its absolute form in order to obtain the "target URI".  The target URI
    23142314   excludes the reference's fragment identifier component, if any,
    23152315   since fragment identifiers are reserved for client-side processing
     
    25432543</section>
    25442544
    2545 <section title="The Resource Identified by a Request" anchor="the.resource.identified.by.a.request">
    2546 <t>
    2547    The exact resource identified by an Internet request is determined by
    2548    examining both the request-target and the Host header field.
    2549 </t>
    2550 <t>
    2551    An origin server that does not allow resources to differ by the
    2552    requested host &MAY; ignore the Host header field value when
    2553    determining the resource identified by an HTTP/1.1 request. (But see
    2554    <xref target="changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses"/>
    2555    for other requirements on Host support in HTTP/1.1.)
    2556 </t>
    2557 <t>
    2558    An origin server that does differentiate resources based on the host
    2559    requested (sometimes referred to as virtual hosts or vanity host
    2560    names) &MUST; use the following rules for determining the requested
    2561    resource on an HTTP/1.1 request:
    2562   <list style="numbers">
    2563     <t>If request-target is an absolute-URI, the host is part of the
    2564      request-target. Any Host header field value in the request &MUST; be
    2565      ignored.</t>
    2566     <t>If the request-target is not an absolute-URI, and the request includes
    2567      a Host header field, the host is determined by the Host header
    2568      field value.</t>
    2569     <t>If the host as determined by rule 1 or 2 is not a valid host on
    2570      the server, the response &MUST; be a 400 (Bad Request) error message.</t>
    2571   </list>
    2572 </t>
    2573 <t>
    2574    Recipients of an HTTP/1.0 request that lacks a Host header field &MAY;
    2575    attempt to use heuristics (e.g., examination of the URI path for
    2576    something unique to a particular host) in order to determine what
    2577    exact resource is being requested.
    2578 </t>
    2579 </section>
    2580 
    25812545<section title="Effective Request URI" anchor="effective.request.uri">
    25822546  <iref primary="true" item="effective request URI"/>
    25832547<t>
    2584    HTTP requests often do not carry the absolute URI (<xref target="RFC3986" x:fmt="," x:sec="4.3"/>)
    2585    for the target resource; instead, the URI needs to be inferred from the
    2586    request-target, Host header field, and connection context. The result of
    2587    this process is called the "effective request URI".  The "target resource"
    2588    is the resource identified by the effective request URI.
    2589 </t>
    2590 <t>
    2591    If the request-target is an absolute-URI, then the effective request URI is
    2592    the request-target.
    2593 </t>
    2594 <t>
    2595    If the request-target uses the origin form or the asterisk form,
    2596    and the Host header field is present, then the effective request URI is
    2597    constructed by concatenating
    2598 </t>
    2599 <t>
    2600   <list style="symbols">
    2601     <t>
    2602       the scheme name: "http" if the request was received over an insecure
    2603       TCP connection, or "https" when received over a SSL/TLS-secured TCP
    2604       connection,
    2605     </t>
    2606     <t>
    2607       the octet sequence "://",
    2608     </t>
    2609     <t>
    2610       the authority component, as specified in the Host header field
    2611       (<xref target="header.host"/>), and
    2612     </t>
    2613     <t>
    2614       the request-target obtained from the request-line, unless the
    2615       request-target is just the asterisk "*".
    2616     </t>
    2617   </list>
    2618 </t>
    2619 <t>
    2620    If the request-target uses the origin form or the asterisk form,
    2621    and the Host header field is not present, then the effective request URI is
    2622    undefined.
    2623 </t>
    2624 <t>
    2625    Otherwise, when request-target uses the authority form, the effective
    2626    request URI is undefined.
     2548   A server that receives an HTTP request message &MUST; reconstruct
     2549   the user agent's original target URI, based on the pieces of information
     2550   learned from the request-target, Host, and connection context, in order
     2551   to identify the intended target resource and properly service the request.
     2552   The URI derived from this reconstruction process is referred to as the
     2553   "effective request URI".
     2554</t>
     2555<t>
     2556   If the request-target is in absolute-form, then the effective request URI
     2557   is the same as the request-target.  Otherwise, the effective request URI
     2558   is constructed as follows.
     2559</t>
     2560<t>
     2561   If the request is received over an SSL/TLS-secured TCP connection,
     2562   then the effective request URI's scheme is "https"; otherwise, the
     2563   scheme is "http".
     2564</t>
     2565<t>
     2566   If the request-target is in authority-form, then the effective
     2567   request URI's authority component is the same as the request-target.
     2568   Otherwise, if a Host header field is supplied with a non-empty field-value,
     2569   then the authority component is the same as the Host field-value.
     2570   Otherwise, the authority component is the concatenation of the default
     2571   hostname configured for the server, a colon (":"), and the connection's
     2572   incoming TCP port number in decimal form.
     2573</t>
     2574<t>
     2575   If the request-target is in authority-form or asterisk-form, then the
     2576   effective request URI's combined path and query component is empty.
     2577   Otherwise, the combined path and query component is the same as the
     2578   request-target.
     2579</t>
     2580<t>
     2581   The components of the effective request URI, once determined as above,
     2582   can be combined into absolute-URI form by concatenating the scheme,
     2583   "://", authority, and combined path and query component.
    26272584</t>
    26282585<figure>
    26292586<preamble>
    2630    Example 1: the effective request URI for the message
     2587   Example 1: the following message received over an insecure TCP connection
    26312588</preamble>
    26322589<artwork type="example" x:indent-with="  ">
     
    26342591Host: www.example.org:8080
    26352592</artwork>
    2636 <postamble>
    2637   (received over an insecure TCP connection) is "http", plus "://", plus the
    2638   authority component "www.example.org:8080", plus the request-target
    2639   "/pub/WWW/TheProject.html", thus
    2640   "http://www.example.org:8080/pub/WWW/TheProject.html".
    2641 </postamble>
    26422593</figure>
    26432594<figure>
    26442595<preamble>
    2645    Example 2: the effective request URI for the message
     2596  has an effective request URI of
     2597</preamble>
     2598<artwork type="example" x:indent-with="  ">
     2599http://www.example.org:8080/pub/WWW/TheProject.html
     2600</artwork>
     2601</figure>
     2602<figure>
     2603<preamble>
     2604   Example 2: the following message received over an SSL/TLS-secured TCP
     2605   connection
    26462606</preamble>
    26472607<artwork type="example" x:indent-with="  ">
     
    26492609Host: www.example.org
    26502610</artwork>
    2651 <postamble>
    2652   (received over an SSL/TLS secured TCP connection) is "https", plus "://", plus the
    2653   authority component "www.example.org", thus "https://www.example.org".
    2654 </postamble>
    26552611</figure>
    2656 <t>
    2657    Effective request URIs are compared using the rules described in
    2658    <xref target="uri.comparison"/>, except that empty path components &MUST-NOT;
    2659    be treated as equivalent to an absolute path of "/".
    2660 </t> 
     2612<figure>
     2613<preamble>
     2614  has an effective request URI of
     2615</preamble>
     2616<artwork type="example" x:indent-with="  ">
     2617https://www.example.org
     2618</artwork>
     2619</figure>
     2620<t>
     2621   An origin server that does not allow resources to differ by requested
     2622   host &MAY; ignore the Host field-value and instead replace it with a
     2623   configured server name when constructing the effective request URI.
     2624</t>
     2625<t>
     2626   Recipients of an HTTP/1.0 request that lacks a Host header field &MAY;
     2627   attempt to use heuristics (e.g., examination of the URI path for
     2628   something unique to a particular host) in order to guess the
     2629   effective request URI's authority component.
     2630</t>
    26612631</section>
    26622632
Note: See TracChangeset for help on using the changeset viewer.