[
https://issues.apache.org/jira/browse/JENA-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13566596#comment-13566596
]
Leigh Dodds commented on JENA-388:
----------------------------------
Yes, having it configurable makes sense, and happy to enable it where required.
> Make Fuseki responses cacheable
> -------------------------------
>
> Key: JENA-388
> URL: https://issues.apache.org/jira/browse/JENA-388
> Project: Apache Jena
> Issue Type: Improvement
> Components: Fuseki
> Affects Versions: Fuseki 0.2.5
> Reporter: Leigh Dodds
> Assignee: Rob Vesse
> Fix For: Fuseki 0.2.6
>
>
> Fuseki currently sets Pragma and Cache-Control: No-Cache headers on all
> responses. This effectively disables all client side caching.
> While some public caching and caching proxies may not typically cache GET
> requests with parameters, this is changing (I believe the Squid default has
> changed, or is due to).
> This is more of an issue when using caches within system, e.g. between a user
> facing app and the fuseki instance. Some HTTP libraries support caching and
> rely on caching headers to control that.
> Fuseki could instead return Last-Modified dates + ETags (e.g. a hash of the
> Last-Modified). This would allow clients to perform Conditional GET requests
> and receive a 304 response if the store hasn't been updated.
> For read-only servers the Last-Modified date is the date on the index files.
> For read-write servers the date of the last transaction could be used.
> Alternatively an Expires header could be served, allowing clients to face for
> a specific period, but this ought to be configurable in the Fuseki config to
> allow for administrator control.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
