Please allow access to PURLs from JS

[nathan]

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?

Best & TIA,

Nathan

[1] http://dev.w3.org/2006/waf/access-control/

[Young,Jeff (OR)]

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

[David Wood]

Hi all,

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

[Nathan]

Hi David,

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.

Best,

Nathan

[danbri]

Hi folks

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.

cheers,

Dan

ps. current headers are -

TellyClub:~ danbri$ curl -i -I http://purl.org/dc/elements/1.1/
HTTP/1.1 302 Moved Temporarily
Date: Sun, 24 Oct 2010 07:28:43 GMT
Server: 1060 NetKernel v3.3 - Powered by Jetty
Location: http://dublincore.org/2010/10/11/dcelements.rdf#
Content-Type: text/html; charset=iso-8859-1
X-Purl: 2.0; http://localhost:8080
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Content-Length: 281



http://lists.w3.org/Archives/Public/public-lod/2010Oct/0181

[Nathan]

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.

Best,

Nathan

[mfhepp]

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.

Best

Martin Hepp
http://www.heppnetz.de/