Re: Mandating a default client timeout for HTTP 301

Hi,

> On 30 Nov 2017, at 2:03 am, McGuireV10 <mcguirev10@gmail.com> wrote:
> 
> 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.

It's more than a valid interpretation -- I think it's the primary intent.

AIUI this distinction was made for the case mentioned in the RFC; bookmarks, link editors, etc. needed to know whether they should update the stored link, and 301 gives them a signal that it's OK to do so.

> 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).

The semantics of the status code -- for better or worse -- aren't tied to caching, so this would be a pretty big change. We're generally shy of doing that unless there's a significant interoperability or security issue, and this sounds like it's more of a developer usability issue -- i.e., people should have used a temporary, rather than a permanent redirect.

All of that said, I think we *could* put a warning in the spec to the effect that "permanent means permanent," advising to use a temporary redirect unless it's really permanent.

Cheers,


--
Mark Nottingham   https://www.mnot.net/

Received on Thursday, 30 November 2017 00:35:40 UTC