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)
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.
Updated•11 years ago
|
Priority: -- → P2
Comment 1•11 years ago
|
||
This clashes with the idea of having the CDN serving API responses, unless the CDN supports Vary, right ?
Priority: P2 → --
Reporter | ||
Updated•11 years ago
|
Priority: -- → P3
Target Milestone: 2014-01-14 → 2014-02-11
Reporter | ||
Updated•11 years ago
|
Keywords: perf
Summary: Send Cache-Control headers from Fireplace → Send Cache-Control request headers from Fireplace
Whiteboard: [perf]
Reporter | ||
Updated•11 years ago
|
Assignee: cvan → nobody
Target Milestone: 2014-02-11 → ---
Updated•11 years ago
|
Blocks: tarako-marketplace
Updated•11 years ago
|
No longer blocks: tarako-marketplace
Comment 2•10 years ago
|
||
(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.
Reporter | ||
Comment 3•10 years ago
|
||
It respects any header except `Vary`.
Comment 4•10 years ago
|
||
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.
Comment 5•10 years ago
|
||
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?
Comment 6•10 years ago
|
||
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.
Comment 7•10 years ago
|
||
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)
Comment 8•10 years ago
|
||
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)
Reporter | ||
Comment 9•10 years ago
|
||
(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.
Updated•10 years ago
|
Blocks: marketplace-perf
Updated•9 years ago
|
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.
Description
•