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

Re: Mandating a default client timeout for HTTP 301

From: Barry Tunetheweb <barry@tunetheweb.com>
Date: Thu, 30 Nov 2017 22:52:59 +0000
Message-ID: <CAM37g065JozUA1xTdF8MC-adqfsiDGk=sTd8G8e0gA_U_DuMKw@mail.gmail.com>
To: Matthew Kerwin <matthew@kerwin.net.au>
Cc: Mark Nottingham <mnot@mnot.net>, McGuireV10 <mcguirev10@gmail.com>, ietf-http-wg@w3.org
> I wasn't aware that browsers cache the 301. (I mean, maybe if you send the
>> right combination of cache headers along with the response...) And even if
>> they do, doesn't "forever" in a browser cache usually mean a couple of
>> months (assuming no further hits)?
Some of them definitely do, and often they are difficult to reset even if
you do have access to the client machines (which of course you won’t for an
Internet site).

I’m not sure how long “forever” means but a couple of months is a long time
and I personally would prefer this to be much, much smaller, or even zero.

However checking some more I’m not so sure about my post now...

https://tools.ietf.org/html/rfc7231#section-6.4.2 states:

A 301 response is cacheable by default; i.e., unless otherwise
   indicated by the method definition or explicit cache controls (see
   Section 4.2.2 of [RFC7234]

I was sure browsers totally ignored cache control headers from previous
investigations, but above suggests they should not, and double checking
now, it looks like I’m not setting cache control
headers on 301s when I was sure I was. Will dig some more, but it appears
that the problem is as the OP originally stated - the default value of
“forever” when no other cache control header is sent is the issue
(partially because most web servers make it easy to add 301s without cache
control headers, but less easy to add them with cache control headers so
most 301s will NOT have a cache control header).

So I would agree with the OPs request to add a max expiry time set in the
standard for when no other expiry is set. Though to be honest I’d prefer to
remove caching of 301s altogether - if the page still needs redirecting
next time, then sites can continue to send 301 and all that is lost is some
time for a redirect for those who never updated from the original URL.

I always read 301 as about updating bookmarks, crawler/search indices, etc.

Agreed that’s their primary usage. I wonder if that’s why some of the
browsers permenatly cache 301s - to effectively update the bookmark without
actually having to update it? Seems a bit fragile though if that is the
Received on Thursday, 30 November 2017 22:53:53 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 30 November 2017 22:54:01 UTC