MicrosoftDocs
Azure Frontdoor Cache - Request headers - missing information about dropping `Accept*` headers
Hey, thanks for your good work!
I recently configured Frontdoor with cache, and I came upon a problem with Accept header. Tracking it down, it looks like the Frontdoor does not pass this header to backend as well - and this is probably missing in docs.
I found a response from your technical support, that shows it is not only Accept but rather Accept* headers:
https://docs.microsoft.com/en-us/answers/questions/422192/azure-front-door-does-not-forward-accept-language.html
The specific docs part is: https://docs.microsoft.com/en-us/azure/frontdoor/front-door-caching#request-headers
I can PR a change, but you would have to elaborate on how it actually works.
@viters Thank you for sharing feedback.
@duongau Could you please validate feedback and enhance document as appropriate.
@ShaikMaheer-MSFT Is there a workaround for this? I have a NextJS site behind Front Door that requires the Accept header be forwarded through on image requests so that it knows whether it can return an optimized webp image rather than the default jpeg. This is part of the default NextJS image optimization.
It's also not clear from the docs whether Front Door would vary the caching based on the Vary: Accept header being returned in responses from the /_next/image endpoint. Does Front Door support Vary: Accept to cache content for the same URI separately?
Even if passing the Accept header through was fixed, if you don't support the Vary response header, I would need to rewrite the query strings to add &accept=image/webp to the URL so that the different requests are cached separately.
I can't see a way to do this, since Front Door only supports path rewriting?
I would want to rewrite
https://domain/_next/image?url=%2F_next%2Fstatic%2Fmedia%2Fbackground.34614e4f.jpg
to
https://domain/_next/image?url=%2F_next%2Fstatic%2Fmedia%2Fbackground.34614e4f.jpg&accept=image/webp
based on
Request Accept header containing image/webp.
@jrestall Hey, that's exactly the same issue I had to tackle!
Afaik, Frontdoor CDN does not respect the Vary headers. It's really a pity, because it results in kinda troublesome experience while configuring the cache policy and it results in limited places where cache can be utilized.
Although for this specific problem, I've found a reasonable solution. According to caniuse.com >90% browsers support webp (especially now that Safari does support it as well). I decided to serve only webp via CDN, and - as fallback - if user sends a request without specifying support for webp, I bypass the cache and process the request on nextjs server directly.
As Azure Frontdoor removes Accept headers, you need to define rules to rewrite headers. My idea was:
If Accept header contains image/webp then force nextjs to serve webp and cache it. To achieve it I have created a header X-Force-Webp. If Accept header does not contain image/webp - bypass cache and serve whatever nextjs wants to serve. Then I had to process X-Force-Webp on my infrastructure - you can try to proxy nextjs image requests, or change the nextjs image optimization behavior (to process that additional header), or you can do it on some load balancer before nextjs. I went with the former, because I had ORY Oathkeeper in my infrastructure already, the actual solution onwards is described here https://github.com/ory/oathkeeper/discussions/901.
Frontdoor rules:
Regarding your idea with URL, I did not think about that, although I do not know if rewriting the URLs is possible via the Frontdoor rules and how it would affect the cache (whether it will be respected or not). Give a try and letme know, because it would be an easier solution without need to modify the rest of request processing on the app / infra side.
I'm needing this for the support of webp also. Stripping Accept header is still missing in the docs.
Did anyone come up with at nice solution to this? We are experience the same issue..
Thinking of disable the CDN cache for images and let Next to handle the caching of them instead, not optimal though.
Thank you for you dedication to our documentation.
Unfortunately, we have been unable to review this issue in a timely manner. We sincerely apologize for the delayed response. We will create an internal tracking work item to address this issue. For now, we are closing this issue. If you have any additional information you would like to provide, please respond to this issue with any additional details.
Please continue to provide feedback about the documentation. We appreciate your contributions to our community.
#please-close
