[
https://issues.apache.org/jira/browse/JENA-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13966876#comment-13966876
]
Andy Seaborne commented on JENA-388:
------------------------------------
Maybe, maybe not. The handling of requests and the general internal
architecture has not changed in Fuseki2 although the classes implementing have
been cleaned up to abstract the request lifecycle and put logging on a
systematic basis.
What changes were in progress? Even if it's just a sketch of the changes
needed (in terms of Fuseki1), I can use that to get the feature into Fuseki2.
> 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)
