1054472 - Use ETags to determine when the snippets service can send 304s in response to snippet requests

Status: RESOLVED FIXED

(Snippets :: Service, defect)

Description

[Osmose [:osmose, :mkelly]]

Attachment: Flowchart of ETag Logic

We'd like to add ETags to outgoing snippet service responses that contain a hash of the content being sent. The service can then use that ETag to determine what snippet content the user currently has and whether they need new content delivered or can reuse the content they have.

Attached is a flowchart illustrating the behavior that we want.

Comment 1

[Osmose [:osmose, :mkelly]]

jakem: Is there any easy way for you to test if Zeus can vary on ETags? Or, is the dev server behind Zeus such that I can just test there?

Comment 2

[Osmose [:osmose, :mkelly]]

(In reply to Michael Kelly [:mkelly,:Osmose] from comment #1)
> jakem: Is there any easy way for you to test if Zeus can vary on ETags? Or,
> is the dev server behind Zeus such that I can just test there?

Confirmed over IRC that snippets-dev is behind Zeus and caching is enabled, allowing us to test there.

Comment 3

[Osmose [:osmose, :mkelly]]

Attachment: Github pull request

Comment 4

[[github robot]]

Commit pushed to master at https://github.com/mozilla/snippets-service

https://github.com/mozilla/snippets-service/commit/b12f537e8f9b1de80dcc86d0814222d8cd595887
Fix bug 1054472: Use ETags to determine if we can send 304s.

Changes the fetch_snippets view to add ETags to outgoing responses that
are a hash of their content. It then uses the incoming ETags from
clients to determine what snippet content the client currently has 
cached, and whether new snippet content needs to be delivered or if a
304 can be sent to instruct the client to use their cached snippets.

This should allow us to increase the frequency of updates by lowering
the amount of data we need to send.

Comment 5

[Osmose [:osmose, :mkelly]]

Reopening. From an email conversation:

> But after testing and thinking, I noticed that the browser cached 
> response goes away at the same time Zeus stops caching the response
> since they're both based on the max-age of the response. In other words,
> by the time Zeus allows users to hit snippets on a URL after it's been
> cached, they don't have the ETag cached anymore and the service won't
> respond with a 304.
> 
> (Which is good in a way, if the service ever returned a 304 Zeus
> wouldn't cache it, which is another thing I learned.)
> 
> What this means is that, since users will not have an ETag when they get
> through Zeus and hit the server, any logic on the server for returning a
> 304 is moot and unnecessary.

Thus we are simply going to add support for adding an ETag to the response and vary of If-None-Match so that Zeus will return 304s on its own.

Comment 6

[[github robot]]

Commits pushed to master at https://github.com/mozilla/snippets-service

https://github.com/mozilla/snippets-service/commit/a3c2197bd49c34faf1a1d9e68b3da604bea6f92e
Revert "Fix bug 1054472: Use ETags to determine if we can send 304s."

This reverts commit b12f537e8f9b1de80dcc86d0814222d8cd595887.

https://github.com/mozilla/snippets-service/commit/ab74a8c241fde8f79f7c433aac58ddbde27740e3
Fix bug 1054472: Add ETag header to responses.