Re: JSON-LD responses for core ontologies don't contain CORS headers; limits browser clients

Tomasz, I actually do use your vocabulary package in the app for some
sections. I do understand those problems you mentioned, but the situation
in my app is one where the rdf and rdfs ontologies are one out of many
properties on an object, and the user hovers over the IRI to dereference it
to get additional data (e.g. a title from rdfs:label). Thus I could
implement it differently by adding a cache of common ontologies, but I'm
reaching for the ideal world described in the LInked Data note
<https://www.w3.org/DesignIssues/LinkedData.html>. In fact, in my mind,
most of the problems you mentioned would be "good problems to have,"
because they would indicate significant adoption of linked data technology
via heavy load on the servers.

Ivan, thanks for your response. I did indeed test locally and the headers
are the same for rdf-schema as for rdf-syntax-ns. However, the primary
issue I was running into was that for some reason this header:
access-control-allow-origin: *
is present on the regular request but not the one with "Accept:
application/ld+json" I'm not sure why this would be the case if it's added
with:

Header set Access-Control-Allow-Origin "*"

to the .htaccess file. This might require some more investigation.

However, I also noticed some other issues with the headers. Firstly I
don't see any reason why we need access-control-allow-credentials.

Then, with:
access-control-allow-headers: Link, Location, Content-Type, Accept, Vary
the TLDR is that this line doesn't make a difference to browser clients.

Link and Content-Type are entity headers and thus can be on a response
or a POST request, so they don't make sense here

Location and Vary are both response headers, so they wouldn't be on a
request being checked by CORS

Accept is a request header, but it is already allowed by CORS in
"simple requests," and doesn't trigger a preflight CORS check
<https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#Preflighted_requests>,
so it shouldn't be needed in access-control-allow-headers.


What I'd recommend instead are the following headers:
access-control-allow-headers: If-Match, If-None-Match, If-Modified-Since,
If-Unmodified-Since, If-Range, Range
access-control-allow-methods: GET, HEAD, OPTIONS
access-control-allow-origin: *
access-control-expose-headers: *

Since Apache handles conditional requests
<https://developer.mozilla.org/en-US/docs/Web/HTTP/Conditional_requests> for
us <https://httpd.apache.org/docs/trunk/compliance.html#policyconditional>,
and they can improve performance and help with caching, I think it's
valuable to add them. As indicated in that first link, these headers can
help libraries with caching, but can also allow resumable downloads, which
applies because the server already provides responses with accept-ranges:
bytes

However, if for some reason we didn't want to expose conditional requests
to browsers, we could just use:

access-control-allow-origin: *
access-control-expose-headers: *

as a minimal default. Let me know what you think!

On Sun, Oct 25, 2020 at 3:32 PM Alex Kreidler <alexkreidler2020@gmail.com>
wrote:

