W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2017

Mandating a default client timeout for HTTP 301

From: McGuireV10 <mcguirev10@gmail.com>
Date: Wed, 29 Nov 2017 15:03:00 +0000
Message-Id: <CADPK38_McGriDptZhJgyKqvpOBhvjHoFdQ-3GtDT1KfDomcq3g@mail.gmail.com>
To: ietf-http-wg@w3.org
I would like to suggest a mandatory default timeout for clients which cache HTTP 301 (Permanent Redirect) responses that are received without a corresponding expiration. It appears that all current major browsers take "permanent" very seriously, meaning the server potentially loses control of that URI forever. I don't live-and-breathe the HTTP spec like many of the folks on this list, but that appears to be a valid interpretation of the spec.

However, "permanent" means a simple mistake can become a very serious and irreversible problem for server owners. Sure, it's easy to say server owners should be careful, but in the real world mistakes happen, management makes decisions and changes their mind later, and so on. A quick search of stackoverflow and the web in general shows that this problem is not uncommon.

If you own the redirect target, you can issue another redirect back to the original resource, but if you don't control the clients, the safe solution is to never remove that second redirect -- which also means the second resource is permanently unavailable for other uses. If you do not own the redirect target (and the other owner can't or won't cooperate), you're simply out of luck.

A default timeout (specified as a "must" requirement) means clients would periodically re-validate cached 301s. Since 301 already requires a TTL, implementation would be trivial. (I only realized as I'm writing this that I haven't actually checked the spec to confirm expiration is supported, but the public at large seems to believe this to be the case and it seems to work with all major browsers.)

Off the top of my head, I would think the possible responses would fall into three categories: reset the timer and continue using the cached redirect (a 404 is the obvious example), update the cached redirect (for example, a different 301 response is received), or remove the redirect from the cache (the response succeeds in some "normal" fashion).

Received on Wednesday, 29 November 2017 22:35:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:15:11 UTC