Re: Mandating a default client timeout for HTTP 301

>
> First time poster, long time lurker, so be nice if I’m wrong about this :-)

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

I would argue that it IS tied to caching - by most browsers making it
permanently cached as well.

While I don’t necessarily agree with the OPs suggested solution (personally
I think that perhaps it is up to the individual clients to decide on a max
setting), I do think there is a problem with permanently removing the
ability to use a URL because of a 301 and this has caused me problems in
the past.

Mistakingly using a 301 instead of a 302 is one use case and yes, arguable
this can be chalked up to user error, but I dislike there being no
forgiveness for user error in any system. There may be short term pain for
a mistake, but there should ALWAYS be a longer term solution to roll it
back IMHO. Forcing  a move to another URL (i.e. not being able to roll it
back) is therefore not a solution.

However, there are other use cases, where I have been more caught out:

Scenario 1: When trying to reuse a URL that was used in the past. For
example you have a URL called /example.html. You retire the page, and will
never be bringing it back, so put in a 301. After a while, everyone has
stopped referring to /example.html. Traffic logs show it’s not used and
maybe the redirect is even removed from the web server config (or are we
suggesting config files should just grow and grow?). Someone then decides
to use /example.html for a completely different purpose - perhaps unawares
that it was used previously. This works fine for most people, except a few
browsers that have the 301 cached and leads to weirdness (“It works for
me!”).

Should you NEVER be able to reuse a URL? Now arguably in this case, some
users may have bookmarked the original URL, be dependent on the redirect,
and therefore be surprised to see the new page if you publish something
else there, but to me that’s part and parcel of an evolving web and can be
controlled somewhat by checking web server logs before removing the
redirect.

Scenario 2: When the page it redirects to moves.

Example I have the following:

example1.html -> example2.html

Later I move example2.html so put another redirect:

example2.hrml -> example3.html

I should be able to update the original 301 to save the two step redirect.

Scenario 3: Domain is moved to a new owner with a completely new site.
After a transition period (ideally well defined) the new owner should not
be tied to the old owners decisions.

Instead of mandating a max time I would prefer if clients obeyed cage
control headers on redirects. During that time it should be treated as a
permanent redirect, and bookmarks and the likes can be updated, but if the
original is attempted again after that time, it should be able to return a
different response (either a resource or a different redirect) and know it
will be read by all clients after a set time. Maybe here there should be a
suggested max time as the OP wants for when no cache control header are
given on the 301 (my understanding is when cache control headers are not
given, it’s not clearly defined whether to cache or not, and for how long,
but I could be wrong about that).

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.


I would still prefer to be able to specify a cache control header saying
it’s “permanent for the duration of that cache control” (and all the
ramifications that permanent redirects have) but allow this to be changed.
I know the apparent contradiction of a non-permanent permenant redirect
might grate with some people but nothing is really permanent on the web!

301s are heavily used for SEO purposes where, as I say above, the intention
was to make it a permanent redirect at the time (and hence want a strong
signal to search crawlers that 302 doesn’t give) but may want to change
that in future for the scenarios given above or other reasons.

The alternative is to bring in a new HTTP Status code (30X - permanent but
non-cacheable redirect) but honestly don’t see the point. I do not see the
need why 301 needs to be permanently cached - as I say nothing is permanent
on the web.

Thanks,
Barry