rajsite•2y ago

Cache related headers not included in deno deploy for static file serving

I have a hello world level static site using serveDir. When I run the site locally I see that Weak E-Tag headers are included in responses for the static files and can verify in dev tools that caching works. When I deploy the site with deno deploy I don't see any caching and each request sends the full response to the browser. I can see that compression is running as described in the caching documentation but the docs seem to suggest that if Weak E-tags are included (which I assume is the case since that is how serveDir is behaving locally) that I would expect them in the responses. - Any ideas on why deno deploy is not including caching headers in responses? - Related, how can I get insights into the responses of my app before Deno's frontend (i.e. how can debug / confirm my server is still including E-Tags in it's responses before the Deno deploy gateway takes over). Deno deploy caching docs: https://deno.com/deploy/docs/compression#what-happens-to-my-etag-header Example app:

import { serve } from "https://deno.land/std@0.177.0/http/server.ts";
import { serveDir } from "https://deno.land/std@0.177.0/http/file_server.ts";

serve(async (req) => {
    return await serveDir(req);
});

import { serve } from "https://deno.land/std@0.177.0/http/server.ts";
import { serveDir } from "https://deno.land/std@0.177.0/http/file_server.ts";

serve(async (req) => {
    return await serveDir(req);
});

In a directory structure like the following:

index.html
other_static_stuff/
src/main.ts
src/deno.json

index.html
other_static_stuff/
src/main.ts
src/deno.json

Deployed using deployctl with the current directory at the root of the path shown above and pointing to src/main.ts. Can see an example deployed site here showing caching not working: https://rajsite-gnpsdwjvtpk0.deno.dev/

9 Replies

Andreu Botella (they/them)•2y ago

I noticed this as well, but it's not related to Deploy stripping the headers it's because serveDir's handling of Last-Modified and ETag headers depends on the file's last modified timestamp and Deploy's filesystem is virtual and seems to not provide those

Andreu Botella (they/them)•2y ago

https://github.com/denoland/deploy_feedback/issues/334

GitHub

Support querying modification timestamps (mtime) for the Deploy f...

I recently noticed that std/http/file_server.ts in Deploy doesn't add Last-Modified or ETag headers, which results in clients having to redownload the files when they might already have the...

Andreu Botella (they/them)•2y ago

ayame113 then made a PR to change serveDir to use Deploy's deployment ID envvar if it's present so that should probably work on the next release of std although the last modified timestamp will always be that of the last deployment, but that's better than not having it

rajsite•2y ago

Have any approaches on how you figured that out? Logging responses yourself and noticing expected headers weren't present or is there some way to observe that in the deno deploy tooling? Or just source inspection and clever thinking 😛

Andreu Botella (they/them)•2y ago

I noticed that the ETag header weren't present on Deploy but were when running the server locally, and then I searched for "ETag" on the source 😅

rajsite•2y ago

Diving into the source to see what's happening is a lot more approachable in Deno, it's pretty nice. Feels like the deno deploy observability tools have room to grow. But still learning and all very cool!

Andreu Botella (they/them)•2y ago

yeah! to be fair, I already knew that Deploy uses a virtual filesystem, so seeing that those headers were present only when mtime was set made things pretty clear I don't know the details of the virtual filesystem, but I'm quite confident that they use a different implementation of the filesystem lookup than Deno does

rajsite•2y ago

Looking at the PR made me wonder how much of the deno std library had Deno Deploy specific logic in it. Does seem like there is some just searching for deploy but not a huge amount. Hopefully that's something they'll want to avoid growing too much 😅 Thanks for the help @Andreu Botella (he/they) 🙂 Have a good one!

Andreu Botella (they/them)•2y ago

sure!