Possible bug? Getting etag from example.com using fetch() is not possible

I am trying to debug an issue where my reverse proxy does not transfer the headers from the origin (like the e-tag). As an example:

const originalResponse = await fetch('https://example.com');
console.log('etag is:', originalResponse.headers.get('etag')); // will return "null" even though if you do a curl -I https://example.com you'll see an etag header

I also tried doing this: console.log('headers:', JSON.stringify(Object.fromEntries(originalResponse.headers))); but that returns:

headers: {"age":"336467","cache-control":"max-age=604800","cf-cache-status":"DYNAMIC","cf-ray":"639b2841144910b5-CPH","cf-request-id":"0934d77caf000010b58434d000000001","connection":"keep-alive","content-type":"text/html; charset=UTF-8","date":"Fri, 02 Apr 2021 15:40:43 GMT","expect-ct":"max-age=604800, report-uri=\"https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct\"","expires":"Fri, 09 Apr 2021 15:40:43 GMT","last-modified":"Thu, 17 Oct 2019 07:18:26 GMT","server":"cloudflare","transfer-encoding":"chunked","vary":"Accept-Encoding","x-cache":"HIT"}

Which is very weird, because if I do a curl to example.com these are the headers I get:

> curl -I https://example.com
HTTP/2 200
content-encoding: gzip
accept-ranges: bytes
age: 549707
cache-control: max-age=604800
content-type: text/html; charset=UTF-8
date: Fri, 02 Apr 2021 15:41:50 GMT
etag: "3147526947"
expires: Fri, 09 Apr 2021 15:41:50 GMT
last-modified: Thu, 17 Oct 2019 07:18:26 GMT
server: ECS (dcb/7F82)
x-cache: HIT
content-length: 648

Why doesn’t fetch() return the etag headers (or any other header for that matter)?

I also made an example repo here: GitHub - simplenotezy/etagtest: Cloudflare Workers e-tag demo example test

If you run wrangler dev and check in the response, the etag will be null. However, if you try on the playground, it is not: Cloudflare Workers


null when deployed

Unsure if bumps are allowed, anyhow, here goes. Hope somebody can help me with a solution…

1 Like

Flagging @MoreHelp is a good way to draw attention to unanswered posts after a few days.

2 Likes

Thanks for the flag. I’ll stay patiently and eagerly waiting :wink:

You could also ping the team over on their discord server, they’re pretty busy this week with #DeveloperWeek going on this week.

2 Likes

thanks! doing it as we speak. Hopefully I’ll receive an answer soon :blush:

1 Like

Let us know how it works out!

Hello @cloonan. Just an update from me.

So far I have tried with a Cloudflare Workers teammember to diagnose. We found out that on every request, my origin’s etag was changing (because of some Math.random() logic).

Our theory was that Cloudflare would eventually notice that the etags would differ from every request, and thus in the end, start stripping it off / ignoring it. Although it may be a long shot, it tells something about how deep we have gone into the debugging of this weird behaviour from CloudFlare…

I have now waited a few days, and I can tell that the etag header is still not being sent over. If I contact Cloudflare Support about this, they will tell me to look into the documentation, but I think that’s just a standard reply they send to everyone.

Nevertheless, it is quite frustrating since we have a lot of users with errors, because the browser does not have the etag, and thus will be served an old no-longer-working version of the page from their browser cache, which results in a broken site.

I really hope we’ll find a solution to this sooner rather than later.

Apart from the weird behavior in this case (where e-tags is simply not being forwarded), I have an equally weird case where headers are not returned on the second response: Workers strips off important headers on cached responses

The two issues might be related.

I really hope someone from CF could take a look at this issue at some point.