[fix] support etag W/ prefix

[mkorobkov]

Remove W/ prefix from if-none-match header value before comparing with body hash.

Before submitting the PR, please make sure you do the following

• It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
• This message body should clearly illustrate what problems it solves.
• Ideally, include a test that fails without this PR but passes with it.

Tests

• Run the tests with pnpm test and lint the project with pnpm lint and pnpm check

Changesets

• If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running pnpx changeset and following the prompts. All changesets should be patch until SvelteKit 1.0

[changeset-bot]

🦋 Changeset detected

Latest commit: ed8b155

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@sveltejs/kit	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[Rich-Harris]

Thanks — just to clarify, is this something you've encountered? From the MDN docs it seems like W/ is redundant, are you saying that there are user agents that add it anyway?

Also, mind adding a changeset to the PR so that it causes a version bump? Thank you

[mkorobkov]

Thanks — just to clarify, is this something you've encountered? From the MDN docs it seems like W/ is redundant, are you saying that there are user agents that add it anyway?

Also, mind adding a changeset to the PR so that it causes a version bump? Thank you

Hi, Richard. Sorry for the delay in reply.
As I understood, it depends on server response, not user agent.

I have encountered it while using cloudflare workers. It returns weak etag if request contains "Accept-Encoding: gzip" header(I have not investigated the reason why they do this).

curl -v "https://postify.online/_app/error.svelte-315d5cf3.js" 2>&1 | grep etag
prints: < etag: "_app/error.svelte-315d5cf3.dcb826ff86.js"

curl -v -H "Accept-Encoding: gzip" "https://postify.online/_app/error.svelte-315d5cf3.js" 2>&1 | grep etag
prints: < etag: W/"_app/error.svelte-315d5cf3.dcb826ff86.js"

[Fedeorlandau]

Thanks — just to clarify, is this something you've encountered? From the MDN docs it seems like W/ is redundant, are you saying that there are user agents that add it anyway?
Also, mind adding a changeset to the PR so that it causes a version bump? Thank you

Hi, Richard. Sorry for the delay in reply. As I understood, it depends on server response, not user agent.

I have encountered it while using cloudflare workers. It returns weak etag if request contains "Accept-Encoding: gzip" header(I have not investigated the reason why they do this).

curl -v "https://postify.online/_app/error.svelte-315d5cf3.js" 2>&1 | grep etag prints: < etag: "_app/error.svelte-315d5cf3.dcb826ff86.js"

curl -v -H "Accept-Encoding: gzip" "https://postify.online/_app/error.svelte-315d5cf3.js" 2>&1 | grep etag prints: < etag: W/"_app/error.svelte-315d5cf3.dcb826ff86.js"

Hi, @mkorobkov looks like Nginx converts your Etags into weak ones if you ask it to gzip your content.
https://github.com/nginx/nginx/blob/3334585539168947650a37d74dd32973ab451d70/src/http/modules/ngx_http_gzip_filter_module.c#L291 and https://stackoverflow.com/a/51975550

[Rich-Harris]

got it. thank you!