W3C home > Mailing lists > Public > public-xg-webid@w3.org > January 2012

Re: New ResourceMe Version

From: bergi <bergi@axolotlfarm.org>
Date: Sun, 08 Jan 2012 21:54:56 +0100
Message-ID: <4F0A02A0.1050606@axolotlfarm.org>
To: Kingsley Idehen <kidehen@openlinksw.com>
CC: public-xg-webid@w3.org
Am 07.01.2012 20:15, schrieb Kingsley Idehen:
> On 1/6/12 7:46 PM, bergi wrote:
>> 'HTTP/1.1 303 See Other
>> Server: Virtuoso/06.03.3131 (Linux) x86_64-generic-linux-glibc25-64  VDB
>> Connection: close
>> Date: Sat, 07 Jan 2012 00:11:48 GMT
>> Accept-Ranges: bytes
>> TCN: choice
>> Vary: negotiate,accept
>> Content-Location: sioc.rdf
>> Content-Type: application/rdf+xml
>> Location:http://kingsley.idehen.net/dataspace/raw/person/sioc.rdf
>> Content-Length: 0
> 
> Bergi,
> 
> Here is an explanation of the above, also see the HTTP response code
> page from Wikipedia [1] for reference also note the URI debug URL [2]
> below re. the descriptor resource that has URL:
> http://kingsley.idehen.net/dataspace/person/kidehen .
> 
> Content-Location --- reference for an alternate location for the
> returned data
> Location --- used in redirection, or when a new resource has been created.
> 
> URL: http://kingsley.idehen.net/dataspace/person/kidehen isA resource
> address, representation is negotiable. Thus, you have two paths to the
> representation you seek depending on whether your client thinks in terms
> of Content-Location or redirection oriented Location re. header responses.
> 
> For WebID, what's important to you is the location of the composite key
> comprised of WebID and Public Key components that enables "mirrored
> claim" triangulation. How you get to the graph shouldn't matter. It the
> composite key lookup or failure that should determine success or failure.
> 
> At the end of the day you are looking for a signed claim match :-)
> 

Can you try if it works now? I tried your cert with the form on the test
page and it was working.

The problem was something that was discussed on this mailing list some
days ago: Hash in http request. I didn't remove it and the cURL PHP
extensions did behave different on my Windows and Linux machine. I
couldn't figure out how the request looked at the end because there is
no easy way to dump the request header. Maybe cURL escapes the hash
before sending it over the wire, so the request would be still valid but
wrong in our case.
Received on Sunday, 8 January 2012 20:55:17 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 8 January 2012 20:55:17 GMT