Closed Bug 1408477 Opened 7 years ago Closed 7 years ago

Add Cache-Control, Pragma headers in tc-lib-app or maybe tc-lib-api

Categories

(Taskcluster :: Services, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: dustin, Assigned: dustin)

References

Details

It seems weird that for idempotent requests you would want to disable caching.
Yeah, I need to look at what we're doing now and what we want to do.
We don't currently set any cache control headers in tc-lib-app or tc-lib-api.

This ZAP check would require that it be set to 'no-store no-cache must-revalidate'.  The default when the cache-control header is omitted is "private", which is not the same as "no-cache":

> Indicates that the response is intended for a single user and must not be stored by a shared cache.
> A private cache may store the response.

So the options are:

 1) Change nothing in services, ask that ZAP stop making this particular check for our APIs
 2) Set no-store no-cache must-revalidate unconditionally for all API methods
 3) Set more detailed cache headers for some GET requests (but not all..)

Jonas, thoughts?  I don't want to make this a project, so IMHO the choice is between 1 and 2, in other words between "private" and "no-store no-cache must-revalidate".
Flags: needinfo?(jopsen)
I agree with Eli that it's weird to forbid caching.
We could plausibly infer "public" from whether scopes is required.

But since payloads are small and cost of checking if the data have changed is equal to fetching, I suggest we just do:
  'no-store no-cache must-revalidate'
That's is definitely safe, setting a better cache header is an optimization we can do that some other day.
Flags: needinfo?(jopsen)
#2 it is!
The `Pragma` header is only checked for no-cache if it exists, so no need to do anything there.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Component: Platform Libraries → Services
You need to log in before you can comment on or make changes to this bug.