Hi Radu and Bertrand,
The only thing left here is the private caching. The queries run in
authenticated environment and if the CDN does not support private caching then
I guess it has to be supported by sling right?
Regards,
Andreea
On 10/08/2020, 12:15, "Bertrand Delacretaz" <bdelacre...@apache.org> wrote:
Hi Radu,
On Mon, Aug 10, 2020 at 10:54 AM Radu Cotescu <r...@apache.org> wrote:
> > On 7 Aug 2020, at 16:18, Bertrand Delacretaz <bdelacre...@apache.org>
wrote:
...
> > 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
>
> Instead of replying with a 404 and asking the client to do another POST +
GET, couldn’t we just return the
> updated results with updated cache headers?
> Judging by how you describe the algorithm, the Sling server would still
have to maintain a cache internally...
I wasn't planning to store the query results on the Sling side, just
the query itself and enough information to be able to process
conditional HTTP requests.
So a complete scenario could be like
1. Client wants to run a query with digest cf81d4 (computed according
to a definition that we publish)
2. Client GETs /prepared/cf81d4.json and receives a 404 as the query
store is empty
3. Client POSTs the query to /prepared and receives a 201 created
/prepared/cf81d4.json
4. Client GETs /prepared/cf81d4.json and receives the results along
with ETag and Cache-Control headers which allow a front-end HTTP cache
to store it
5. Later, the same or another client GETs /prepared/cf81d4.json
through the HTTP cache, which based on headers received at 4. serves
results from cache and does not touch Sling
6. Later, the same or another client GETs /prepared/cf81d4.json, the
results caching period expired but Sling still has that query stored,
so it runs the query again and returns a new ETag
7. If a request comes later with an expired cache and the cf81d4 query
has been purged, Sling returns a 404 and the client has to start over
a 2.
With this scenario (assuming it works, your sanity check of that is
welcome) Sling just needs to store the queries, ETag and cache
expiration time, which I suppose is much less than query results?
-Bertrand
