W3C home > Mailing lists > Public > public-xg-webid@w3.org > October 2012

Re: WebID-ISSUE-64 (redirects): Redirects [WebID Spec]

From: Henry Story <henry.story@bblfish.net>
Date: Mon, 8 Oct 2012 19:41:59 +0200
Cc: WebID Incubator Group WG <public-xg-webid@w3.org>
Message-Id: <54F62DF0-2C8C-437C-8889-FB96F208419B@bblfish.net>
To: Baptiste Lafontaine <baptiste33@gmail.com>

On 8 Oct 2012, at 19:33, Baptiste Lafontaine <baptiste33@gmail.com> wrote:

> 2011/11/25 WebID Incubator Group Issue Tracker <sysbot+tracker@w3.org>
>> WebID-ISSUE-64 (redirects): Redirects [WebID Spec]
>> http://www.w3.org/2005/Incubator/webid/track/issues/64
>> Raised by: Henry Story
>> On product: WebID Spec
>> Peter Williams correctly points out that the spec should have some text and some thought go into what happens or should happen with HTTP redirects, when fetching a profile. Even if it is just to say that one should not follow those.
> I've read all this old topic but I face this issue while doing my
> node.js implementation.
> The current spec [1] says: "Add explanation for URI with redirect."
> Should I follow all redirects ? What kinds of redirects makes the URL
> of the query changed into the SparQL query ?
> Please note that this is not a theoretical question and  I would
> prefer a pragmatic answer.
> [1] : http://www.w3.org/2005/Incubator/webid/spec/drafts/ED-webid-20111212/#verifying-the-webids

I would say one should follow redirects of course. The question is what are the issues
that may arise there. If an https url redirects to an http url then you must reduce the
trust you have to trust towards that http resource, since that could have been man-in-the

Otherwise I would follow as many redirects as seems cost effective. People who have too many
redirects on their WebID should not be surprised if they have difficulty logging in. On the
other hand servers that don't follow redirects at all will loose friends.

What text do you think we should put there?

> Thanks
> Baptiste

Social Web Architect

Received on Monday, 8 October 2012 17:42:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:39:56 UTC