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

["Rob Vesse (JIRA)" <ji...@apache.org>]

    [ 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