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
I have no problem adding this header but I agree with Jeff that it would be good to wait Until there is a standard.
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.
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.