search

cedaro / satispress

Expose installed WordPress plugins and themes as Composer packages.
521 stars 51 forks source link

Cache-control headers #204

Closed ethanclevenger91 closed 1 month ago

ethanclevenger91 commented 1 year ago

Had an issue where a host was caching the packages.json endpoint after Composer was able to successfully connect. Subsequent unauthenticated requests, even in-browser, would succeed.

Looking at the response headers, I see that if an unauthorized hit is made, a Cache-Control: no-cache header is returned, presumably because this is a default WP page and WP handles it.

But successful requests to the packages.json endpoint do not return a Cache-Control: no-cache header, and it seems like they should, since this endpoint requires authentication. Should all requests to SatisPress return no-cache headers to signal to services that are eagerly caching endpoints (especially those that present as static content, i.e. a JSON file) not to cache these endpoints?

Thoughts on this? I could look into a PR if someone can verify I'm not crazy.

bradyvercher commented 1 year ago

I believe that header is a directive for the client only (browser, Composer, etc) and doesn't affect the server's caching policy. It sounds like the caching rules need to be adjusted on the server to either account for the Basic authentication header or the SatisPress endpoints.