I’m working on a Nuxt 3 project where I’ve implemented some server APIs that return ETag headers. Locally, everything works perfectly in both build and dev environments, with the ETag being consistently returned. However, after deploying to Vercel, I’ve noticed that some APIs return the ETag header, while others do not. For instance, the /api/wt on my website www.leoon.cn returns the ETag, but other api do not. I’ve observed that the x-vercel-cache header shows a difference between hit and miss.
I’m not sure how to address this issue. My goal is to have all APIs return the ETag header so that I can manage caching based on the ETag, rather than leaving it up to Vercel. Could you please advise me on how to ensure consistent ETag header returns for all my APIs?
// Here's how I set up the etag
import type { EventHandler, EventHandlerRequest } from 'h3'
Preformatted text
export const defineWrappedResponseHandler = <T extends EventHandlerRequest, D>(
handler: EventHandler<T, D>
): EventHandler<T, D> =>
defineEventHandler<T>(async event => {
try {
const requestETag = getHeader(event, 'if-none-match')
const response = await handler(event)
const resJson = JSON.stringify(response);
const etag = generateETag(resJson);
setHeader(event, 'ETag', etag);
if (requestETag && requestETag === etag) {
event.node.res.statusCode = 304;
event.node.res.end();
return;
}
return response
} catch (err) {
return { err }
}
})
Thanks for your patience. I know it’s been a few days, I was wondering how have you got on with this?
In case you’re still looking for debugging steps, I recommend the following:
Check for Middleware or Edge Functions: Make sure that there are no middleware or edge functions that might be altering or removing the ETag headers. Sometimes, these can interfere with the headers set by your application.
Consistent Header Setting: Make sure that the ETag header is being set consistently across all your API routes. In your provided code, you are setting the ETag header within a custom response handler. Ensure that this handler is applied to all your API routes.
Vercel Cache Headers: The x-vercel-cache header indicating hit or miss suggests that Vercel’s caching mechanism is in play. When the cache is a hit, the response might be served from the cache, potentially bypassing your custom ETag logic. To manage this, you can configure your cache settings in the vercel.json file to ensure that your ETag headers are respected.
Debugging and Logs: Add logging to your API routes to verify that the ETag headers are being set correctly before the response is sent.
If the issue persists, could you create a minimal reproduction example for us to help in diagnose further? Let us know how you get on!
I tried the third situation you mentioned, but it failed. He still didn’t return. I now provide a minimal example, hoping to get your help, thank you! ! !
When developing locally, you can see that etag is returned, but it is not returned when building to vercel. I don’t know what to do.
