Re: Extending redirects to suggest updated locations ?

Perhaps a Link header with a new link relation like  
"newer"/"older" (to allow iterating both directions through releases)  
or "latest"?

Jon

........
Jon Moore


On Oct 3, 2010, at 2:04 AM, "Willy Tarreau" <w@1wt.eu> wrote:

> 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 11:15:26 UTC