Changeset 1173
- Timestamp:
- 13/03/11 11:39:25 (12 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 4 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.xml
r1171 r1173 710 710 requests to the underlying server's protocol. Gateways are often 711 711 used for load balancing, "accelerator" caching, or partitioning 712 HTTP services across multiple machines. 713 Unlike a proxy, a gateway receives requests as if it were the 714 origin server for the target resource; the requesting client 715 will not be aware that it is communicating with a gateway. 716 A gateway communicates with the client as if the gateway is the 717 origin server and thus is subject to all of the requirements on 718 origin servers for that connection. A gateway communicates 719 with inbound servers using any protocol it desires, including 720 private extensions to HTTP that are outside the scope of this 721 specification. 712 HTTP services across multiple machines. Gateways behave as an origin 713 server on the outbound connection and as a proxy on the inbound 714 connection. All HTTP requirements applicable to an origin server 715 also apply to the outbound communication of a gateway. A gateway 716 communicates with inbound servers using any protocol it desires, 717 including private extensions to HTTP that are outside the scope of 718 this specification. However, an HTTP-to-HTTP gateway that wishes 719 to interoperate with third-party HTTP servers &SHOULD; comply with 720 HTTP proxy requirements on the gateway's inbound connection. 722 721 </t> 723 722 <t><iref primary="true" item="tunnel"/> … … 1430 1429 If this is a request message, the server &MUST; respond with 1431 1430 a 400 (Bad Request) status code and then close the connection. 1432 If this is a response message received by a proxy or gateway, the proxy1433 or gateway&MUST; discard the received response, send a 502 (Bad Gateway)1431 If this is a response message received by a proxy, the proxy 1432 &MUST; discard the received response, send a 502 (Bad Gateway) 1434 1433 status code as its downstream response, and then close the connection. 1435 1434 If this is a response message received by a user-agent, it &MUST; be … … 1634 1633 <t><iref item="origin form (of request-target)"/> 1635 1634 The most common form of request-target is that used when making 1636 a request to an origin server or gateway("origin form").1635 a request to an origin server ("origin form"). 1637 1636 In this case, the absolute path and query components of the URI 1638 1637 &MUST; be transmitted as the request-target, and the authority component … … 2385 2384 <t> 2386 2385 Prior to persistent connections, a separate TCP connection was 2387 established to fetch each URL, increasing the load on HTTP servers2386 established for each request, increasing the load on HTTP servers 2388 2387 and causing congestion on the Internet. The use of inline images and 2389 2388 other associated data often requires a client to make multiple … … 3094 3093 A received message that does not have a Date header field &MUST; be 3095 3094 assigned one by the recipient if the message will be cached by that 3096 recipient or gatewayed via a protocol which requires a Date.3095 recipient. 3097 3096 </t> 3098 3097 <t> … … 3133 3132 <x:anchor-alias value="Host-v"/> 3134 3133 <t> 3135 The "Host" header field specifies the Internet host and port 3136 number of the resource being requested, allowing the origin server or 3137 gateway to differentiate between internally-ambiguous URLs, such as the root 3138 "/" URL of a server for multiple host names on a single IP address. 3139 </t> 3140 <t> 3141 The Host field value &MUST; represent the naming authority of the origin 3142 server or gateway given by the original URL obtained from the user or 3143 referring resource (generally an http URI, as described in 3144 <xref target="http.uri"/>). 3134 The "Host" header field in a request provides the host and port 3135 information from the target resource's URI, enabling the origin 3136 server to distinguish between resources while servicing requests 3137 for multiple host names on a single IP address. Since the Host 3138 field-value is critical information for handling a request, it 3139 &SHOULD; be sent as the first header field following the Request-Line. 3145 3140 </t> 3146 3141 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Host"/><iref primary="true" item="Grammar" subitem="Host-v"/> … … 3149 3144 </artwork></figure> 3150 3145 <t> 3151 A "host" without any trailing port information implies the default 3152 port for the service requested (e.g., "80" for an HTTP URL). For 3153 example, a request on the origin server for 3154 <http://www.example.org/pub/WWW/> would properly include: 3146 A client &MUST; send a Host header field in all HTTP/1.1 request 3147 messages. If the target resource's URI includes an authority 3148 component, then the Host field-value &MUST; be identical to that 3149 authority component after excluding any userinfo (<xref target="http.uri"/>). 3150 If the authority component is missing or undefined for the target 3151 resource's URI, then the Host header field &MUST; be sent with an 3152 empty field-value. 3153 </t> 3154 <t> 3155 For example, a GET request to the origin server for 3156 <http://www.example.org/pub/WWW/> would begin with: 3155 3157 </t> 3156 3158 <figure><artwork type="message/http; msgtype="request"" x:indent-with=" "> … … 3159 3161 </artwork></figure> 3160 3162 <t> 3161 A client &MUST; include a Host header field in all HTTP/1.1 request 3162 messages. If the requested URI does not include an Internet host 3163 name for the service being requested, then the Host header field &MUST; 3164 be given with an empty value. An HTTP/1.1 proxy &MUST; ensure that any 3165 request message it forwards does contain an appropriate Host header 3166 field that identifies the service being requested by the proxy. All 3167 Internet-based HTTP/1.1 servers &MUST; respond with a 400 (Bad Request) 3168 status code to any HTTP/1.1 request message which lacks a Host header 3169 field. 3163 The Host header field &MUST; be sent in an HTTP/1.1 request even 3164 if the request-target is in the form of an absolute-URI, since this 3165 allows the Host information to be forwarded through ancient HTTP/1.0 3166 proxies that might not have implemented Host. 3167 </t> 3168 <t> 3169 When an HTTP/1.1 proxy receives a request with a request-target in 3170 the form of an absolute-URI, the proxy &MUST; ignore the received 3171 Host header field (if any) and instead replace it with the host 3172 information of the request-target. When a proxy forwards a request, 3173 it &MUST; generate the Host header field based on the received 3174 absolute-URI rather than the received Host. 3175 </t> 3176 <t> 3177 Since the Host header field acts as an application-level routing 3178 mechanism, it is a frequent target for malware seeking to poison 3179 a shared cache or redirect a request to an unintended server. 3180 An interception proxy is particularly vulnerable if it relies on 3181 the Host header field value for redirecting requests to internal 3182 servers, or for use as a cache key in a shared cache, without 3183 first verifying that the intercepted connection is targeting a 3184 valid IP address for that host. 3185 </t> 3186 <t> 3187 A server &MUST; respond with a 400 (Bad Request) status code to 3188 any HTTP/1.1 request message that lacks a Host header field and 3189 to any request message that contains more than one Host header field 3190 or a Host header field with an invalid field-value. 3170 3191 </t> 3171 3192 <t> … … 3449 3470 <x:anchor-alias value="Via-v"/> 3450 3471 <t> 3451 The "Via" header field &MUST; be used by gateways andproxies to3472 The "Via" header field &MUST; be sent by proxies to 3452 3473 indicate the intermediate protocols and recipients between the user 3453 3474 agent and the server on requests, and between the origin server and … … 3484 3505 </t> 3485 3506 <t> 3486 Multiple Via field values represent each proxy or gatewaythat has3507 Multiple Via field values represent each proxy that has 3487 3508 forwarded the message. Each recipient &MUST; append its information 3488 3509 such that the end result is ordered according to the sequence of … … 3491 3512 <t> 3492 3513 Comments &MAY; be used in the Via header field to identify the software 3493 of the recipient proxy or gateway, analogous to the User-Agent and3514 of the recipient proxy, analogous to the User-Agent and 3494 3515 Server header fields. However, all comments in the Via field are 3495 3516 optional and &MAY; be removed by any recipient prior to forwarding the … … 3508 3529 </artwork></figure> 3509 3530 <t> 3510 Proxies and gatewaysused as a portal through a network firewall3531 Proxies used as a portal through a network firewall 3511 3532 &SHOULD-NOT;, by default, forward the names and ports of hosts within 3512 3533 the firewall region. This information &SHOULD; only be propagated if … … 4917 4938 Internet will also be able to recover the IP addresses that have been 4918 4939 allocated for the sole purpose of allowing special-purpose domain 4919 names to be used in root-level HTTP URLs. Given the rate of growth of4940 names to be used. Given the rate of growth of 4920 4941 the Web, and the number of servers already deployed, it is extremely 4921 4942 important that all implementations of HTTP (including updates to -
draft-ietf-httpbis/latest/p2-semantics.xml
r1168 r1173 1133 1133 &SHOULD; reflect the message received back to the client as the 1134 1134 message-body of a 200 (OK) response. The final recipient is either the 1135 origin server or the first proxy or gatewayto receive a Max-Forwards1135 origin server or the first proxy to receive a Max-Forwards 1136 1136 value of zero (0) in the request (see <xref target="header.max-forwards"/>). 1137 1137 A TRACE request &MUST-NOT; include a message-body. … … 2302 2302 TRACE (<xref target="TRACE"/>) and OPTIONS (<xref target="OPTIONS"/>) 2303 2303 methods to limit the number of times that the request is forwarded by 2304 proxies or gateways. This can be useful when the client is attempting to2304 proxies. This can be useful when the client is attempting to 2305 2305 trace a request which appears to be failing or looping in mid-chain. 2306 2306 </t> … … 2314 2314 </t> 2315 2315 <t> 2316 Each proxy or gatewayrecipient of a TRACE or OPTIONS request2316 Each recipient of a TRACE or OPTIONS request 2317 2317 containing a Max-Forwards header field &MUST; check and update its 2318 2318 value prior to forwarding the request. If the received value is zero -
draft-ietf-httpbis/latest/p3-payload.xml
r1167 r1173 1507 1507 client to function as an integrity check of the payload body. Only 1508 1508 origin servers or user agents &MAY; generate the Content-MD5 header field; 1509 proxies and gateways&MUST-NOT; generate it, as this would defeat its1509 proxies &MUST-NOT; generate it, as this would defeat its 1510 1510 value as an end-to-end integrity check. Any recipient &MAY; check that 1511 1511 the digest value in this header field matches a corresponding digest -
draft-ietf-httpbis/latest/p6-cache.xml
r1166 r1173 679 679 <x:h>Note:</x:h> RFC 2616 (<xref target="RFC2616" x:fmt="," 680 680 x:sec="13.9"/>) required that caches do not calculate heuristic 681 freshness for UR Ls with query components (i.e., those containing '?').681 freshness for URIs with query components (i.e., those containing '?'). 682 682 In practice, this has not been widely implemented. Therefore, servers 683 683 are encouraged to send explicit directives (e.g., Cache-Control: … … 1100 1100 </x:note> 1101 1101 <t> 1102 A n intermediary (i.e., a proxy or gateway, whether or not it implements1103 a cache) &MUST; pass cache directives through, regardless of their1102 A proxy, whether or not it implements a cache, &MUST; pass cache directives 1103 through in forwarded messages, regardless of their 1104 1104 significance to that application, since the directives might be applicable 1105 1105 to all recipients along the request/response chain. It is not possible to
Note: See TracChangeset
for help on using the changeset viewer.