Changeset 2587 for draft-ietf-httpbis


Ignore:
Timestamp:
26/01/14 11:14:39 (7 years ago)
Author:
fielding@…
Message:

Use factual phrasing for reconstructing an effective request URI
instead of a MUST; see #531

Update the description of constructing the effective request URI such
that it defers to local configuration.

Add a paragraph about the need for an origin server to verify that the
constructed URI is consistent with the connection context, and point to
(not yet complete) security considerations on routing; see #550

Location:
draft-ietf-httpbis/latest
Files:
2 edited

Legend:

Unmodified
Added
Removed

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

    r2586 r2587  
    19451945            <div id="rfc.iref.e.1"></div>
    19461946            <h2 id="rfc.section.5.5"><a href="#rfc.section.5.5">5.5</a>&nbsp;<a href="#effective.request.uri">Effective Request URI</a></h2>
    1947             <p id="rfc.section.5.5.p.1">A server that receives an HTTP request message <em class="bcp14">MUST</em> reconstruct the user agent's original target URI, based on the pieces of information learned from the request-target, <a href="#header.host" class="smpl">Host</a> header field, and connection context, in order to identify the intended target resource and properly service the request.
    1948                The URI derived from this reconstruction process is referred to as the "<dfn>effective request URI</dfn>".
     1947            <p id="rfc.section.5.5.p.1">Since the request-target often contains only part of the user agent's target URI, a server reconstructs the intended target
     1948               as an "<dfn>effective request URI</dfn>" to properly service the request. This reconstruction involves both the server's local configuration and information communicated
     1949               in the request-target, <a href="#header.host" class="smpl">Host</a> header field, and connection context.
    19491950            </p>
    19501951            <p id="rfc.section.5.5.p.2">For a user agent, the effective request URI is the target URI.</p>
    19511952            <p id="rfc.section.5.5.p.3">If the request-target is in absolute-form, then the effective request URI is the same as the request-target. Otherwise, the
    1952                effective request URI is constructed as follows.
    1953             </p>
    1954             <p id="rfc.section.5.5.p.4">If the request is received over a TLS-secured TCP connection, then the effective request URI's scheme is "https"; otherwise,
    1955                the scheme is "http".
    1956             </p>
    1957             <p id="rfc.section.5.5.p.5">If the request-target is in authority-form, then the effective request URI's authority component is the same as the request-target.
    1958                Otherwise, if a <a href="#header.host" class="smpl">Host</a> header field is supplied with a non-empty field-value, then the authority component is the same as the Host field-value. Otherwise,
    1959                the authority component is the concatenation of the default host name configured for the server, a colon (":"), and the connection's
    1960                incoming TCP port number in decimal form.
    1961             </p>
    1962             <p id="rfc.section.5.5.p.6">If the request-target is in authority-form or asterisk-form, then the effective request URI's combined path and query component
    1963                is empty. Otherwise, the combined path and query component is the same as the request-target.
    1964             </p>
    1965             <p id="rfc.section.5.5.p.7">The components of the effective request URI, once determined as above, can be combined into absolute-URI form by concatenating
    1966                the scheme, "://", authority, and combined path and query component.
    1967             </p>
     1953               effective request URI is constructed as follows:
     1954            </p>
     1955            <ul class="empty">
     1956               <li>If the server's configuration (or outbound gateway) provides a fixed URI scheme, that scheme is used for the effective request
     1957                  URI. Otherwise, if the request is received over a TLS-secured TCP connection, the effective request URI's scheme is "https";
     1958                  if not, the scheme is "http".
     1959               </li>
     1960               <li>If the server's configuration (or outbound gateway) provides a fixed URI authority component, that authority is used for the
     1961                  effective request URI. If not, then if the request-target is in authority-form, the effective request URI's authority component
     1962                  is the same as the request-target. If not, then if a <a href="#header.host" class="smpl">Host</a> header field is supplied with a non-empty field-value, the authority component is the same as the Host field-value. Otherwise,
     1963                  the authority component is assigned the default name configured for the server and, if the connection's incoming TCP port
     1964                  number differs from the default port for the effective request URI's scheme, then a colon (":") and the incoming port number
     1965                  (in decimal form) are appended to the authority component.
     1966               </li>
     1967               <li>If the request-target is in authority-form or asterisk-form, the effective request URI's combined path and query component
     1968                  is empty. Otherwise, the combined path and query component is the same as the request-target.
     1969               </li>
     1970               <li>The components of the effective request URI, once determined as above, can be combined into absolute-URI form by concatenating
     1971                  the scheme, "://", authority, and combined path and query component.
     1972               </li>
     1973            </ul>
    19681974            <div id="rfc.figure.u.48"></div>
    19691975            <p>Example 1: the following message received over an insecure TCP connection</p><pre class="text">GET /pub/WWW/TheProject.html HTTP/1.1
    … …  
    19761982</pre><div id="rfc.figure.u.51"></div>
    19771983            <p>has an effective request URI of</p><pre class="text">https://www.example.org
    1978 </pre><p id="rfc.section.5.5.p.12">An origin server that does not allow resources to differ by requested host <em class="bcp14">MAY</em> ignore the <a href="#header.host" class="smpl">Host</a> field-value and instead replace it with a configured server name when constructing the effective request URI.
    1979             </p>
    1980             <p id="rfc.section.5.5.p.13">Recipients of an HTTP/1.0 request that lacks a <a href="#header.host" class="smpl">Host</a> header field <em class="bcp14">MAY</em> attempt to use heuristics (e.g., examination of the URI path for something unique to a particular host) in order to guess
    1981                the effective request URI's authority component.
     1984</pre><p id="rfc.section.5.5.p.8">Recipients of an HTTP/1.0 request that lacks a <a href="#header.host" class="smpl">Host</a> header field might need to use heuristics (e.g., examination of the URI path for something unique to a particular host) in
     1985               order to guess the effective request URI's authority component.
     1986            </p>
     1987            <p id="rfc.section.5.5.p.9">Once the effective request URI has been constructed, an origin server needs to decide whether or not to provide service for
     1988               that URI via the connection in which the request was received. For example, the request might have been misdirected, deliberately
     1989               or accidentally, such that the information within a received absolute-form URI or <a href="#header.host" class="smpl">Host</a> header field differs from the host or port upon which the connection has been made. If the connection is from a trusted gateway,
     1990               that inconsistency might be expected; otherwise, it might indicate an attempt to bypass security filters, trick the server
     1991               into delivering non-public content, or poison a cache. See <a href="#security.considerations" title="Security Considerations">Section&nbsp;9</a> for security considerations regarding message routing.
    19821992            </p>
    19831993         </div>

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

    r2586 r2587  
    24962496  <x:anchor-alias value="effective request URI"/>
    24972497<t>
    2498    A server that receives an HTTP request message &MUST; reconstruct
    2499    the user agent's original target URI, based on the pieces of information
    2500    learned from the request-target, <x:ref>Host</x:ref> header field, and
    2501    connection context, in order to identify the intended target resource and
    2502    properly service the request. The URI derived from this reconstruction
    2503    process is referred to as the "<x:dfn>effective request URI</x:dfn>".
     2498   Since the request-target often contains only part of the user agent's
     2499   target URI, a server reconstructs the intended target as an
     2500   "<x:dfn>effective request URI</x:dfn>" to properly service the request.
     2501   This reconstruction involves both the server's local configuration and
     2502   information communicated in the request-target, <x:ref>Host</x:ref> header
     2503   field, and connection context.
    25042504</t>
    25052505<t>
    … …  
    25092509   If the request-target is in absolute-form, then the effective request URI
    25102510   is the same as the request-target.  Otherwise, the effective request URI
    2511    is constructed as follows.
    2512 </t>
    2513 <t>
    2514    If the request is received over a TLS-secured TCP connection,
    2515    then the effective request URI's scheme is "https"; otherwise, the
    2516    scheme is "http".
    2517 </t>
    2518 <t>
    2519    If the request-target is in authority-form, then the effective
     2511   is constructed as follows:
     2512<list style="empty">
     2513<t>
     2514   If the server's configuration (or outbound gateway) provides a fixed URI
     2515   scheme, that scheme is used for the effective request URI.
     2516   Otherwise, if the request is received over a TLS-secured TCP connection,
     2517   the effective request URI's scheme is "https"; if not, the scheme is "http".
     2518</t>
     2519<t>
     2520   If the server's configuration (or outbound gateway) provides a fixed URI
     2521   authority component, that authority is used for the effective request URI.
     2522   If not, then if the request-target is in authority-form, the effective
    25202523   request URI's authority component is the same as the request-target.
    2521    Otherwise, if a <x:ref>Host</x:ref> header field is supplied with a
    2522    non-empty field-value, then the authority component is the same as the
    2523    Host field-value. Otherwise, the authority component is the concatenation of
    2524    the default host name configured for the server, a colon (":"), and the
    2525    connection's incoming TCP port number in decimal form.
    2526 </t>
    2527 <t>
    2528    If the request-target is in authority-form or asterisk-form, then the
     2524   If not, then if a <x:ref>Host</x:ref> header field is supplied with a
     2525   non-empty field-value, the authority component is the same as the
     2526   Host field-value. Otherwise, the authority component is assigned
     2527   the default name configured for the server and, if the connection's
     2528   incoming TCP port number differs from the default port for the effective
     2529   request URI's scheme, then a colon (":") and the incoming port number (in
     2530   decimal form) are appended to the authority component.
     2531</t>
     2532<t>
     2533   If the request-target is in authority-form or asterisk-form, the
    25292534   effective request URI's combined path and query component is empty.
    25302535   Otherwise, the combined path and query component is the same as the
    … …  
    25352540   can be combined into absolute-URI form by concatenating the scheme,
    25362541   "://", authority, and combined path and query component.
     2542</t>
     2543</list>
    25372544</t>
    25382545<figure>
    … …  
    25712578</figure>
    25722579<t>
    2573    An origin server that does not allow resources to differ by requested
    2574    host &MAY; ignore the <x:ref>Host</x:ref> field-value and instead replace it
    2575    with a configured server name when constructing the effective request URI.
    2576 </t>
    2577 <t>
    25782580   Recipients of an HTTP/1.0 request that lacks a <x:ref>Host</x:ref> header
    2579    field &MAY; attempt to use heuristics (e.g., examination of the URI path for
     2581   field might need to use heuristics (e.g., examination of the URI path for
    25802582   something unique to a particular host) in order to guess the
    25812583   effective request URI's authority component.
     2584</t>
     2585<t>
     2586   Once the effective request URI has been constructed, an origin server needs
     2587   to decide whether or not to provide service for that URI via the connection
     2588   in which the request was received. For example, the request might have
     2589   been misdirected, deliberately or accidentally, such that the information
     2590   within a received absolute-form URI or <x:ref>Host</x:ref> header field
     2591   differs from the host or port upon which the connection has been made.
     2592   If the connection is from a trusted gateway, that inconsistency might be
     2593   expected; otherwise, it might indicate an attempt to bypass security
     2594   filters, trick the server into delivering non-public content, or poison
     2595   a cache. See <xref target="security.considerations"/> for security
     2596   considerations regarding message routing.
    25822597</t>
    25832598</section>
Note: See TracChangeset for help on using the changeset viewer.