[
https://issues.apache.org/jira/browse/JENA-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14181265#comment-14181265
]
Osma Suominen commented on JENA-652:
------------------------------------
I haven't tried either in deployment - I just wanted to test SKOSjs locally
(running stock Fuseki 1.1.1 on my laptop) and stumbled on this issue. If I had
to deploy this today, I'd use a Varnish proxy anyway in front of Fuseki, and
it's easy to add HTTP headers with Varnish rules like this:
sub vcl_deliver {
set resp.http.Access-Control-Allow-Origin = "*";
set resp.http.Access-Control-Allow-Headers = "X-Requested-With,
Content-Type, Authorization";
set resp.http.Access-Control-Allow-Methods =
"GET,HEAD,OPTIONS,PUT,DELETE,POST";
}
But for playing around on localhost, I'd rather not install varnish (I did that
anyway now to get SKOSjs to work). There are external solutions like
http://www.corsproxy.com/ but that doesn't work for localhost, and I'd not use
it for real deployments.
I would have tried the Servlet filter if I knew how to set that up, but with no
web.xml in sight (with Fuseki 1.1.1) I didn't know where to start. But I guess
this is a good opportunity to try out Fuseki2 :)
Still I think that the default, even for Fuseki1, should be to just send the
appropriate CORS headers. If it's easy to enable the servlet filter for Fuseki1
I'd prefer that, since it's obviously more flexible than hardcoding the header
values in Java code. But Eetu's patch is much better than doing nothing.
> Fuseki SPARQL update endpoint does not set CORS headers on an OPTIONS request
> -----------------------------------------------------------------------------
>
> Key: JENA-652
> URL: https://issues.apache.org/jira/browse/JENA-652
> Project: Apache Jena
> Issue Type: Bug
> Components: Fuseki
> Affects Versions: Fuseki 1.0.1
> Reporter: Eetu Mäkelä
> Assignee: Andy Seaborne
> Priority: Minor
> Attachments: fuseki-cors.patch
>
>
> Fuseki does not return CORS Allow headers for an OPTIONS request on the
> update endpoint, thus disallowing SPARQL UPDATE requests to be made from
> HTML5 web applications.
> This can probably be fixed just by adding a call to
> {{setCommonHeaders(response);}} into the {{doOptions}} -method of
> {{org.apache.jena.fuseki.servlets.SPARQL_Update}}, identically to how this is
> handled in {{org.apache.jena.fuseki.servlets.SPARQL_Query}} .
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
