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

On 8 Oct 2012, at 23:27, Sebastian Tramp <tramp@informatik.uni-leipzig.de> wrote:

> On Mon, Oct 08, 2012 at 10:07:01PM +0200, Baptiste Lafontaine wrote:
>>>> 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?
>>> 
>> 
>> I would have say that the specification should be a little bit more formal on
>> this point by telling how many redirections should/must be tested. This way
>> WebID implementations may have more consistency and prevent users from having
>> WebIDs that work on some implementation and does not on others.  In my
>> opinion it's the same for the number of URIs from the certificate's SAN.
> 
> I agree in this. We could request for at least two redirects, e.g. a webid
> redirects to a profile hoster which redirects to the specific representation.

not to take account of redirects is clearly not a good thing. But I wonder if
the HTTP spec says anything about the number either.

> 
>> Another problem that I face : let say that bob has this into his
>> certificate SAN :
>> URI:https://bob.example/profile#me
>> 
>> When reaching this URL, the VerificationAgent got a 301 (or 302) to
>> https://bob.somethingelse/profile#me.

Tim Berners Lee argued (see below ) that only 301 should change the 
URL of an http redirect.

>> 
>> When using the SPARQL query defined in 3.2.4.2, should the
>> VerificationAgent test against https://bob.example/profile#me or
>> https://bob.somethingelse/profile#me ?

That is a good question. 

As I see it a URL such as #me is defined by a document, only if it is in
the namespace of that document. But that of course does not work
for URLs such as foaf:knows which redirect to their definitions....

Ah here is the answer perhaps: with foaf:knows you get redirected but
your query still concerns foaf:knows 


$ curl -I http://xmlns.com/foaf/0.1/knows
HTTP/1.1 303 See Other
Date: Tue, 09 Oct 2012 05:51:21 GMT
Server: Apache/2.2.14 (Ubuntu)
Access-Control-Allow-Origin: *
Location: http://xmlns.com/foaf/spec/
Vary: Accept-Encoding
Content-Type: text/html; charset=iso-8859-1

But that is a 303.

Now I suppose this question must have been answered in some linked data group
allready.


> 
> Clearly https://bob.example/profile#me - the redirection will lead you from the
> non-information resource to a information resource which describes the
> requested one. Nethertheless, you will sometimes find triples with the
> information resources as the subject (e.g.  last modified timestamps of the
> foaf profile document).

I think we discussed something along these lines, and we should also add some
text here, because it is difficult. ( Not sure if we can because it realise
on HTTP2.0, and I am not sure where things are there )

There was a discussion on this here:
http://lists.w3.org/Archives/Public/public-webid/2012Apr/0006.html


Here is my implementation
https://dvcs.w3.org/hg/read-write-web/file/258d2757ef3d/src/main/scala/GraphCache.scala#l161


   161           // an oddity of HTTP, see the discussion on the WebID mailing list
   162           // http://lists.w3.org/Archives/Public/public-webid/2012Apr/0004.html
   163           // and the bug report on the httpbis mailing list
   164           // http://trac.tools.ietf.org/wg/httpbis/trac/ticket/154
   165           // and the definition of httpbis
   166           val loc = code match {
   167             case 301 => res.getHeaders("Content-Location").headOption match {
   168                 case Some(loc) =>  new URL(u,loc.getValue)
   169                 case None => new URL(u.getProtocol,u.getAuthority,u.getPort,u.getPath)
   170             }
   171             case _ => u
   172           }


It would be nice if we came up with some text to add to the spec on this, so that if
the issue comes up we can just point to the spec. That is the best way to make
the behaviour consistent across implementations...

Henry

> 
> Best regards
> 
> Sebastian Tramp
> 
> -- 
> WebID: http://sebastian.tramp.name

Social Web Architect
http://bblfish.net/