[
https://issues.apache.org/jira/browse/JENA-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14181242#comment-14181242
]
Andy Seaborne commented on JENA-652:
------------------------------------
Fuseki2 uses web.xml (jena-fuseki2/src/main/webapp/WEB-INF/web.xml)
Have you tired either approaches in deployment? Which is better -
setCommonHeader (Fuseki has to set headers anyway) or a Servlet filter (does
that make it easily switchable?)?
See questions 3/April/2014 (not being a CORS expert, I'm being quite cautious
and also relying on feedback/help here).
> 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)
