Make CORS mandatory

[jpstroop]

See #4

[azaroth42]

What was our rationale about level 0 implementations and mandatory CORS?

[jpstroop]

Not sure...is there an issue? It's easy enough to do with Apache.

[azaroth42]

Easy if you have access to the configuration files or .htconfig in the directory (and support turned on in the server for it), but otherwise impossible? Level 0 should be possible just by putting files on disk somewhere. Also might not be so easy with other servers (but I have no experience outside of tornado, which would be a very odd choice of technology for serving images IMO)?

I see two options:

• a very strongly recommended
• must, with an exception for level 0

We should also have a field in the capabilities doc for CORS.

R

On Thu, Feb 27, 2014 at 4:32 PM, Jon Stroop notifications@github.comwrote:

Not sure...is there an issue? It's easy enough to do with Apache.

Reply to this email directly or view it on GitHubhttps://github.com/IIIF/specifications/issues/5#issuecomment-36305325 .

[jpstroop]

How about very strongly recommend, and require for level 1 compliance? And yeah, "cors_enabled" (bool).

[azaroth42]

Yup, +1

On Fri, Feb 28, 2014 at 11:15 AM, Jon Stroop notifications@github.comwrote:

How about very strongly recommend, and require for level 1 compliance? And yeah, "cors_enabled" (bool).

Reply to this email directly or view it on GitHubhttps://github.com/IIIF/specifications/issues/5#issuecomment-36378485 .

[zimeon]

+1 from me also... though perhaps amusing that an app won't be able to read capabilities.json to find cors_enabled = false ;-)

[jpstroop]

It is a little ridiculous. I understand that we want level 0 to be attainable with apache httpd only...but are we going too far by further assuming that the level 0 implementer won't have the privileges to configure their server either?

Starting to lean back toward MUST, regardless of level.

[zimeon]

