Extending redirects to suggest updated locations ?

Hi,

it recently happened to me again that some people downloaded an old
deprecated version of some software I authored, installed it in
production and blogged about it with links to the deprecated software.
The link is basically a link to the tgz, such as :

  http://haproxy.1wt.eu/download/1.4/src/haproxy-1.4.8.tar.gz

When the link points to an old version which contains at least 50
known bugs, then I'm sure that in the following days the support
mailing list will receive several mails reporting known issues. In
fact, knowing that users will experience issues sooner or later
worries me much more than to think they'll send mails about that.

I've already thought about replacing the file with a symlink to the
new version or to perform a redirect to the new version, but that's
really not friendly to admins or packagers who really need version
X or Y because they maintain it and apply the fixes on top of them.
And in general I don't like removing contents from the net, whether
it's buggy or not.

Thus I realized that we might be missing a possibly useful feature.
What is needed to cover the issue above would be either to have the
ability to report an "obsolete" or "deprecated" status to the user
agent for the file being downloaded, or to report a Location header
indicating where to get the newer version, or maybe both.

In both cases, the user agent would have two possibilities :
  - either it is automated (wget, curl, etc...) and wouldn't care
    about those headers. It could eventually log them if it provides
    a log of the downloads.

  - or it would be interactive and controlled by a user (browser), so
    it could report the status to the user and ask him if he still
    wants to download that content, or prefers to be redirected to the
    updated location (which may either be a page or downloadable contents).

Since the behaviour only depends on whether we're responding to a machine
or to a human being, I don't think it can easily be addressed on the server
side alone.

So, for instance, we could have :

HTTP/1.1 200 OK
Content-status: deprecated
Location: /download/1.4/src/haproxy-1.4.9.tar.gz
... + requested contents

Or perhaps :

HTTP/1.1 303 Found
Content-status: deprecated
Location: /download/1.4/src/haproxy-1.4.9.tar.gz
... + requested contents

Or maybe :

HTTP/1.1 200 OK
Content-status: deprecated; preferred=/download/1.4/src/haproxy-1.4.9.tar.gz
... + requested contents

I think the former would be better since it still allows server-side
intermediaries to rewrite paths as they do for many apps today.

Have I missed something ? Would it be useful to work on something like this,
and is it appropriate for the HTTP spec ?

Thanks,
Willy

Received on Sunday, 3 October 2010 06:02:16 UTC