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

On 9 Oct 2012, at 10:06, Baptiste Lafontaine <baptiste33@gmail.com> wrote:

> 2012/10/9 Henry Story <henry.story@bblfish.net>:
>> 
>> 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.
>> 
> 
> 
> The RFC 2616 (HTTP1.1) does not fix a limit :
>  "A client SHOULD detect infinite redirection loops, since
>    such loops generate network traffic for each redirection.
> 
>    Note: previous versions of this specification recommended a
>      maximum of five redirections. Content developers should be aware
>      that there might be clients that implement such a fixed
>      limitation."
> 
> I would like to see the discussion that led to removing the limit of
> five redirections but it should be quite old.
> 
> It seems like Chrome, Firefox and Internet Explorer set their
> redirection limit to 20. If we use a different value, people who are
> trying to test their WebID into their browser could be confused
> because it would work on their browser but not while trying to log-in.
> By the way 20 seems too long for the WebID process.
> In my opinion, 5 seems long enough to discover most WebID profile and
> short enough in order to keep the process short.
> 
> I can't seen any drawbacks in giving a precise number in the
> specification but I am definitively not a pro in writing
> specifications ;)

I think we could have a note pointing to that note, and just
simply say that too many redirections are likely to cause 
failures. WebId client certificate testers could flag in yellow
anything that had ore than 3 and in red any webid that required
more than 5 redirects.

> 
> 
>> 
>> 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           }
>> 
> 
> I'm not fluent in Scala so it does not help me much right now. What I
> understand : when the code is 301, you define the new location as the
> value of the Content-location header ?
> In all other case, you just use the URI defined into the SAN.

yes, that has to do with how one interprets relative urls in the 
document fetched. 

http://lists.w3.org/Archives/Public/public-webid/2012Apr/0004.html

Of course then one has to ask if one also needs to adapt the WebID...
That is a difficult question...

> 
>> 
>> 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...
>> 
> 
> Another issue which came into my mind: how should the implementation
> manage multiple URIs into the SAN. Currently the specification
> basically says "do whatever you want" but it does not look that much
> satisfying.
> Should I start a thread about this problem ?

That was issue 1 which was closed.
I think the spec says: that you can verify as many SANs as you want. The 
server can on verified SANs only. So it is completely up to the server.
If the access control rule for a resource only allows one of the webids
access, then there would be no point verifying any of the others for 
example. Do you still think something is missing here?

> 
> 
>> Henry
>> 
>> 
>> Best regards
>> 
>> Sebastian Tramp
>> 
>> --
>> WebID: http://sebastian.tramp.name
>> 
>> 
>> Social Web Architect
>> http://bblfish.net/
>> 
> 
> 
> Baptiste Lafonntaine

Social Web Architect
http://bblfish.net/