Compare commits
No commits in common. "9d5d602c046568301a4e0341a43b93c753daa033" and "985777a1e95426f22c58ec0861c54aa68787d98e" have entirely different histories.
9d5d602c04
...
985777a1e9
7
.gitmodules
vendored
7
.gitmodules
vendored
|
@ -1,3 +1,6 @@
|
|||
[submodule "themes/hello-friend-ng"]
|
||||
path = themes/hello-friend-ng
|
||||
url = https://github.com/rhazdon/hugo-theme-hello-friend-ng.git
|
||||
[submodule "themes/catafalque"]
|
||||
path = themes/catafalque
|
||||
url = https://github.com/SeriousBug/hugo-theme-catafalque.git
|
||||
path = themes/catafalque
|
||||
url = git@github.com:SeriousBug/hugo-theme-catafalque.git
|
||||
|
|
|
@ -1,12 +0,0 @@
|
|||
clone:
|
||||
git:
|
||||
image: woodpeckerci/plugin-git
|
||||
settings:
|
||||
recursive: true
|
||||
|
||||
pipeline:
|
||||
build:
|
||||
image: klakegg/hugo:ext-alpine
|
||||
commands:
|
||||
- hugo -D
|
||||
- ls -lAh
|
|
@ -62,7 +62,7 @@ images = [""]
|
|||
# Home subtitle of the index page.
|
||||
#
|
||||
homeSubtitle = [
|
||||
"Hi! I'm a Software Engineer, an avid Linux user, an enthusiast of many programming languages, a <a href='/recipes'>home cook</a>, and an amateur gardener.",
|
||||
"Hi! I'm a Software Engineer at <a href='https://dendron.so'>Dendron</a>, and a recent Master's graduate from <a href='https://osu.edu'>the Ohio State University</a>. I'm an avid Linux user, an enthusiast of many programming languages, a <a href='/recipes'>home cook</a>, and an amateur gardener.",
|
||||
"My interests include building web and mobile applications, both front and back end. Over the years I learned and used many programming languages and technologies, including JavaScript, TypeScript, React, React Native, Python, Java, C, C++, Clojure, Rust, and Haskell. Pretty much everthing I've worked on is open source and available on <a href='https://github.com/SeriousBug/'>my Github page</a>.",
|
||||
]
|
||||
|
||||
|
@ -171,7 +171,7 @@ url = "https://github.com/SeriousBug/"
|
|||
|
||||
[[params.social]]
|
||||
name = "mastodon"
|
||||
url = "https://fosstodon.org/@kaan"
|
||||
url = "https://mastodon.technology/@kaan"
|
||||
me = true
|
||||
|
||||
[[params.social]]
|
||||
|
|
BIN
content/img/browser-caching-after.png
(Stored with Git LFS)
BIN
content/img/browser-caching-after.png
(Stored with Git LFS)
Binary file not shown.
BIN
content/img/browser-caching-before.png
(Stored with Git LFS)
BIN
content/img/browser-caching-before.png
(Stored with Git LFS)
Binary file not shown.
|
@ -1,47 +0,0 @@
|
|||
---
|
||||
title: "Browser Caching: Assets not revalidated when server sends a 304 'Not Modified' for html page"
|
||||
date: 2022-10-15T20:56:36-04:00
|
||||
toc: false
|
||||
images:
|
||||
tags:
|
||||
- dev
|
||||
- web
|
||||
---
|
||||
|
||||
I've been working on some web server middleware, and hit a weird issue that I
|
||||
couldn't find documented anywhere. First, let's look at an overview of how
|
||||
browser caching works:
|
||||
|
||||
If your web server sends an
|
||||
[ETag](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ETag) header in
|
||||
a HTTP response, the web browser may choose to cache the response. Next time the
|
||||
same object is requested, the browser may add an
|
||||
[If-None-Match](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-None-Match)
|
||||
header to let the server know that the browser might have the object cached. At this point, the server should respond with the
|
||||
[304 Not Modified](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/304)
|
||||
code and skip sending the response. This can also happen with the
|
||||
[Last Modified](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Last-Modified)
|
||||
and
|
||||
[If-Modified-Since](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/If-Modified-Since)
|
||||
headers if `ETag` is not supported as well.
|
||||
|
||||
After implementing this in my middleware, I made a quick test website to try it
|
||||
out. That's when I ran into a weird behavior: the browser would revalidate the
|
||||
HTML page itself with the `If-None-Match` header, but when the server responded
|
||||
with `304` it would not attempt to revalidate the linked stylesheets, scripts,
|
||||
and images. The browser would not request them at all and immediately use the
|
||||
cached version. It looks like if the server responds with `304` on the HTML
|
||||
page, the browser assumes that all the linked assets are not modified as well.
|
||||
That means that if the asset does change (you weren't using something like
|
||||
fingerprinting or versioning on your assets), then the browser will use outdated
|
||||
assets. Oops!
|
||||
|
||||
Luckily it looks like there's an easy solution: add `Cache-Control: no-cache`
|
||||
header to your responses. `no-cache` doesn't actually mean "don't cache at all",
|
||||
but rather means that the browser needs to revalidate objects before using
|
||||
the cached version.
|
||||
|
||||
Without the `Cache-Control` header:
|
||||
![Browser developer tools window, there is only 1 request for /](/img/browser-caching-before.png)
|
||||
With the `Cache-Control` header:
|
||||
![Browser developer tools window, there are 5 requests in total, including /, style.css, and 3 images.](/img/browser-caching-after.png)
|
Loading…
Reference in a new issue