[jira] [Commented] (JENA-388) Make Fuseki responses cacheable

["A. Soroka (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/JENA-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14605596#comment-14605596 ] 

A. Soroka commented on JENA-388:
--------------------------------

I don't see {{DatasetRef}} any more in Fuseki 2. Is that still the right hanging point for a per-Dataset ETag implementation, or is it {{DataService}} now?

> 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.3.4#6332)