Currently all PURLs (on purl.org) do not expose headers which allow
client side access from javascript, they are currently all blocked by
CORS [1].
Allowing access is as simple as adding a single HTTP Response Header -
'Access-Control-Allow-Origin "*"'
End resources will also have to expose this header, however at the
moment purl.org is blocking access to js regardless of whether the end
resource is exposed or not.
Is there anybody here who can make this change, if not, to who do I
speak?
The Cross-Origin Resource Sharing specification appears to be on the bleeding edge (23 Sept 2010) and is currently in "Editor's Draft" status. It's not clear (to me at least) that setting this header blindly for all PURL responses is appropriate. These "same-origin restrictions" that CORS is trying to sidestep are presumably there for a reason.
Even if blindly setting this header does make sense, my naive impression is that NetKernel requires HTTP response headers to be implemented in code rather than configuration. I think purl.org needs to beware of customizing PURLZ code because preserving and test changes across PURLZ distribution updates is non-trivial. If it makes sense to set this header, I'm inclined to believe it needs to be part of a future PURLZ distribution.
> -----Original Message----- > From: persistenturls@googlegroups.com > [mailto:persistenturls@googlegroups.com] On Behalf Of nathan > Sent: Friday, October 22, 2010 8:45 PM > To: persistenturls > Subject: Please allow access to PURLs from JS
> Hi,
> Currently all PURLs (on purl.org) do not expose headers which allow > client side access from javascript, they are currently all blocked by > CORS [1].
> Allowing access is as simple as adding a single HTTP Response Header - > 'Access-Control-Allow-Origin "*"'
> End resources will also have to expose this header, however at the > moment purl.org is blocking access to js regardless of whether the end > resource is exposed or not.
> Is there anybody here who can make this change, if not, to who do I > speak?
> The Cross-Origin Resource Sharing specification appears to be on the > bleeding edge (23 Sept 2010) and is currently in "Editor's Draft" > status. It's not clear (to me at least) that setting this header blindly > for all PURL responses is appropriate. These "same-origin restrictions" > that CORS is trying to sidestep are presumably there for a reason.
> Even if blindly setting this header does make sense, my naive impression > is that NetKernel requires HTTP response headers to be implemented in > code rather than configuration. I think purl.org needs to beware of > customizing PURLZ code because preserving and test changes across PURLZ > distribution updates is non-trivial. If it makes sense to set this > header, I'm inclined to believe it needs to be part of a future PURLZ > distribution.
> Jeff
>> -----Original Message----- >> From: persistenturls@googlegroups.com >> [mailto:persistenturls@googlegroups.com] On Behalf Of nathan >> Sent: Friday, October 22, 2010 8:45 PM >> To: persistenturls >> Subject: Please allow access to PURLs from JS
>> Hi,
>> Currently all PURLs (on purl.org) do not expose headers which allow >> client side access from javascript, they are currently all blocked by >> CORS [1].
>> Allowing access is as simple as adding a single HTTP Response Header - >> 'Access-Control-Allow-Origin "*"'
>> End resources will also have to expose this header, however at the >> moment purl.org is blocking access to js regardless of whether the end >> resource is exposed or not.
>> Is there anybody here who can make this change, if not, to who do I >> speak?
Currently CORS is supported by all major browsers (IE, Chrome, Firefox, Safari) except Opera, who are adding in the very near future (Anne van Kesteren from Opera is the one writing the spec).
I also have a full response to Jeff's comments from Jonathan Rees (from the TAG, Creative Commons) which I'll fwd under separate cover - for some reason the google group wouldn't accept his email.
In general purl.org is sitting in the middle and currently prevents anybody using PURLz from adopting CORS, and there are many who would like to adopt, it's a shame to see them blocked.
> I have no problem adding this header but I agree with Jeff that it would be good to wait Until there is a standard.
> Nathan, do you have any reason to think that current Javascript implementations support use of this header?
> Regards, > Dave
> On Oct 25, 2010, at 17:11, "Young,Jeff (OR)" <jyo...@oclc.org> wrote:
>> Nathan,
>> The Cross-Origin Resource Sharing specification appears to be on the >> bleeding edge (23 Sept 2010) and is currently in "Editor's Draft" >> status. It's not clear (to me at least) that setting this header blindly >> for all PURL responses is appropriate. These "same-origin restrictions" >> that CORS is trying to sidestep are presumably there for a reason.
>> Even if blindly setting this header does make sense, my naive impression >> is that NetKernel requires HTTP response headers to be implemented in >> code rather than configuration. I think purl.org needs to beware of >> customizing PURLZ code because preserving and test changes across PURLZ >> distribution updates is non-trivial. If it makes sense to set this >> header, I'm inclined to believe it needs to be part of a future PURLZ >> distribution.
>> Jeff
>>> -----Original Message----- >>> From: persistenturls@googlegroups.com >>> [mailto:persistenturls@googlegroups.com] On Behalf Of nathan >>> Sent: Friday, October 22, 2010 8:45 PM >>> To: persistenturls >>> Subject: Please allow access to PURLs from JS
>>> Hi,
>>> Currently all PURLs (on purl.org) do not expose headers which allow >>> client side access from javascript, they are currently all blocked by >>> CORS [1].
>>> Allowing access is as simple as adding a single HTTP Response Header - >>> 'Access-Control-Allow-Origin "*"'
>>> End resources will also have to expose this header, however at the >>> moment purl.org is blocking access to js regardless of whether the end >>> resource is exposed or not.
>>> Is there anybody here who can make this change, if not, to who do I >>> speak?
On Oct 27, 6:52 pm, Nathan <nat...@webr3.org> wrote:
> Currently CORS is supported by all major browsers (IE, Chrome, Firefox,
> Safari) except Opera, who are adding in the very near future (Anne van
> Kesteren from Opera is the one writing the spec).
[..]
> In general purl.org is sitting in the middle and currently prevents
> anybody using PURLz from adopting CORS, and there are many who would
> like to adopt, it's a shame to see them blocked.
I'd like to support Nathan's request. In fact I wrote one of my own
(copied in full below) but sent it to the wrong / old PURL list.
While we can't 100% guarantee the specs won't change, the impression I
have is that CORS is pretty stable and well supported in modern
browsers.
PURL is a very specific kind of Web service, and I think CORS support
ought to be added soonish, since without support from purl.org (and
other installations), users of the system are unable to make up their
own mind whether to support CORS. And without CORS headers from the
redirected-to sites, browsers still won't be able to access anything.
So the content is safe regardless of the headers sent by the purl.
Unblocking things on the purl side will open the door for all of these
sites (and in the SemWeb community, that's a good %) to explore and
evaluate CORS. I'd hope we can get them doing so while there is still
some door open for final tweaks to the CORS spec.
I understand this means work for someone, and don't ask lightly. But I
think the time is right...
cheers,
Dan
------- 8< ----------
Hi folks,
Currently OCLC's PURL service (and I presume others) does not return
Access-Control-Allow-Origin "*"
If you add this 'CORS' header (see
http://dev.w3.org/2006/waf/access-control/ and more detailed version
of this request
http://lists.w3.org/Archives/Public/public-lod/2010Oct/0181 ) then
modern Web browsers will be about to fetch documents (in particular
XML including RDF/XML schemas and data) via purls. The inability to
de-reference publically available RDF/XML documents from within a
Javascript app is currently forcing people to use JSON/Javascript data
encodings, awkward proxies, or to develop everything server-side. This
makes it difficult, for example, for clientside Javascript apps to
parse the Dublin Core's RDF schema document.
You might be considering making the CORS header and optional /
configurable feature. However I'd advise against this, as that would
be a lot more work, for no clear gain. The only information content in
a PURL is the redirect, and the managers of the site it redirects to
then have their own direct option to decide whether to support the
CORS header. So the point of this mail is to ask that purl.org remove
this barrier to PURL users making this decision on a case-by-case
basis on their own sites.
That said, you might want to not use the header on areas of the site
that involve logins, personalisation or customisation (eg. /admin/,
/docs/), but for the public areas it should be harmless and simple,
and open up lots of possibilities for rich apps using data that is
published behind PURL URIs.
danbri wrote: >> Currently CORS is supported by all major browsers (IE, Chrome, Firefox, >> Safari) except Opera, who are adding in the very near future (Anne van >> Kesteren from Opera is the one writing the spec). > [..] >> In general purl.org is sitting in the middle and currently prevents >> anybody using PURLz from adopting CORS, and there are many who would >> like to adopt, it's a shame to see them blocked.
> I'd like to support Nathan's request. In fact I wrote one of my own > (copied in full below) but sent it to the wrong / old PURL list.
> While we can't 100% guarantee the specs won't change, the impression I > have is that CORS is pretty stable and well supported in modern > browsers.
Just to confirm, even if CORS does end up changing, the one bit that is very widely deployed and can be considered as close to stable as you can get, is the single header Access-Control-Allow-Origin which we need.
The parts of CORS which are still in semi-flux are related to exposing additional headers and handling non-simple requests such as PUT and DELETE.
As the maintainer of the GoodRelations vocabulary for e-commerce
(http://purl.org/goodrelations/) I would like to strongly endorse
Nathan's request. Currently, purl.org prevents (or at least
complicates substantially) the development of client-side scripts that
make use of GoodRelations rich commerce data.
I am also the maintainer of the Vehicle Sales Ontology (http://
purl.org/vso/ns), where I am running into the same problems.
This should really not be put off, it is a high priority for us.
Maybe you can add a simple check-box so that when configuring a
purl.org domain or PURL every maintainer has the choice to send this
additional header parameter. If the default is "off", then adding the
new feature should also not break any of the existing implementations.
> danbri wrote:
> >> Currently CORS is supported by all major browsers (IE, Chrome, Firefox,
> >> Safari) except Opera, who are adding in the very near future (Anne van
> >> Kesteren from Opera is the one writing the spec).
> > [..]
> >> In general purl.org is sitting in the middle and currently prevents
> >> anybody using PURLz from adopting CORS, and there are many who would
> >> like to adopt, it's a shame to see them blocked.
> > I'd like to support Nathan's request. In fact I wrote one of my own
> > (copied in full below) but sent it to the wrong / old PURL list.
> > While we can't 100% guarantee the specs won't change, the impression I
> > have is that CORS is pretty stable and well supported in modern
> > browsers.
> Just to confirm, even if CORS does end up changing, the one bit that is
> very widely deployed and can be considered as close to stable as you can
> get, is the single header Access-Control-Allow-Origin which we need.
> The parts of CORS which are still in semi-flux are related to exposing
> additional headers and handling non-simple requests such as PUT and DELETE.
