Closed Bug 957383 Opened 11 years ago Closed 9 years ago

Send Cache-Control request headers from Fireplace

Categories

(Marketplace Graveyard :: Consumer Pages, defect, P3)

x86
All
defect

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: cvan, Unassigned)

References

Details

(Keywords: perf, Whiteboard: [marketplace-transition])

Instead of passing ?cache=1 clouserw had wisely suggested we instead send `Cache-Control: max-age=180` as a request header and if we don't want a resource cached we send `Cache-Control: no-cache` (which should probably the default anyway). I like this idea.
Priority: -- → P2
This clashes with the idea of having the CDN serving API responses, unless the CDN supports Vary, right ?
Priority: P2 → --
Priority: -- → P3
Target Milestone: 2014-01-14 → 2014-02-11
Keywords: perf
Summary: Send Cache-Control headers from Fireplace → Send Cache-Control request headers from Fireplace
Whiteboard: [perf]
Assignee: cvan → nobody
Target Milestone: 2014-02-11 → ---
No longer blocks: tarako-marketplace
Blocks: 992365
No longer blocks: 992365
(In reply to Mathieu Pillard [:mat] from comment #1) > This clashes with the idea of having the CDN serving API responses, unless > the CDN supports Vary, right ? The CDN respects any headers we send. If we say cache for an hour, the CDN will cache it for an hour.
It respects any header except `Vary`.
Because the CDN doesn't support Vary, here is what happens: - Client A sends a request with a Cache-Control: max-age=180 header. CDN sees the request, doesn't have it in its cache, let it go through the server. Server returns something, the CDN caches it and returns it to the client. - Then, client B sends a request with Cache-Control: nocache. CDN has the answer from client A, and sends it directly to client B instead of letting it go through the server. When the caching layer / CDN supports Vary, it's not a problem, because it caches as many versions as necessary depending on the headers sent by the client that were in the Vary header of the server responses. But we know that our current CDN does *not* respect Vary.
So we can't tell the CDN to vary on accept-lang? Are there other headers you'd need to vary on? Are the buchets sent as a header?
Buchets and language are sent as a query string to the API. The way I understood it, the CDN actually does Vary on Accept-Language (and Accept-Encoding, possibly others) though.
Jason - can you clarify the last few comments? What headers do the CDNs vary on right now? Sorry this seems to come up every few months, heh. Also, are all our CDNs the same? Seems like we flip between them quite a bit.
Flags: needinfo?(jthomas)
Our CDN honors Vary:Accept-Encoding, Cache-Control and Expires headers. If you send it anything other than Vary:Accept-Encoding it will not cache. We are using Edgecast and Akamai right now and the CDN configuration are the same.
Flags: needinfo?(jthomas)
(In reply to Mathieu Pillard [:mat] from comment #6) > Buchets and language are sent as a query string to the API. The way I > understood it, the CDN actually does Vary on Accept-Language (and > Accept-Encoding, possibly others) though. That's correct that all *Fireplace* endpoints pass `?lang` instead of `Accept-Language`, but there's one public API endpoint (for localised price tiers) that looks at `Accept-Language`: http://firefox-marketplace-api.readthedocs.org/en/latest/topics/payment.html#get--api-v1-webpay-prices-(int-id)- It's not behind a CDN (yet), but something to be aware of.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
Whiteboard: [marketplace-transition]
You need to log in before you can comment on or make changes to this bug.