Re: same connection, different hosts

On 31/05/2015 11:18 a.m., Glen Knowles wrote:
> I pretty much concluded that, based on the way our server infrastructure
> works, we should set no-cache headers with all 421 responses.
> 
> This seems a reasonable option for any deployment where virtual servers
> wander around behind different clusters of proxies. Sometimes it's an
> optimization where you want to redirect requests for certain resources to
> somewhere closer to the client or to a server that already has the
> resources required cached locally.
> 
> In point of fact, I'm not sure there are any circumstances that you'd want
> clients to cache a 421. Because clearly you've configured DNS such that
> both hosts go to the same IP, therefore there must be (barring
> misconfiguration) a new connection scenario where it's okay to send
> requests for the 421 rejected host to the IP.

If you start looking closely at the wider HTTP/1 traffic system you will
find an enormous number of messages flowing around with Host: header
containing malformed, mismatching request-target, or otherwise plain
garbage values (ie "localhost:0" FFS).

Any of those are eligible for 421 and having it cacheable would vastly
reduce garbage bandwidth or loops of repeated requests.

The main use case I see though is ISP environments where for example,
https:// URLs are directed to a proxy with no HTTPS support built in.

Origin servers such as Apache where its possible to turn on TLS suport
and use it for example.com by then not possible to disable https:// URLs
for example.org being responded to with wrong certificates. 421 would
help prevent plaintext content going out over HTTPS. (yeah for some of
us its a legal requirement *not* to encrypt content).

Amos

Received on Monday, 1 June 2015 01:28:34 UTC