Subject: Extending redirects to suggest updated locations ?

From: Willy Tarreau <[email-masked]>
Date: Sun, 3 Oct 2010 08:01:47 +0200

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

---

From: Julian Reschke <[email-masked]>
Date: Sun, 03 Oct 2010 09:55:05 +0200

On 03.10.2010 08:01, Willy Tarreau wrote:
> ...
> ...

Yes.

> ..

How about:

HTTP/1.1 200 OK
Content-status: deprecated
Link: <haproxy-1.4.9.tar.gz>; rel=newest-version

?

Best regards, Julian

---

From: "Moore, Jonathan" <[email-masked]>
Date: Sun, 3 Oct 2010 07:14:08 -0400

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

Jon

........
Jon Moore

---

From: Willy Tarreau <[email-masked]>
Date: Sun, 3 Oct 2010 18:58:12 +0200

Hi Julian,

> Link: <haproxy-1.4.9.tar.gz>; rel=newest-version

Yes, probably something like this. It would make a good use of
the Link header. And doing it this way is a good idea because
it even allows multiple Link headers in case other branches may
be suggested. For instance :

Link: <haproxy-1.4.8.1.tar.gz>; rel=fixed-version; title="Fixes critical bug"
Link: <haproxy-1.4.9.tar.gz>; rel=updated-version; title="Latest in same branch"
Link: <haproxy-2.0.2.tar.gz>; rel=newest-version; title="Latest in latest branch"

In case nobody would object, how could we move on ? Doing so involves a
new header ("content-status"), so that should probably require proper
registration. Also, I've not seen any registry for all relation-types,
so we might need to define a few. Also, does a draft need to be written
to advance ?

Thanks,
Willy

---

From: Willy Tarreau <[email-masked]>
Date: Sun, 3 Oct 2010 18:59:50 +0200

> "newer"/"older" (to allow iterating both directions through releases)  

Yes, I did not think about the Link header, not being used to it, and
that's what Julian proposed too. I'm not sure we'd need to move in the
other direction though. However, jumping between branches certainly is
useful.

Regards,
Willy

---

From: Julian Reschke <[email-masked]>
Date: Sun, 03 Oct 2010 19:06:22 +0200

On 03.10.2010 18:58, Willy Tarreau wrote:
>> Link:<haproxy-1.4.9.tar.gz>; rel=newest-version
>
> Link:<haproxy-1.4.8.1.tar.gz>; rel=fixed-version; title="Fixes critical bug"
> Link:<haproxy-1.4.9.tar.gz>; rel=updated-version; title="Latest in same branch"
> Link:<haproxy-2.0.2.tar.gz>; rel=newest-version; title="Latest in latest branch"
>

Do we really need Content-Status?

> so we might need to define a few. Also, does a draft need to be written

The Link Relations registry is defined in RFC5988-to-be 
(<http://greenbytes.de/tech/webdav/#draft-nottingham-http-link-header>).

Best regards, Julian

---

From: Willy Tarreau <[email-masked]>
Date: Sun, 3 Oct 2010 19:21:28 +0200

> Do we really need Content-Status?

I don't know. Maybe we can deduce it from the presence of the Link
headers. But when reading the Link header spec below :
  http://tools.ietf.org/id/draft-nottingham-http-link-header-10.txt

I did not get the impression that the header is supposed to cause UAs
to request specific user action. But maybe we could imagine that some
specific values of the header are automatically detected by UAs and
make them ask the user for chosing the most suitable version. I'm not
certain this practice is good for the long term (eg: should browser
present a popup when encountering unknown types). Probably that Mark
has some insights on the best way to use the header.

> (<http://greenbytes.de/tech/webdav/#draft-nottingham-http-link-header>).

So if I understand it correctly, we refer to the types enumerated in
RFC4287 ? Then we have 5 available types : "alternate", "related", "self",
"enclosure", and "via". I thought that "alternate" would fit but it's
indicated that no more than one link may be present, which limits the
usefulness.

Regards,
Willy

---

From: "Eric J. Bowman" <[email-masked]>
Date: Sun, 3 Oct 2010 12:18:36 -0600

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

One solution is to attach a Link header to that response, with rel=
alternate pointing to /download/current/src/haproxy-latest.tgz, which
when dereferenced returns Location or Content-Location with the version-
specific URI of the latest version.

If the "user" is something like pkgsrc or ports, you're providing all
the information necessary for re-downloading the existing, installed
version vs. updating the package tree while preserving the version for
later re-downloading, etc. (assuming the agents for such users are
updated to grok C-L and Link, or you're redirecting from latest).

You're basically stuck with the problem of folks downloading the old
version that's been linked to, unless you're willing to disallow access
to the old version by redirecting to latest, or download managers react
to the rel=alternate by informing the user that there's also haproxy-
latest.tgz to consider -- which seems reasonable considering that the
act of downloading from a link already requires user interaction where
browsers are concerned, presumably wget could be updated to understand
rel=alternate with a switch to always ignore/follow/ask.

-Eric

---

From: Julian Reschke <[email-masked]>
Date: Sun, 03 Oct 2010 21:14:36 +0200

> make them ask the user for chosing the most suitable version. I'm not

Well, rel=stylesheet already "makes" UA do something.

> present a popup when encountering unknown types). Probably that Mark

No, the browser certainly should *not* display a popup for unknown types :-)

> indicated that no more than one link may be present, which limits the

No no, I just was pointing out that this is the new definition of the 
registry.

I would suggest that we either pick one of those listed in

   http://www.iana.org/assignments/link-relations/link-relations.txt

... - "latest-version" might make sense, or define a new one.

Best regards, Julian

---

From: Willy Tarreau <[email-masked]>
Date: Sun, 3 Oct 2010 21:22:14 +0200

> Well, rel=stylesheet already "makes" UA do something.

OK.

(...)
> ... - "latest-version" might make sense, or define a new one.

Indeed, this one looks quite adequate. The "current" might be fine
too.

So... everything's already defined, we have nothing to do :-)

Regards,
Willy

---

From: Julian Reschke <[email-masked]>
Date: Sun, 03 Oct 2010 22:17:41 +0200

> So... everything's already defined, we have nothing to do :-)

That would be too easy :-)

I think what needs to be done is a small spec that what UAs should do 
when somebody does a "save as" (or the UA does because of 
Content-Disposition), and the link relation is present.

Best regards, Julian