Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: cache etag support #3758

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

feat: cache etag support #3758

wants to merge 1 commit into from

Conversation

flakey5
Copy link
Member

@flakey5 flakey5 commented Oct 21, 2024

Re http caching, adds support for etags for when we need to revalidate a cached response.

No breaking changes to the public api. the etag property is nullable so a cache store could just not implement it and it will be fine. However, I did add it to the tests as if it was required just so we can ensure the builtin cache stores fully support the behavior.

This only checks if the etag exists in the response's headers and ignores it if it's in the trailers for simplicity sakes (as allowed by the spec in 8.8.3)

Closes #3718


// Check for the response's etag header, ignore if there's multiple
if (typeof headers.etag === 'string') {
value.etag = headers.etag
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't etag be validated here? https://httpwg.org/specs/rfc9110.html#field.etag

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

and also account for weak etags

@mcollina
Copy link
Member

I think this is a bit too light on tests, and I'm not sure if this implementation is correct.

Can you add some tests where the response is a 304 thanks to if-none-match?

@SukkaW
Copy link
Contributor

SukkaW commented Oct 24, 2024

I think this is a bit too light on tests, and I'm not sure if this implementation is correct.

Can you add some tests where the response is a 304 thanks to if-none-match?

Also, we could test how undici responds to different server implementations. I myself have run into situations when locally stored strong ETag matches the server-sent one yet the server is returning the same ETag with 200 instead of 304.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Easier way to attach ETag to If-None-Match after #3562
5 participants