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

I opened this issue now:
  https://www.w3.org/2005/Incubator/webid/track/issues/64

Please come up with some text, and help along. It's a difficult issue.

We need text for

  a- what happens when a redirect moves from http to https  (security section)
  b- how to resolve urls in remote documents that were reached by redirects
  c- whether the WebID itself changes if redirected???
  d- a note on reasonable numbers of redirects to follow and pointer to http spec

 
I am not sure I have an answer for c.

Henry
  

On 9 Oct 2012, at 17:50, Henry Story <henry.story@bblfish.net> wrote:

> 
> On 9 Oct 2012, at 10:06, Baptiste Lafontaine <baptiste33@gmail.com> wrote:
>> [snip]
>> 
>> 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 that only 301 should change the
URL of an http redirect.

http://lists.w3.org/Archives/Public/public-webid/2012Apr/0004.html
and the bug report on the httpbis mailing list
http://trac.tools.ietf.org/wg/httpbis/trac/ticket/154

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

>>> [snip]
>> 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...
>>>