> Tomasz, I actually do use your vocabulary package in the app for some
> sections. I do understand those problems you mentioned, but the situation
> in my app is one where the rdf and rdfs ontologies are one out of many
> properties on an object, and the user hovers over the IRI to dereference it
> to get additional data (e.g. a title from rdfs:label). Thus I could
> implement it differently by adding a cache of common ontologies, but I'm
> reaching for the ideal world described in the LInked Data note
> <https://www.w3.org/DesignIssues/LinkedData.html>. In fact, in my mind,
> most of the problems you mentioned would be "good problems to have,"
> because they would indicate significant adoption of linked data technology
> via heavy load on the servers.
>
> Ivan, thanks for your response. I did indeed test locally and the headers
> are the same for rdf-schema as for rdf-syntax-ns. However, the primary
> issue I was running into was that for some reason this header:
> access-control-allow-origin: *
> is present on the regular request but not the one with "Accept:
> application/ld+json" I'm not sure why this would be the case if it's added
> with:
>
> Header set Access-Control-Allow-Origin "*"
>
> to the .htaccess file. This might require some more investigation.
>
> However, I also noticed some other issues with the headers. Firstly I don't see any reason why we need access-control-allow-credentials.
>
> Then, with:
> access-control-allow-headers: Link, Location, Content-Type, Accept, Vary
> the TLDR is that this line doesn't make a difference to browser clients.
>
> Link and Content-Type are entity headers and thus can be on a response or a POST request, so they don't make sense here
>
> Location and Vary are both response headers, so they wouldn't be on a request being checked by CORS
>
> Accept is a request header, but it is already allowed by CORS in "simple requests," and doesn't trigger a preflight CORS check <https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#Preflighted_requests>, so it shouldn't be needed in access-control-allow-headers.
>
>
> What I'd recommend instead are the following headers:
> access-control-allow-headers: If-Match, If-None-Match, If-Modified-Since,
> If-Unmodified-Since, If-Range, Range
> access-control-allow-methods: GET, HEAD, OPTIONS
> access-control-allow-origin: *
> access-control-expose-headers: *
>
> Since Apache handles conditional requests
> <https://developer.mozilla.org/en-US/docs/Web/HTTP/Conditional_requests> for
> us <https://httpd.apache.org/docs/trunk/compliance.html#policyconditional>,
> and they can improve performance and help with caching, I think it's
> valuable to add them. As indicated in that first link, these headers can
> help libraries with caching, but can also allow resumable downloads, which
> applies because the server already provides responses with accept-ranges:
> bytes
>
> However, if for some reason we didn't want to expose conditional requests
> to browsers, we could just use:
>
> access-control-allow-origin: *
> access-control-expose-headers: *
>
> as a minimal default. Let me know what you think!
>
> On Sun, Oct 25, 2020 at 1:48 AM Ivan Herman <ivan@w3.org> wrote:
>
>> Alex,
>>
>> I have added to the relevant .htaccess file the instruction to generate
>> the same CORS headers to rdf-schema as for rdf-syntax-ns. It seems to work
>> on my machine when doing a curl —head; however, I would appreciate if you
>> checked everything on your side, too.
>>
>> Thanks for flagging this.
>>
>> Ivan
>>
>> On 25 Oct 2020, at 02:25, Alex Kreidler <alexkreidler2020@gmail.com>
>> wrote:
>>
>> Sorry, just noticed that the link I provided auto-deletes after 24 hours.
>>
>> I've included the full output of the issue below, along with via another
>> pastebin: https://pastebin.com/Jf3K7DW7
>>
>> $ http HEAD http://www.w3.org/1999/02/22-rdf-syntax-ns#type "Accept: application/ld+json"
>> HTTP/1.1 200 OK
>> accept-ranges: bytes
>> access-control-allow-credentials: true
>> access-control-allow-headers: Link, Location, Content-Type, Accept, Vary
>> access-control-allow-methods: GET, HEAD, OPTIONS
>> access-control-expose-headers: Location, Link, Vary, Last-Modified, ETag, Allow, Content-Length, Accept
>> cache-control: max-age=21600
>> content-length: 9198
>> content-location: 22-rdf-syntax-ns.jsonld
>> content-type: application/ld+json
>> date: Sun, 25 Oct 2020 00:08:07 GMT
>> etag: "23ee-599d39942e300;599d3996211bf"
>> expires: Sun, 25 Oct 2020 06:08:07 GMT
>> last-modified: Mon, 16 Dec 2019 15:09:32 GMT
>> tcn: choice
>> vary: negotiate,accept,accept-charset,upgrade-insecure-requests
>>
>>
>>
>> $ http HEAD http://www.w3.org/1999/02/22-rdf-syntax-ns#type
>> HTTP/1.1 <http://www.w3.org/1999/02/22-rdf-syntax-ns#typeHTTP/1.1> 200 OK
>> accept-ranges: bytes
>> access-control-allow-credentials: true
>> access-control-allow-headers: Link, Location, Content-Type, Accept, Vary
>> access-control-allow-methods: GET, HEAD, OPTIONS
>> access-control-allow-origin: *
>> access-control-expose-headers: Location, Link, Vary, Last-Modified, ETag, Allow, Content-Length, Accept
>> cache-control: max-age=21600
>> content-length: 6004
>> content-location: 22-rdf-syntax-ns.ttl
>> content-type: text/turtle; charset=utf-8
>> date: Sun, 25 Oct 2020 00:08:13 GMT
>> etag: "1774-599d39942e300;599d3996204ea"
>> expires: Sun, 25 Oct 2020 06:08:13 GMT
>> last-modified: Mon, 16 Dec 2019 15:09:32 GMT
>> tcn: choice
>> vary: negotiate,accept,accept-charset,upgrade-insecure-requests
>>
>>
>>
>> $ http HEAD https://www.w3.org/2000/01/rdf-schema#range "Accept: application/ld+json"
>> HTTP/1.1 200 OK
>> accept-ranges: bytes
>> cache-control: max-age=21600
>> content-length: 5604
>> content-location: rdf-schema.jsonld
>> content-security-policy: upgrade-insecure-requests
>> content-type: application/ld+json
>> date: Sun, 25 Oct 2020 00:08:54 GMT
>> etag: "15e4-586929c3ace00;586929c7c4f1d"
>> expires: Sun, 25 Oct 2020 06:08:54 GMT
>> last-modified: Mon, 15 Apr 2019 14:38:48 GMT
>> strict-transport-security: max-age=15552000; includeSubdomains; preload
>> tcn: choice
>> vary: negotiate,accept,accept-charset
>>
>>
>>
>> $ http HEAD https://www.w3.org/2000/01/rdf-schema#range
>> HTTP/1.1 <https://www.w3.org/2000/01/rdf-schema#rangeHTTP/1.1> 200 OK
>> accept-ranges: bytes
>> access-control-allow-origin: *
>> cache-control: max-age=21600
>> content-length: 3812
>> content-location: rdf-schema.ttl
>> content-security-policy: upgrade-insecure-requests
>> content-type: text/turtle; charset=utf-8
>> date: Sun, 25 Oct 2020 00:09:03 GMT
>> etag: "ee4-4f33230d4a800;586929c6c4edd"
>> expires: Sun, 25 Oct 2020 06:09:03 GMT
>> last-modified: Tue, 25 Feb 2014 02:53:20 GMT
>> strict-transport-security: max-age=15552000; includeSubdomains; preload
>> tcn: choice
>> vary: negotiate,accept,accept-charset
>>
>>
>>
>>
>> ----
>> Ivan Herman, W3C
>> Home: http://www.w3.org/People/Ivan/
>> mobile: +33 6 52 46 00 43
>> ORCID ID: https://orcid.org/0000-0003-0782-2704
>>
>>