Changeset 1576 for draft-ietf-httpbis/latest/p1-messaging.xml
- Timestamp:
- 10/03/12 11:07:51 (10 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.xml
r1575 r1576 2471 2471 </section> 2472 2472 2473 <section title="Host" anchor="header.host"> 2474 <iref primary="true" item="Host header field" x:for-anchor=""/> 2475 <iref primary="true" item="Header Fields" subitem="Host" x:for-anchor=""/> 2476 <x:anchor-alias value="Host"/> 2477 <t> 2478 The "Host" header field in a request provides the host and port 2479 information from the target resource's URI, enabling the origin 2480 server to distinguish between resources while servicing requests 2481 for multiple host names on a single IP address. Since the Host 2482 field-value is critical information for handling a request, it 2483 &SHOULD; be sent as the first header field following the request-line. 2484 </t> 2485 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Host"/> 2486 <x:ref>Host</x:ref> = <x:ref>uri-host</x:ref> [ ":" <x:ref>port</x:ref> ] ; <xref target="http.uri"/> 2487 </artwork></figure> 2488 <t> 2489 A client &MUST; send a Host header field in all HTTP/1.1 request 2490 messages. If the target resource's URI includes an authority 2491 component, then the Host field-value &MUST; be identical to that 2492 authority component after excluding any userinfo (<xref target="http.uri"/>). 2493 If the authority component is missing or undefined for the target 2494 resource's URI, then the Host header field &MUST; be sent with an 2495 empty field-value. 2496 </t> 2497 <t> 2498 For example, a GET request to the origin server for 2499 <http://www.example.org/pub/WWW/> would begin with: 2500 </t> 2501 <figure><artwork type="message/http; msgtype="request"" x:indent-with=" "> 2502 GET /pub/WWW/ HTTP/1.1 2503 Host: www.example.org 2504 </artwork></figure> 2505 <t> 2506 The Host header field &MUST; be sent in an HTTP/1.1 request even 2507 if the request-target is in the form of an absolute-URI, since this 2508 allows the Host information to be forwarded through ancient HTTP/1.0 2509 proxies that might not have implemented Host. 2510 </t> 2511 <t> 2512 When an HTTP/1.1 proxy receives a request with a request-target in 2513 the form of an absolute-URI, the proxy &MUST; ignore the received 2514 Host header field (if any) and instead replace it with the host 2515 information of the request-target. When a proxy forwards a request, 2516 it &MUST; generate the Host header field based on the received 2517 absolute-URI rather than the received Host. 2518 </t> 2519 <t> 2520 Since the Host header field acts as an application-level routing 2521 mechanism, it is a frequent target for malware seeking to poison 2522 a shared cache or redirect a request to an unintended server. 2523 An interception proxy is particularly vulnerable if it relies on 2524 the Host header field value for redirecting requests to internal 2525 servers, or for use as a cache key in a shared cache, without 2526 first verifying that the intercepted connection is targeting a 2527 valid IP address for that host. 2528 </t> 2529 <t> 2530 A server &MUST; respond with a 400 (Bad Request) status code to 2531 any HTTP/1.1 request message that lacks a Host header field and 2532 to any request message that contains more than one Host header field 2533 or a Host header field with an invalid field-value. 2534 </t> 2535 <t> 2536 See Sections <xref target="the.resource.identified.by.a.request" format="counter"/> 2537 and <xref target="changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" format="counter"/> 2538 for other requirements relating to Host. 2539 </t> 2540 </section> 2541 2473 2542 <section title="The Resource Identified by a Request" anchor="the.resource.identified.by.a.request"> 2474 2543 <t> … … 3230 3299 include the "close" connection option in every response message that 3231 3300 does not have a 1xx (Informational) status code. 3232 </t>3233 </section>3234 3235 <section title="Host" anchor="header.host">3236 <iref primary="true" item="Host header field" x:for-anchor=""/>3237 <iref primary="true" item="Header Fields" subitem="Host" x:for-anchor=""/>3238 <x:anchor-alias value="Host"/>3239 <t>3240 The "Host" header field in a request provides the host and port3241 information from the target resource's URI, enabling the origin3242 server to distinguish between resources while servicing requests3243 for multiple host names on a single IP address. Since the Host3244 field-value is critical information for handling a request, it3245 &SHOULD; be sent as the first header field following the request-line.3246 </t>3247 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Host"/>3248 <x:ref>Host</x:ref> = <x:ref>uri-host</x:ref> [ ":" <x:ref>port</x:ref> ] ; <xref target="http.uri"/>3249 </artwork></figure>3250 <t>3251 A client &MUST; send a Host header field in all HTTP/1.1 request3252 messages. If the target resource's URI includes an authority3253 component, then the Host field-value &MUST; be identical to that3254 authority component after excluding any userinfo (<xref target="http.uri"/>).3255 If the authority component is missing or undefined for the target3256 resource's URI, then the Host header field &MUST; be sent with an3257 empty field-value.3258 </t>3259 <t>3260 For example, a GET request to the origin server for3261 <http://www.example.org/pub/WWW/> would begin with:3262 </t>3263 <figure><artwork type="message/http; msgtype="request"" x:indent-with=" ">3264 GET /pub/WWW/ HTTP/1.13265 Host: www.example.org3266 </artwork></figure>3267 <t>3268 The Host header field &MUST; be sent in an HTTP/1.1 request even3269 if the request-target is in the form of an absolute-URI, since this3270 allows the Host information to be forwarded through ancient HTTP/1.03271 proxies that might not have implemented Host.3272 </t>3273 <t>3274 When an HTTP/1.1 proxy receives a request with a request-target in3275 the form of an absolute-URI, the proxy &MUST; ignore the received3276 Host header field (if any) and instead replace it with the host3277 information of the request-target. When a proxy forwards a request,3278 it &MUST; generate the Host header field based on the received3279 absolute-URI rather than the received Host.3280 </t>3281 <t>3282 Since the Host header field acts as an application-level routing3283 mechanism, it is a frequent target for malware seeking to poison3284 a shared cache or redirect a request to an unintended server.3285 An interception proxy is particularly vulnerable if it relies on3286 the Host header field value for redirecting requests to internal3287 servers, or for use as a cache key in a shared cache, without3288 first verifying that the intercepted connection is targeting a3289 valid IP address for that host.3290 </t>3291 <t>3292 A server &MUST; respond with a 400 (Bad Request) status code to3293 any HTTP/1.1 request message that lacks a Host header field and3294 to any request message that contains more than one Host header field3295 or a Host header field with an invalid field-value.3296 </t>3297 <t>3298 See Sections <xref target="the.resource.identified.by.a.request" format="counter"/>3299 and <xref target="changes.to.simplify.multi-homed.web.servers.and.conserve.ip.addresses" format="counter"/>3300 for other requirements relating to Host.3301 3301 </t> 3302 3302 </section>
Note: See TracChangeset
for help on using the changeset viewer.