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

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 ;)


>
> 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.

>
> 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 ?


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


Baptiste Lafonntaine

Received on Tuesday, 9 October 2012 08:07:07 UTC