Changeset 1173


Ignore:
Timestamp:
Mar 13, 2011, 4:39:25 AM (8 years ago)
Author:
fielding@…
Message:

Clarify that gateways are just origin servers with additional
proxy issues and then refer only to origin servers when
describing their outbound requirements.

Consistently use the term URI instead of URL.

Rewrite the section on Host to be clear on where the information
comes from and how proxies differ from other clients.
Warn about security holes in stupid interception proxies.

Addresses #218

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

Legend:

Unmodified
Added
Removed

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

    r1171 r1173  
    710710   requests to the underlying server's protocol.  Gateways are often
    711711   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.
    722721</t>
    723722<t><iref primary="true" item="tunnel"/>
    … …  
    14301429     If this is a request message, the server &MUST; respond with
    14311430     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 proxy
    1433      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)
    14341433     status code as its downstream response, and then close the connection.
    14351434     If this is a response message received by a user-agent, it &MUST; be
    … …  
    16341633<t><iref item="origin form (of request-target)"/>
    16351634   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").
    16371636   In this case, the absolute path and query components of the URI
    16381637   &MUST; be transmitted as the request-target, and the authority component
    … …  
    23852384<t>
    23862385   Prior to persistent connections, a separate TCP connection was
    2387    established to fetch each URL, increasing the load on HTTP servers
     2386   established for each request, increasing the load on HTTP servers
    23882387   and causing congestion on the Internet. The use of inline images and
    23892388   other associated data often requires a client to make multiple
    … …  
    30943093   A received message that does not have a Date header field &MUST; be
    30953094   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.
    30973096</t>
    30983097<t>
    … …  
    31333132  <x:anchor-alias value="Host-v"/>
    31343133<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.
    31453140</t>
    31463141<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Host"/><iref primary="true" item="Grammar" subitem="Host-v"/>
    … …  
    31493144</artwork></figure>
    31503145<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    &lt;http://www.example.org/pub/WWW/&gt; 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   &lt;http://www.example.org/pub/WWW/&gt; would begin with:
    31553157</t>
    31563158<figure><artwork type="message/http; msgtype=&#34;request&#34;" x:indent-with="  ">
    … …  
    31593161</artwork></figure>
    31603162<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.
    31703191</t>
    31713192<t>
    … …  
    34493470  <x:anchor-alias value="Via-v"/>
    34503471<t>
    3451    The "Via" header field &MUST; be used by gateways and proxies to
     3472   The "Via" header field &MUST; be sent by proxies to
    34523473   indicate the intermediate protocols and recipients between the user
    34533474   agent and the server on requests, and between the origin server and
    … …  
    34843505</t>
    34853506<t>
    3486    Multiple Via field values represent each proxy or gateway that has
     3507   Multiple Via field values represent each proxy that has
    34873508   forwarded the message. Each recipient &MUST; append its information
    34883509   such that the end result is ordered according to the sequence of
    … …  
    34913512<t>
    34923513   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 and
     3514   of the recipient proxy, analogous to the User-Agent and
    34943515   Server header fields. However, all comments in the Via field are
    34953516   optional and &MAY; be removed by any recipient prior to forwarding the
    … …  
    35083529</artwork></figure>
    35093530<t>
    3510    Proxies and gateways used as a portal through a network firewall
     3531   Proxies used as a portal through a network firewall
    35113532   &SHOULD-NOT;, by default, forward the names and ports of hosts within
    35123533   the firewall region. This information &SHOULD; only be propagated if
    … …  
    49174938   Internet will also be able to recover the IP addresses that have been
    49184939   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 of
     4940   names to be used. Given the rate of growth of
    49204941   the Web, and the number of servers already deployed, it is extremely
    49214942   important that all implementations of HTTP (including updates to

  • draft-ietf-httpbis/latest/p2-semantics.xml

    r1168 r1173  
    11331133   &SHOULD; reflect the message received back to the client as the
    11341134   message-body of a 200 (OK) response. The final recipient is either the
    1135    origin server or the first proxy or gateway to receive a Max-Forwards
     1135   origin server or the first proxy to receive a Max-Forwards
    11361136   value of zero (0) in the request (see <xref target="header.max-forwards"/>).
    11371137   A TRACE request &MUST-NOT; include a message-body.
    … …  
    23022302   TRACE (<xref target="TRACE"/>) and OPTIONS (<xref target="OPTIONS"/>)
    23032303   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 to
     2304   proxies. This can be useful when the client is attempting to
    23052305   trace a request which appears to be failing or looping in mid-chain.
    23062306</t>
    … …  
    23142314</t>
    23152315<t>
    2316    Each proxy or gateway recipient of a TRACE or OPTIONS request
     2316   Each recipient of a TRACE or OPTIONS request
    23172317   containing a Max-Forwards header field &MUST; check and update its
    23182318   value prior to forwarding the request. If the received value is zero

  • draft-ietf-httpbis/latest/p3-payload.xml

    r1167 r1173  
    15071507   client to function as an integrity check of the payload body. Only
    15081508   origin servers or user agents &MAY; generate the Content-MD5 header field;
    1509    proxies and gateways &MUST-NOT; generate it, as this would defeat its
     1509   proxies &MUST-NOT; generate it, as this would defeat its
    15101510   value as an end-to-end integrity check. Any recipient &MAY; check that
    15111511   the digest value in this header field matches a corresponding digest

  • draft-ietf-httpbis/latest/p6-cache.xml

    r1166 r1173  
    679679      <x:h>Note:</x:h> RFC 2616 (<xref target="RFC2616" x:fmt=","
    680680      x:sec="13.9"/>) required that caches do not calculate heuristic
    681       freshness for URLs with query components (i.e., those containing '?').
     681      freshness for URIs with query components (i.e., those containing '?').
    682682      In practice, this has not been widely implemented. Therefore, servers
    683683      are encouraged to send explicit directives (e.g., Cache-Control:
    … …  
    11001100</x:note>
    11011101<t>
    1102    An intermediary (i.e., a proxy or gateway, whether or not it implements
    1103    a cache) &MUST; pass cache directives through, regardless of their
     1102   A proxy, whether or not it implements a cache, &MUST; pass cache directives
     1103   through in forwarded messages, regardless of their
    11041104   significance to that application, since the directives might be applicable
    11051105   to all recipients along the request/response chain. It is not possible to
Note: See TracChangeset for help on using the changeset viewer.