Ignore:
Timestamp:
Mar 9, 2012, 11:18:43 PM (8 years ago)
Author:
fielding@…
Message:

(editorial) move transfer codings section up to be next to message parsing

File:
1 edited

Legend:

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

    r1572 r1574  
    19191919</section>
    19201920
    1921 <section title="Message Routing" anchor="message.routing">
    1922 <t>
    1923    In most cases, the user agent is provided a URI reference
    1924    from which it determines an absolute URI for identifying the target
    1925    resource.  When a request to the resource is initiated, all or part
    1926    of that URI is used to construct the HTTP request-target.
    1927 </t>
    1928 
    1929 <section title="Types of Request Target" anchor="request-target-types">
    1930 <t>
    1931    The proper format choice of the four options available to request-target
    1932    depends on the method being requested and if the request is being made to
    1933    a proxy.
    1934 </t>   
    1935 <t anchor="origin-form"><iref item="origin form (of request-target)"/>
    1936    The most common form of request-target is that used when making
    1937    a request to an origin server ("origin form") to access a resource
    1938    identified by an "http" (<xref target="http.uri"/>) or
    1939    "https" (<xref target="https.uri"/>) URI.
    1940    In this case, the absolute path and query components of the URI
    1941    &MUST; be transmitted as the request-target and the authority component
    1942    (excluding any userinfo) &MUST; be transmitted in a Host header field.
    1943    For example, a client wishing to retrieve a representation of the resource
    1944    identified as
    1945 </t>
    1946 <figure><artwork x:indent-with="  ">
    1947 http://www.example.org/where?q=now
    1948 </artwork></figure>
    1949 <t>
    1950    directly from the origin server would open (or reuse) a TCP connection
    1951    to port 80 of the host "www.example.org" and send the lines:
    1952 </t>
    1953 <figure><artwork type="message/http; msgtype=&#34;request&#34;" x:indent-with="  ">
    1954 GET /where?q=now HTTP/1.1
    1955 Host: www.example.org
    1956 </artwork></figure>
    1957 <t>
    1958    followed by the remainder of the request. Note that the origin form
    1959    of request-target always starts with an absolute path. If the target
    1960    resource's URI path is empty, then an absolute path of "/" &MUST; be
    1961    provided in the request-target.
    1962 </t>
    1963 <t>
    1964    If the request-target is percent-encoded
    1965    (<xref target="RFC3986" x:fmt="," x:sec="2.1"/>), the origin server
    1966    &MUST; decode the request-target in order to
    1967    properly interpret the request. Servers &SHOULD; respond to invalid
    1968    request-targets with an appropriate status code.
    1969 </t>
    1970 <t anchor="absolute-URI-form"><iref item="absolute-URI form (of request-target)"/>
    1971    The "absolute-URI" form of request-target is &REQUIRED; when the request
    1972    is being made to a proxy.  The proxy is requested to either forward the
    1973    request or service it from a valid cache, and then return the response.
    1974    Note that the proxy &MAY; forward the request on to another proxy or
    1975    directly to the server specified by the absolute-URI.
    1976    In order to avoid request loops, a proxy that forwards requests to other
    1977    proxies &MUST; be able to recognize and exclude all of its own server
    1978    names, including any aliases, local variations, or literal IP addresses.
    1979    An example request-line would be:
    1980 </t>
    1981 <figure><artwork type="message/http; msgtype=&#34;request&#34;" x:indent-with="  ">
    1982 GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1
    1983 </artwork></figure>
    1984 <t>
    1985    To allow for transition to absolute-URIs in all requests in future
    1986    versions of HTTP, all HTTP/1.1 servers &MUST; accept the absolute-URI
    1987    form in requests, even though HTTP/1.1 clients will only generate
    1988    them in requests to proxies.
    1989 </t>
    1990 <t>
    1991    If a proxy receives a host name that is not a fully qualified domain
    1992    name, it &MAY; add its domain to the host name it received. If a proxy
    1993    receives a fully qualified domain name, the proxy &MUST-NOT; change
    1994    the host name.
    1995 </t>
    1996 <t anchor="authority-form"><iref item="authority form (of request-target)"/>
    1997    The "authority form" of request-target, which &MUST-NOT; be used
    1998    with any request method other than CONNECT, is used to establish a
    1999    tunnel through one or more proxies (&CONNECT;).  For example,
    2000 </t>
    2001 <figure><artwork type="message/http; msgtype=&#34;request&#34;" x:indent-with="  ">
    2002 CONNECT www.example.com:80 HTTP/1.1
    2003 </artwork></figure>
    2004 <t anchor="asterix-form"><iref item="asterisk form (of request-target)"/>
    2005    The asterisk ("*") form of request-target, which &MUST-NOT; be used
    2006    with any request method other than OPTIONS, means that the request
    2007    applies to the server as a whole (the listening process) rather than
    2008    to a specific named resource at that server.  For example,
    2009 </t>
    2010 <figure><artwork type="message/http; msgtype=&#34;request&#34;" x:indent-with="  ">
    2011 OPTIONS * HTTP/1.1
    2012 </artwork></figure>
    2013 <t>
    2014    If a proxy receives an OPTIONS request with an absolute-URI form of
    2015    request-target in which the URI has an empty path and no query component,
    2016    then the last proxy on the request chain &MUST; use a request-target
    2017    of "*" when it forwards the request to the indicated origin server.
    2018 </t>
    2019 <figure><preamble>   
    2020    For example, the request
    2021 </preamble><artwork type="message/http; msgtype=&#34;request&#34;" x:indent-with="  ">
    2022 OPTIONS http://www.example.org:8001 HTTP/1.1
    2023 </artwork></figure>
    2024 <figure><preamble>   
    2025   would be forwarded by the final proxy as
    2026 </preamble><artwork type="message/http; msgtype=&#34;request&#34;" x:indent-with="  ">
    2027 OPTIONS * HTTP/1.1
    2028 Host: www.example.org:8001
    2029 </artwork>
    2030 <postamble>
    2031    after connecting to port 8001 of host "www.example.org".
    2032 </postamble>
    2033 </figure>
    2034 <t>
    2035    A non-transforming proxy &MUST-NOT; rewrite the "path-absolute" and "query"
    2036    parts of the received request-target when forwarding it to the next inbound
    2037    server, except as noted above to replace a null path-absolute with "/" or
    2038    "*".
    2039 </t>
    2040 </section>
    2041 
    2042 <section title="The Resource Identified by a Request" anchor="the.resource.identified.by.a.request">
    2043 <t>
    2044    The exact resource identified by an Internet request is determined by
    2045    examining both the request-target and the Host header field.
    2046 </t>
    2047 <t>
    2048    An origin server that does not allow resources to differ by the
    2049    requested host &MAY; ignore the Host header field value when
    2050    determining the resource identified by an HTTP/1.1 request. (But see
    2051    <xref target="changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses"/>
    2052    for other requirements on Host support in HTTP/1.1.)
    2053 </t>
    2054 <t>
    2055    An origin server that does differentiate resources based on the host
    2056    requested (sometimes referred to as virtual hosts or vanity host
    2057    names) &MUST; use the following rules for determining the requested
    2058    resource on an HTTP/1.1 request:
    2059   <list style="numbers">
    2060     <t>If request-target is an absolute-URI, the host is part of the
    2061      request-target. Any Host header field value in the request &MUST; be
    2062      ignored.</t>
    2063     <t>If the request-target is not an absolute-URI, and the request includes
    2064      a Host header field, the host is determined by the Host header
    2065      field value.</t>
    2066     <t>If the host as determined by rule 1 or 2 is not a valid host on
    2067      the server, the response &MUST; be a 400 (Bad Request) error message.</t>
    2068   </list>
    2069 </t>
    2070 <t>
    2071    Recipients of an HTTP/1.0 request that lacks a Host header field &MAY;
    2072    attempt to use heuristics (e.g., examination of the URI path for
    2073    something unique to a particular host) in order to determine what
    2074    exact resource is being requested.
    2075 </t>
    2076 </section>
    2077 
    2078 <section title="Effective Request URI" anchor="effective.request.uri">
    2079   <iref primary="true" item="effective request URI"/>
    2080   <iref primary="true" item="target resource"/>
    2081 <t>
    2082    HTTP requests often do not carry the absolute URI (<xref target="RFC3986" x:fmt="," x:sec="4.3"/>)
    2083    for the target resource; instead, the URI needs to be inferred from the
    2084    request-target, Host header field, and connection context. The result of
    2085    this process is called the "effective request URI".  The "target resource"
    2086    is the resource identified by the effective request URI.
    2087 </t>
    2088 <t>
    2089    If the request-target is an absolute-URI, then the effective request URI is
    2090    the request-target.
    2091 </t>
    2092 <t>
    2093    If the request-target uses the origin form or the asterisk form,
    2094    and the Host header field is present, then the effective request URI is
    2095    constructed by concatenating
    2096 </t>
    2097 <t>
    2098   <list style="symbols">
    2099     <t>
    2100       the scheme name: "http" if the request was received over an insecure
    2101       TCP connection, or "https" when received over a SSL/TLS-secured TCP
    2102       connection,
    2103     </t>
    2104     <t>
    2105       the octet sequence "://",
    2106     </t>
    2107     <t>
    2108       the authority component, as specified in the Host header field
    2109       (<xref target="header.host"/>), and
    2110     </t>
    2111     <t>
    2112       the request-target obtained from the request-line, unless the
    2113       request-target is just the asterisk "*".
    2114     </t>
    2115   </list>
    2116 </t>
    2117 <t>
    2118    If the request-target uses the origin form or the asterisk form,
    2119    and the Host header field is not present, then the effective request URI is
    2120    undefined.
    2121 </t>
    2122 <t>
    2123    Otherwise, when request-target uses the authority form, the effective
    2124    request URI is undefined.
    2125 </t>
    2126 <figure>
    2127 <preamble>
    2128    Example 1: the effective request URI for the message
    2129 </preamble>
    2130 <artwork type="example" x:indent-with="  ">
    2131 GET /pub/WWW/TheProject.html HTTP/1.1
    2132 Host: www.example.org:8080
    2133 </artwork>
    2134 <postamble>
    2135   (received over an insecure TCP connection) is "http", plus "://", plus the
    2136   authority component "www.example.org:8080", plus the request-target
    2137   "/pub/WWW/TheProject.html", thus
    2138   "http://www.example.org:8080/pub/WWW/TheProject.html".
    2139 </postamble>
    2140 </figure>
    2141 <figure>
    2142 <preamble>
    2143    Example 2: the effective request URI for the message
    2144 </preamble>
    2145 <artwork type="example" x:indent-with="  ">
    2146 OPTIONS * HTTP/1.1
    2147 Host: www.example.org
    2148 </artwork>
    2149 <postamble>
    2150   (received over an SSL/TLS secured TCP connection) is "https", plus "://", plus the
    2151   authority component "www.example.org", thus "https://www.example.org".
    2152 </postamble>
    2153 </figure>
    2154 <t>
    2155    Effective request URIs are compared using the rules described in
    2156    <xref target="uri.comparison"/>, except that empty path components &MUST-NOT;
    2157    be treated as equivalent to an absolute path of "/".
    2158 </t> 
    2159 </section>
    2160 
    2161 <section title="Associating a Response to a Request" anchor="associating.response.to.request">
    2162 <t>
    2163    HTTP does not include a request identifier for associating a given
    2164    request message with its corresponding one or more response messages.
    2165    Hence, it relies on the order of response arrival to correspond exactly
    2166    to the order in which requests are made on the same connection.
    2167    More than one response message per request only occurs when one or more
    2168    informational responses (1xx, see &status-1xx;) precede a final response
    2169    to the same request.
    2170 </t>
    2171 <t>
    2172    A client that uses persistent connections and sends more than one request
    2173    per connection &MUST; maintain a list of outstanding requests in the
    2174    order sent on that connection and &MUST; associate each received response
    2175    message to the highest ordered request that has not yet received a final
    2176    (non-1xx) response.
    2177 </t>
    2178 </section>
    2179 </section>
    2180 
    21811921<section title="Transfer Codings" anchor="transfer.codings">
    21821922  <x:anchor-alias value="transfer-coding"/>
     
    25492289    <t>Trailer</t>
    25502290  </list>
     2291</t>
     2292</section>
     2293</section>
     2294
     2295<section title="Message Routing" anchor="message.routing">
     2296<t>
     2297   In most cases, the user agent is provided a URI reference
     2298   from which it determines an absolute URI for identifying the target
     2299   resource.  When a request to the resource is initiated, all or part
     2300   of that URI is used to construct the HTTP request-target.
     2301</t>
     2302
     2303<section title="Types of Request Target" anchor="request-target-types">
     2304<t>
     2305   The proper format choice of the four options available to request-target
     2306   depends on the method being requested and if the request is being made to
     2307   a proxy.
     2308</t>   
     2309<t anchor="origin-form"><iref item="origin form (of request-target)"/>
     2310   The most common form of request-target is that used when making
     2311   a request to an origin server ("origin form") to access a resource
     2312   identified by an "http" (<xref target="http.uri"/>) or
     2313   "https" (<xref target="https.uri"/>) URI.
     2314   In this case, the absolute path and query components of the URI
     2315   &MUST; be transmitted as the request-target and the authority component
     2316   (excluding any userinfo) &MUST; be transmitted in a Host header field.
     2317   For example, a client wishing to retrieve a representation of the resource
     2318   identified as
     2319</t>
     2320<figure><artwork x:indent-with="  ">
     2321http://www.example.org/where?q=now
     2322</artwork></figure>
     2323<t>
     2324   directly from the origin server would open (or reuse) a TCP connection
     2325   to port 80 of the host "www.example.org" and send the lines:
     2326</t>
     2327<figure><artwork type="message/http; msgtype=&#34;request&#34;" x:indent-with="  ">
     2328GET /where?q=now HTTP/1.1
     2329Host: www.example.org
     2330</artwork></figure>
     2331<t>
     2332   followed by the remainder of the request. Note that the origin form
     2333   of request-target always starts with an absolute path. If the target
     2334   resource's URI path is empty, then an absolute path of "/" &MUST; be
     2335   provided in the request-target.
     2336</t>
     2337<t>
     2338   If the request-target is percent-encoded
     2339   (<xref target="RFC3986" x:fmt="," x:sec="2.1"/>), the origin server
     2340   &MUST; decode the request-target in order to
     2341   properly interpret the request. Servers &SHOULD; respond to invalid
     2342   request-targets with an appropriate status code.
     2343</t>
     2344<t anchor="absolute-URI-form"><iref item="absolute-URI form (of request-target)"/>
     2345   The "absolute-URI" form of request-target is &REQUIRED; when the request
     2346   is being made to a proxy.  The proxy is requested to either forward the
     2347   request or service it from a valid cache, and then return the response.
     2348   Note that the proxy &MAY; forward the request on to another proxy or
     2349   directly to the server specified by the absolute-URI.
     2350   In order to avoid request loops, a proxy that forwards requests to other
     2351   proxies &MUST; be able to recognize and exclude all of its own server
     2352   names, including any aliases, local variations, or literal IP addresses.
     2353   An example request-line would be:
     2354</t>
     2355<figure><artwork type="message/http; msgtype=&#34;request&#34;" x:indent-with="  ">
     2356GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1
     2357</artwork></figure>
     2358<t>
     2359   To allow for transition to absolute-URIs in all requests in future
     2360   versions of HTTP, all HTTP/1.1 servers &MUST; accept the absolute-URI
     2361   form in requests, even though HTTP/1.1 clients will only generate
     2362   them in requests to proxies.
     2363</t>
     2364<t>
     2365   If a proxy receives a host name that is not a fully qualified domain
     2366   name, it &MAY; add its domain to the host name it received. If a proxy
     2367   receives a fully qualified domain name, the proxy &MUST-NOT; change
     2368   the host name.
     2369</t>
     2370<t anchor="authority-form"><iref item="authority form (of request-target)"/>
     2371   The "authority form" of request-target, which &MUST-NOT; be used
     2372   with any request method other than CONNECT, is used to establish a
     2373   tunnel through one or more proxies (&CONNECT;).  For example,
     2374</t>
     2375<figure><artwork type="message/http; msgtype=&#34;request&#34;" x:indent-with="  ">
     2376CONNECT www.example.com:80 HTTP/1.1
     2377</artwork></figure>
     2378<t anchor="asterix-form"><iref item="asterisk form (of request-target)"/>
     2379   The asterisk ("*") form of request-target, which &MUST-NOT; be used
     2380   with any request method other than OPTIONS, means that the request
     2381   applies to the server as a whole (the listening process) rather than
     2382   to a specific named resource at that server.  For example,
     2383</t>
     2384<figure><artwork type="message/http; msgtype=&#34;request&#34;" x:indent-with="  ">
     2385OPTIONS * HTTP/1.1
     2386</artwork></figure>
     2387<t>
     2388   If a proxy receives an OPTIONS request with an absolute-URI form of
     2389   request-target in which the URI has an empty path and no query component,
     2390   then the last proxy on the request chain &MUST; use a request-target
     2391   of "*" when it forwards the request to the indicated origin server.
     2392</t>
     2393<figure><preamble>   
     2394   For example, the request
     2395</preamble><artwork type="message/http; msgtype=&#34;request&#34;" x:indent-with="  ">
     2396OPTIONS http://www.example.org:8001 HTTP/1.1
     2397</artwork></figure>
     2398<figure><preamble>   
     2399  would be forwarded by the final proxy as
     2400</preamble><artwork type="message/http; msgtype=&#34;request&#34;" x:indent-with="  ">
     2401OPTIONS * HTTP/1.1
     2402Host: www.example.org:8001
     2403</artwork>
     2404<postamble>
     2405   after connecting to port 8001 of host "www.example.org".
     2406</postamble>
     2407</figure>
     2408<t>
     2409   A non-transforming proxy &MUST-NOT; rewrite the "path-absolute" and "query"
     2410   parts of the received request-target when forwarding it to the next inbound
     2411   server, except as noted above to replace a null path-absolute with "/" or
     2412   "*".
     2413</t>
     2414</section>
     2415
     2416<section title="The Resource Identified by a Request" anchor="the.resource.identified.by.a.request">
     2417<t>
     2418   The exact resource identified by an Internet request is determined by
     2419   examining both the request-target and the Host header field.
     2420</t>
     2421<t>
     2422   An origin server that does not allow resources to differ by the
     2423   requested host &MAY; ignore the Host header field value when
     2424   determining the resource identified by an HTTP/1.1 request. (But see
     2425   <xref target="changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses"/>
     2426   for other requirements on Host support in HTTP/1.1.)
     2427</t>
     2428<t>
     2429   An origin server that does differentiate resources based on the host
     2430   requested (sometimes referred to as virtual hosts or vanity host
     2431   names) &MUST; use the following rules for determining the requested
     2432   resource on an HTTP/1.1 request:
     2433  <list style="numbers">
     2434    <t>If request-target is an absolute-URI, the host is part of the
     2435     request-target. Any Host header field value in the request &MUST; be
     2436     ignored.</t>
     2437    <t>If the request-target is not an absolute-URI, and the request includes
     2438     a Host header field, the host is determined by the Host header
     2439     field value.</t>
     2440    <t>If the host as determined by rule 1 or 2 is not a valid host on
     2441     the server, the response &MUST; be a 400 (Bad Request) error message.</t>
     2442  </list>
     2443</t>
     2444<t>
     2445   Recipients of an HTTP/1.0 request that lacks a Host header field &MAY;
     2446   attempt to use heuristics (e.g., examination of the URI path for
     2447   something unique to a particular host) in order to determine what
     2448   exact resource is being requested.
     2449</t>
     2450</section>
     2451
     2452<section title="Effective Request URI" anchor="effective.request.uri">
     2453  <iref primary="true" item="effective request URI"/>
     2454  <iref primary="true" item="target resource"/>
     2455<t>
     2456   HTTP requests often do not carry the absolute URI (<xref target="RFC3986" x:fmt="," x:sec="4.3"/>)
     2457   for the target resource; instead, the URI needs to be inferred from the
     2458   request-target, Host header field, and connection context. The result of
     2459   this process is called the "effective request URI".  The "target resource"
     2460   is the resource identified by the effective request URI.
     2461</t>
     2462<t>
     2463   If the request-target is an absolute-URI, then the effective request URI is
     2464   the request-target.
     2465</t>
     2466<t>
     2467   If the request-target uses the origin form or the asterisk form,
     2468   and the Host header field is present, then the effective request URI is
     2469   constructed by concatenating
     2470</t>
     2471<t>
     2472  <list style="symbols">
     2473    <t>
     2474      the scheme name: "http" if the request was received over an insecure
     2475      TCP connection, or "https" when received over a SSL/TLS-secured TCP
     2476      connection,
     2477    </t>
     2478    <t>
     2479      the octet sequence "://",
     2480    </t>
     2481    <t>
     2482      the authority component, as specified in the Host header field
     2483      (<xref target="header.host"/>), and
     2484    </t>
     2485    <t>
     2486      the request-target obtained from the request-line, unless the
     2487      request-target is just the asterisk "*".
     2488    </t>
     2489  </list>
     2490</t>
     2491<t>
     2492   If the request-target uses the origin form or the asterisk form,
     2493   and the Host header field is not present, then the effective request URI is
     2494   undefined.
     2495</t>
     2496<t>
     2497   Otherwise, when request-target uses the authority form, the effective
     2498   request URI is undefined.
     2499</t>
     2500<figure>
     2501<preamble>
     2502   Example 1: the effective request URI for the message
     2503</preamble>
     2504<artwork type="example" x:indent-with="  ">
     2505GET /pub/WWW/TheProject.html HTTP/1.1
     2506Host: www.example.org:8080
     2507</artwork>
     2508<postamble>
     2509  (received over an insecure TCP connection) is "http", plus "://", plus the
     2510  authority component "www.example.org:8080", plus the request-target
     2511  "/pub/WWW/TheProject.html", thus
     2512  "http://www.example.org:8080/pub/WWW/TheProject.html".
     2513</postamble>
     2514</figure>
     2515<figure>
     2516<preamble>
     2517   Example 2: the effective request URI for the message
     2518</preamble>
     2519<artwork type="example" x:indent-with="  ">
     2520OPTIONS * HTTP/1.1
     2521Host: www.example.org
     2522</artwork>
     2523<postamble>
     2524  (received over an SSL/TLS secured TCP connection) is "https", plus "://", plus the
     2525  authority component "www.example.org", thus "https://www.example.org".
     2526</postamble>
     2527</figure>
     2528<t>
     2529   Effective request URIs are compared using the rules described in
     2530   <xref target="uri.comparison"/>, except that empty path components &MUST-NOT;
     2531   be treated as equivalent to an absolute path of "/".
     2532</t> 
     2533</section>
     2534
     2535<section title="Associating a Response to a Request" anchor="associating.response.to.request">
     2536<t>
     2537   HTTP does not include a request identifier for associating a given
     2538   request message with its corresponding one or more response messages.
     2539   Hence, it relies on the order of response arrival to correspond exactly
     2540   to the order in which requests are made on the same connection.
     2541   More than one response message per request only occurs when one or more
     2542   informational responses (1xx, see &status-1xx;) precede a final response
     2543   to the same request.
     2544</t>
     2545<t>
     2546   A client that uses persistent connections and sends more than one request
     2547   per connection &MUST; maintain a list of outstanding requests in the
     2548   order sent on that connection and &MUST; associate each received response
     2549   message to the highest ordered request that has not yet received a final
     2550   (non-1xx) response.
    25512551</t>
    25522552</section>
Note: See TracChangeset for help on using the changeset viewer.