[
https://issues.apache.org/jira/browse/JENA-388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Vesse reassigned JENA-388:
------------------------------
Assignee: (was: Rob Vesse)
Relinquishing assignment
I strongly suspect my previous efforts to look into this are likely rendered
obsolete by [~andy.seaborne] and [~ijd] work on Fuseki 2 (JENA-420)
> 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
>
> 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 was sent by Atlassian JIRA
(v6.2#6252)
