[
https://issues.apache.org/jira/browse/JENA-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13566706#comment-13566706
]
Rob Vesse edited comment on JENA-388 at 1/30/13 6:11 PM:
---------------------------------------------------------
I started playing with this, I had the same thought as you that using the index
as the source of the Last Modified really doesn't work in the general case.
I think Expires works if you keep the expiry sufficiently short, I was thinking
something in the region of 10 seconds with configurability so users can tune
this as necessary.
Presumably the main case for caching is either for read-only servers where you
might have highly repetitive query loads e.g. backend for some
application/presentation logic and you can whack the expiry up high? Lee can
you comment more on your usage scenarios?
When updates get involved things start to get a lot hairier, though maybe if
you want to turn caching on your understand the associated risks of seeing
stale data and can tolerate that? Again Lee do you have comments on this?
was (Author: rvesse):
I started playing with this, I had the same thought as you that using the
index as the source of the Last Modified really doesn't work in the general
case.
I think Expires works if you keep the expiry sufficiently short, I was thinking
something in the region of 10 seconds with configurability so users can tune
this as necessary.
Presumably the main case for caching is either for read-only servers where you
can whack the expiry up high? Lee can you comment more on your usage scenarios?
When updates get involved things start to get a lot hairier, though maybe if
you want to turn caching on your understand the associated risks of seeing
stale data and can tolerate that? Again Lee do you have comments on this?
> 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
