Enable HTTP caching (adds Cache-Control and Vary headers, changes some APIs from POST to GET, replaces time= with tz=) #320
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
time
request argument withtz
and proper time zone handling (less request variability, one variant per time zone instead of one per minute of the day). Also adjusts dates as well as times to the user’s time zone.This only enabled caching on some assets, and not any responses that change per-user or based on cookies. It means admins may be confused by their sites not immediately changing when they change a setting that modifies these assets. I decided to focus on the end user and their experience instead. You should’t need to change settings all that often, so this is a much smaller use case anyway. A compromise could be to disable caching for the admins, but this wouldn’t be a true representation of how users experience their sites. (Admins using HashOver are therefor expected to understand caching and how to turn it off in developer tools.)
I thought long and hard about where to put the caching headers. I decided they belonged where they’re used. I figured confused developers would look at the code to figure out why a changed setting didn’t apply as expected. Greeting them with the cache header should explain it, so it’s better for code readability. I can make it a function inside
Setup
instead if you hate this.Bonus sneaking in along with the others:
Sec-CH-UA-Mobile
client hint instead ofUser-Agent
to determine device mobileness (when available; e.g. Edge and Chrome over HTTPS). This is part of the client hints standard and is meant to replace User-Agents in the future. Among other things, it’s better for caching (varying on one boolean vs the entire User-Agent string).Each change is its own commit, so you can merge just the parts you want.