- From: Martin Hepp <martin.hepp@ebusiness-unibw.org>
- Date: Wed, 27 Oct 2010 22:34:14 +0200
- To: nathan@webr3.org
- Cc: Ian Davis <lists@iandavis.com>, Linked Data community <public-lod@w3.org>, Semantic Web <semantic-web@w3.org>, foaf-protocols <foaf-protocols@lists.foaf-project.org>
Hi Nathan: Would it be an option that someone provides a service that resolves purls to their current resource locations and adds the JS/CORS header info to that service? I mean, one could use a service other than purl.org to resolve a purl.org URI. Something like cors4purl.org. Whenever your JS encounters a http://purl/.*$ URI, you fetch http://cors4purl.org/$1 . Not the most beautiful solution, but likely a clean, pragmatic way to make the many purl.org-based vocabularies accessible for client-side scripts. Martin On 27.10.2010, at 22:14, Nathan wrote: > Hi Martin, > > Great work! sadly though purl.org currently doesn't allow JS/CORS > access so it won't work :( this is true for everybody who use PURLz. > > see: http://groups.google.com/group/persistenturls/browse_thread/thread/d4c5d9880b4fb5fb > > for the request to add, please do add weight if you want them to > make it so - note that this will allow the redirects to be JS/CORS > compatible, it's still up to each end URI/domain to allow CORS > support (as martin has done). > > Best, > > Nathan > > Martin Hepp wrote: >> Hi Nathan, all: >> I just fixed this for GoodRelations >> http://purl.org/goodrelations/v1 >> and the Vehicle Sales Ontology (VSO): >> http://purl.org/vso/ns >> Best wishes >> Martin >> On 23.10.2010, at 03:28, Nathan wrote: >>> Hi Ian, >>> >>> Thanks, I can confirm the change has been successful :) >>> >>> However, one small note is that the conneg URIs such as http://productdb.org/gtin/00319980033520 >>> do not expose the header, thus can't be used. >>> >>> In order to test yourself, simply do a curl -I request on the >>> resource, for instance: >>> >>> curl -I http://productdb.org/gtin/00319980033520.rdf >>> >>> Also, I've just uploaded a small script which lets you enter a uri >>> of an RDF/XML document, it'll try and pull it, parse it and >>> display it as turtle for you - which is a good test of both CORS >>> and the script ;) >>> http://webr3.org/apps/play/api/test >>> >>> FYI, Dan has also made the change so the FOAF vocab is now exposed >>> to JS. >>> >>> Best and thanks again, >>> >>> Nathan >>> >>> Ian Davis wrote: >>>> Hi Nathan, >>>> I implemented this header on http://productdb.org/ (since I had the >>>> code open). Can someone comfirm that it does what's expected (i.e. >>>> allows off-domain requesting of data from productdb.org) >>>> One important thing to note. The PHP snippet you gave was slightly >>>> wrong. The correct form is: >>>> header("Access-Control-Allow-Origin: *"); >>>> Cheers, >>>> Ian >>>> On Sat, Oct 23, 2010 at 12:04 AM, Nathan <nathan@webr3.org> wrote: >>>>> Hi All, >>>>> >>>>> Currently nearly all the web of linked data is blocked from >>>>> access via >>>>> client side scripts (javascript) due to CORS [1] being >>>>> implemented in the >>>>> major browsers. >>>>> >>>>> Whilst this is important for all data, there are many of you >>>>> reading this >>>>> who have it in your power to expose huge chunks of the RDF on >>>>> the web to JS >>>>> clients, if you manage any of the common ontologies or anything >>>>> in the LOD >>>>> cloud diagram, please do take a few minutes from your day to >>>>> expose the >>>>> single http header needed. >>>>> >>>>> Long story short, to allow js clients to access our "open" data >>>>> we need to >>>>> add one small HTTP Response header which will allow HEAD/GET and >>>>> POST >>>>> requests - the header is: >>>>> Access-Control-Allow-Origin "*" >>>>> >>>>> This is both XMLHttpRequest (W3C) and XDomainRequest (Microsoft) >>>>> compatible >>>>> and supported by all the major browser vendors. >>>>> >>>>> Instructions for common servers follow: >>>>> >>>>> If you're on Apache then you can send this header by simply >>>>> adding the >>>>> following line to a .htaccess file in the dir you want to expose >>>>> (probably >>>>> site-root): >>>>> Header add Access-Control-Allow-Origin "*" >>>>> >>>>> For NGINX: >>>>> add_header Access-Control-Allow-Origin "*"; >>>>> see: http://wiki.nginx.org/NginxHttpHeadersModule >>>>> >>>>> For IIS see: >>>>> http://technet.microsoft.com/en-us/library/cc753133(WS.10).aspx >>>>> >>>>> In PHP you add the following line before any output has been >>>>> sent from the >>>>> server with: >>>>> header("Access-Control-Allow-Origin", "*"); >>>>> >>>>> For anything else you'll need to check the relevant docs I'm >>>>> afraid. >>>>> >>>>> Best & TIA, >>>>> >>>>> Nathan >>>>> >>>>> [1] http://dev.w3.org/2006/waf/access-control/ >>>>> >>>>> >>> >>> > >
Received on Wednesday, 27 October 2010 20:34:57 UTC