Send HTTP Vary hints to caches when varying on HTTP request headers.
Enable caching for static script assets for the Comment, Count, and Latest APIs. These are mostly static, except when the admin changes server setting. Clients cache for 30 min and use stale while async revalidation for 1 day.
Support methods other than POST and PUT in ajax.js.
The Count and Latest APIs responses also get short-lived cache headers and switches from POST to GET.
Replaces time request argument with tz 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.
Removed some ancient cache control headers and focus on the ones that work. (HTTP/1.0+ compatible.)
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:
Use the modern Sec-CH-UA-Mobile client hint instead of User-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.
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.