[Fwd: CORS & PURL]
Nathan
can't post for some reason!
-------- Original Message --------
Subject: CORS & PURL
Date: Wed, 27 Oct 2010 05:08:30 -0700
From: Jonathan Rees <j...@creativecommons.org>
To: nat...@webr3.org
I don't know why I can't post to the group. You can forward this if
you like, if I don't fix the posting problem first.
Best
Jonathan
Date: Wed, 27 Oct 2010 05:06:29 -0700
Subject: Re: Please allow access to PURLs from JS
From: Jonathan Rees <j...@creativecommons.org>
To: persist...@googlegroups.com
On Mon, Oct 25, 2010 at 9:11 AM, 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.
Yes, but for better or worse, it is (as I understand) implemented by
many user agents - they are not waiting for the standards process,
which seems to be stalled anyway, to run its course.
> 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.
The same-origin policy, to which CORS/UMP enables exceptions, is there
to protect resources from confused deputy attacks, which roughly
speaking is the use of client credentials by the wrong party. As the
PURL(Z) server does not make use of any client-side credentials (IP
address, cookies, authentication, encryption, Origin:, Referer:, etc.)
the PURLs themselves do not need SOP protection. The redirect target
may need such protection (although who knows why it would have gotten
a PURL if so), but it can protect itself using SOP - that's not the
PURL's job.
So I agree with Nathan - it would be beneficial and harmless to
disable SOP protection for all PURLs by using the appropriate CORS/UMP
header. THis would be a boon to semantic web clients and others.
Of course if there ever were such a thing as a protected PURL
redirect, this would have to be reviewed.
> 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.
Agreed - but isn't this the right forum for such discussions?
Jonathan
> Jeff
>