On 1 May 2015, at 01:30, Daniel Ruggeri <[email protected]> wrote: >> >> 4. The backend MUST add the "X-Backend-Info" token to the "Connection" >> response header, making it a hop-by-hop field that is removed by the >> frontend from the downstream response (RFC2616 14.10 and RFC7230 6.1). [Note >> there appears to be an httpd bug here that I intend to submit and that needs >> to be addressed.] >> >> Connection: X-Backend-Info > > I'm not sure if this is a stroke of brilliance or extra work that isn't > needed :-) . As we discussed at the Con, it is vital for the proxy to remove > the header to avoid leaking any potentially useful information to an attacker > out to the 'tubes... but parsing Connection for "X-Backend-Info" seems like > it wouldn't be needed since one could just as well check if X-Backend-Info > header is present. I'm probably missing the obvious, but can you help me > understand more about why we would want this here instead of treating the > presence of the header as a sign to do some kind of work?
Here's a situation that could go wrong if this new header weren't marked as hop-by-hop. Imagine if there are two webserver products in a reverse proxy topology, something like this: user-agent ← httpd-proxy ← acme-proxy ← httpd-origin (the server tiers might in fact be clusters of identically configured hosts). All 4 tiers are doing HTTP/1.1 cacheing, correctly using Vary: and so on. If httpd-origin is sending X-Backend-Info then it must signal to ACME-proxy that this is a hop-by-hop header. Let's say httpd-origin signals that workers-free is 0. httpd-proxy receives a copy of this header and from acme-proxy. httpd-proxy incorrectly concludes that workers-free is 0 and starts sending 503 responses as per its intended configuration, even though acme-proxy would be able to serve stale responses from its cache. The sysadmin contacts the vendor “ACME Proxy”; the vendor asserts that their product is conforming to HTTP 1.1 and that the incorrect behaviour is in Apache httpd. Which, in my view, it would be. -- Tim Bannister – [email protected]
