- From: Henry Story <henry.story@bblfish.net>
- Date: Mon, 8 Oct 2012 19:41:59 +0200
- To: Baptiste Lafontaine <baptiste33@gmail.com>
- Cc: WebID Incubator Group WG <public-xg-webid@w3.org>
- Message-Id: <54F62DF0-2C8C-437C-8889-FB96F208419B@bblfish.net>
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 -middled. 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 http://bblfish.net/
Attachments
- application/pkcs7-signature attachment: smime.p7s
Received on Monday, 8 October 2012 17:42:52 UTC