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

Timestamp:

10/03/12 11:07:51 (10 years ago)

Author:

fielding@…

Message:

Move Host header field to Message Routing

File:

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

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

@@ -2471 +2471 @@
 </section>
 
+<section title="Host" anchor="header.host">
+  <iref primary="true" item="Host header field" x:for-anchor=""/>
+  <iref primary="true" item="Header Fields" subitem="Host" x:for-anchor=""/>
+  <x:anchor-alias value="Host"/>
+<t>
+   The "Host" header field in a request provides the host and port
+   information from the target resource's URI, enabling the origin
+   server to distinguish between resources while servicing requests
+   for multiple host names on a single IP address.  Since the Host
+   field-value is critical information for handling a request, it
+   &SHOULD; be sent as the first header field following the request-line.
+</t>
+<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Host"/>
+  <x:ref>Host</x:ref> = <x:ref>uri-host</x:ref> [ ":" <x:ref>port</x:ref> ] ; <xref target="http.uri"/>
+</artwork></figure>
+<t>
+   A client &MUST; send a Host header field in all HTTP/1.1 request
+   messages.  If the target resource's URI includes an authority
+   component, then the Host field-value &MUST; be identical to that
+   authority component after excluding any userinfo (<xref target="http.uri"/>).
+   If the authority component is missing or undefined for the target
+   resource's URI, then the Host header field &MUST; be sent with an
+   empty field-value.
+</t>
+<t>
+   For example, a GET request to the origin server for
+   &lt;http://www.example.org/pub/WWW/&gt; would begin with:
+</t>
+<figure><artwork type="message/http; msgtype=&#34;request&#34;" x:indent-with="  ">
+GET /pub/WWW/ HTTP/1.1
+Host: www.example.org
+</artwork></figure>
+<t>
+   The Host header field &MUST; be sent in an HTTP/1.1 request even
+   if the request-target is in the form of an absolute-URI, since this
+   allows the Host information to be forwarded through ancient HTTP/1.0
+   proxies that might not have implemented Host.
+</t>
+<t>
+   When an HTTP/1.1 proxy receives a request with a request-target in
+   the form of an absolute-URI, the proxy &MUST; ignore the received
+   Host header field (if any) and instead replace it with the host
+   information of the request-target.  When a proxy forwards a request,
+   it &MUST; generate the Host header field based on the received
+   absolute-URI rather than the received Host.
+</t>
+<t>
+   Since the Host header field acts as an application-level routing
+   mechanism, it is a frequent target for malware seeking to poison
+   a shared cache or redirect a request to an unintended server.
+   An interception proxy is particularly vulnerable if it relies on
+   the Host header field value for redirecting requests to internal
+   servers, or for use as a cache key in a shared cache, without
+   first verifying that the intercepted connection is targeting a
+   valid IP address for that host.
+</t>
+<t>
+   A server &MUST; respond with a 400 (Bad Request) status code to
+   any HTTP/1.1 request message that lacks a Host header field and
+   to any request message that contains more than one Host header field
+   or a Host header field with an invalid field-value.
+</t>
+<t>
+   See Sections <xref target="the.resource.identified.by.a.request" format="counter"/>
+   and <xref target="changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" format="counter"/>
+   for other requirements relating to Host.
+</t>
+</section>
+
 <section title="The Resource Identified by a Request" anchor="the.resource.identified.by.a.request">
 <t>
@@ -3230 +3299 @@
    include the "close" connection option in every response message that
    does not have a 1xx (Informational) status code.
-</t>
-</section>
-
-<section title="Host" anchor="header.host">
-  <iref primary="true" item="Host header field" x:for-anchor=""/>
-  <iref primary="true" item="Header Fields" subitem="Host" x:for-anchor=""/>
-  <x:anchor-alias value="Host"/>
-<t>
-   The "Host" header field in a request provides the host and port
-   information from the target resource's URI, enabling the origin
-   server to distinguish between resources while servicing requests
-   for multiple host names on a single IP address.  Since the Host
-   field-value is critical information for handling a request, it
-   &SHOULD; be sent as the first header field following the request-line.
-</t>
-<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Host"/>
-  <x:ref>Host</x:ref> = <x:ref>uri-host</x:ref> [ ":" <x:ref>port</x:ref> ] ; <xref target="http.uri"/>
-</artwork></figure>
-<t>
-   A client &MUST; send a Host header field in all HTTP/1.1 request
-   messages.  If the target resource's URI includes an authority
-   component, then the Host field-value &MUST; be identical to that
-   authority component after excluding any userinfo (<xref target="http.uri"/>).
-   If the authority component is missing or undefined for the target
-   resource's URI, then the Host header field &MUST; be sent with an
-   empty field-value.
-</t>
-<t>
-   For example, a GET request to the origin server for
-   &lt;http://www.example.org/pub/WWW/&gt; would begin with:
-</t>
-<figure><artwork type="message/http; msgtype=&#34;request&#34;" x:indent-with="  ">
-GET /pub/WWW/ HTTP/1.1
-Host: www.example.org
-</artwork></figure>
-<t>
-   The Host header field &MUST; be sent in an HTTP/1.1 request even
-   if the request-target is in the form of an absolute-URI, since this
-   allows the Host information to be forwarded through ancient HTTP/1.0
-   proxies that might not have implemented Host.
-</t>
-<t>
-   When an HTTP/1.1 proxy receives a request with a request-target in
-   the form of an absolute-URI, the proxy &MUST; ignore the received
-   Host header field (if any) and instead replace it with the host
-   information of the request-target.  When a proxy forwards a request,
-   it &MUST; generate the Host header field based on the received
-   absolute-URI rather than the received Host.
-</t>
-<t>
-   Since the Host header field acts as an application-level routing
-   mechanism, it is a frequent target for malware seeking to poison
-   a shared cache or redirect a request to an unintended server.
-   An interception proxy is particularly vulnerable if it relies on
-   the Host header field value for redirecting requests to internal
-   servers, or for use as a cache key in a shared cache, without
-   first verifying that the intercepted connection is targeting a
-   valid IP address for that host.
-</t>
-<t>
-   A server &MUST; respond with a 400 (Bad Request) status code to
-   any HTTP/1.1 request message that lacks a Host header field and
-   to any request message that contains more than one Host header field
-   or a Host header field with an invalid field-value.
-</t>
-<t>
-   See Sections <xref target="the.resource.identified.by.a.request" format="counter"/>
-   and <xref target="changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" format="counter"/>
-   for other requirements relating to Host.
 </t>
 </section>