[
https://issues.apache.org/jira/browse/SLING-9655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17177022#comment-17177022
]
Bertrand Delacretaz commented on SLING-9655:
--------------------------------------------
h3. HTTP response headers related to caching
I've done a bit of reading of [https://www.ietf.org/rfc/rfc2616.txt] (the
HTTP/1.1 spec) to refresh my understanding of caching headers, here's a summary:
* HTTP/1.1 requires origin servers to send a *Date* header, if possible, with
every response, giving the time at which the response was generated. This is
used by caches to compute the response's age.
* A *Cache-Control: max-age=<nSeconds>* header should be sufficient for basic
caching, but we should also include the "*public*" or "*private*" modifier as
per section _14.9.1 What is Cacheable_. I suppose we'll use "public" for the
anonymous Oak user and "private" for authenticated requests.
[https://developers.google.com/web/fundamentals/performance/get-started/httpcaching-6]
and [https://jakearchibald.com/2016/caching-best-practices/] are good sources
of additional information.
If we want to later use cache duration hints provided by {{SlingDataFetcher}}
services, we should create a utility class for the logic that combines those
hints to generate the caching headers. That might be useful in other parts of
Sling, but we can start with a class in its own package this module and move it
later if needed.
> Caching support for the GraphQL core
> ------------------------------------
>
> Key: SLING-9655
> URL: https://issues.apache.org/jira/browse/SLING-9655
> Project: Sling
> Issue Type: Task
> Components: GraphQL
> Affects Versions: GraphQL Core 0.0.4
> Reporter: Bertrand Delacretaz
> Assignee: Radu Cotescu
> Priority: Major
>
> We've discussed [on our dev
> list|https://lists.apache.org/thread.html/r00652fa5bc54f96bb3ec01264905d9a1f36677a71070fa1b724570f9%40%3Cdev.sling.apache.org%3E]
> how to provide caching support and we'd like to leverage front-end HTTP
> caches that people usually use in front of Sling.
> What we've discussed is:
> * 1) GraphQL queries executed via POST are not cached by Sling
> * 2) Queries can be prepared in advance by POSTing the query text to
> Sling, which returns a "201 created" status with a URL that contains
> the query's digest, like cf81d4
> * 3) Clients run such prepared queries by making GET requests to URLs
> like /graphqlservlet/prepared/cf81d4.json
> * 4) The responses to such prepared queries requests contain HTTP
> Cache headers which might (maybe in later phase) be set from hints supplied
> by data fetchers with configurable defaults.
> * 5) There's no guarantee on how long the prepared queries are stored, a
> client that gets a 404 on a prepared query request must be prepared to
> use the default POST request method or store the prepared query again
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