What is the goal of level 0? Is it that a viewer (let's say OpenSeadragon for sake of concreteness) will run over on an image with the minimum infrastructure requirements possible? If CORS is necessary for that then perhaps it should be mandated for level 0 to be useful?

[azaroth42]

Question -- how well supported is .htconfig in vanilla apache installs? And are the necessary directives valid in it?

LoadModule headers_module modules/mod_headers.so
Header set Access-Control-Allow-Origin "*"

If that's commonly supported, I'm okay with MUST.

Use case for when you don't have access -- university servers. You get space, but that's all.

R

On Fri, Feb 28, 2014 at 1:55 PM, Jon Stroop notifications@github.comwrote:

It is a little ridiculous. I understand that we want level 0 to be attainable with apache httpd only...but are we going too far by further assuming that the level 0 implementer won't have the privileges to configure their server either?

Starting to lean back toward MUST, regardless of level.

Reply to this email directly or view it on GitHubhttps://github.com/IIIF/specifications/issues/5#issuecomment-36393486 .

[azaroth42]

CORS is only necessary when the image is used from a domain other than the hosting domain. So it would work fine without CORS in a javascript viewer on the same domain, or a non javascript/browser based implementation anywhere.

Also, the information may not even be needed -- it can be embedded in the manifest of the Presentation API (SWIDT) and thus a level 0 without CORS would still be useful cross domain.

I guess there's no precedent for level -1? (no cors, static images) :)

On Fri, Feb 28, 2014 at 2:01 PM, Simeon Warner notifications@github.comwrote:

What is the goal of level 0? Is it that a viewer (let's say OpenSeadragon for sake of concreteness) will run over on an image with the minimum infrastructure requirements possible? If CORS is necessary for that then perhaps it should be mandated for level 0 to be useful?

Reply to this email directly or view it on GitHubhttps://github.com/IIIF/specifications/issues/5#issuecomment-36393978 .

[azaroth42]

.htaccess rather. And the default is None as it's a security and performance hit to allow it.

http://httpd.apache.org/docs/2.2/howto/htaccess.html http://httpd.apache.org/docs/2.2/mod/core.html#allowoverride

So I'm sticking with very strong SHOULD.

On Fri, Feb 28, 2014 at 2:02 PM, Robert Sanderson azaroth42@gmail.comwrote:

Question -- how well supported is .htconfig in vanilla apache installs? And are the necessary directives valid in it?

LoadModule headers_module modules/mod_headers.so
Header set Access-Control-Allow-Origin "*"

If that's commonly supported, I'm okay with MUST.

Use case for when you don't have access -- university servers. You get space, but that's all.

R

On Fri, Feb 28, 2014 at 1:55 PM, Jon Stroop notifications@github.comwrote:

It is a little ridiculous. I understand that we want level 0 to be attainable with apache httpd only...but are we going too far by further assuming that the level 0 implementer won't have the privileges to configure their server either?

Starting to lean back toward MUST, regardless of level.

Reply to this email directly or view it on GitHubhttps://github.com/IIIF/specifications/issues/5#issuecomment-36393486 .

[jpstroop]

OK ok... but still required for level 1, or just should across the board?

[azaroth42]

Definitely required at level 1+

For the text, how about the kludge:

"The HTTP server MUST, if at all possible, send the Cross Origin Access control header..."

R

On Fri, Feb 28, 2014 at 2:18 PM, Jon Stroop notifications@github.comwrote:

OK ok... but still required for level 1, or just should across the board?

Reply to this email directly or view it on GitHubhttps://github.com/IIIF/specifications/issues/5#issuecomment-36395403 .

[zimeon]

cute kludge but kinda makes a mockery of RFC 2119... maybe just better to be explicit. "The HTTP server MUST send the Cross Origin Access control header except in level 0 implementations which SHOULD sent the header." and perhaps be explicit about the implications.

[azaroth42]

Yes, but we'd then need to explain level 0 in the specification. Currently it's just tacked in at the end under conformance.

On Fri, Feb 28, 2014 at 2:28 PM, Simeon Warner notifications@github.comwrote:

cute kludge but kinda makes a mockery of RFC 2119... maybe just better to be explicit. "The HTTP server MUST send the Cross Origin Access control header except in level 0 implementations which SHOULD sent the header." and perhaps be explicit about the implications.

Reply to this email directly or view it on GitHubhttps://github.com/IIIF/specifications/issues/5#issuecomment-36396172 .

[azaroth42]

How about:

"The HTTP server SHOULD, if at all possible, send the Cross Origin Access control header..."

And then with the profile level descriptions it's clear that CORS is required for everything above level 0.

[jpstroop]

Is "if at all possible" necessary? I feel like that's implied in (or at least one way to read) SHOULD.

?:

"The HTTP server SHOULD send the Access-Control-Allow-Origin header with the value "*". This is required for compliance with Level 1 or greater"

[zimeon]

I understand Rob's earlier point that we don't mention levels elsewhere in this document. How about the simple SHOULD version with then a statement about why, along the lines of: "This header is required in order to allow images to be used by Javascript viewers from different domains."

Also, should be add a reference to CORS?

[azaroth42]

I'm fine with that. And yes, should add a ref to http://www.w3.org/TR/cors

R

On Mon, Mar 3, 2014 at 12:22 PM, Simeon Warner notifications@github.comwrote:

I understand Rob's earlier point that we don't mention levels elsewhere in this document. How about the simple SHOULD version with then a statement about why, along the lines of: "This header is required in order to allow images to be used by Javascript viewers from different domains."

Also, should be add a reference to CORS?

Reply to this email directly or view it on GitHubhttps://github.com/IIIF/specifications/issues/5#issuecomment-36548060 .

[zimeon]

Concrete proposal as branch issue5: https://github.com/IIIF/specifications/commit/76266401e89e1c01bddec8865874346a75e97bfd

[azaroth42]

SImeon's commit closes this issue.