Hi, @dicta. That is an important detail and thank you for mentioning it.
I suspected the same thing back on 2022-03-11 and tested to confirm. Once confirmed I did add a note to this effect to the issue filed, quoted below:
I just re-ran the command I get all 304s so this looks like it only happens for uncached content.
To summarize, I completely agree about the root cause and the issue does include that detail. It is a key detail so if I had missed this is a very important reminder. Thanks again for double checking about that!
Hi, @dicta. I wanted to follow-up that this behavior is not going to change anytime soon. We do acknowledge that it is occurring. However, while this is not ideal behavior, it isn’t breaking anything so it will remain a low priority - likely indefinitely.
If you disagree or if you notice some negative impact of this behavior, please let us know.
Thanks for getting back to us. I understand that it’s not causing sites to actually fail. I just wanted to note two things: one, a repeat visitor will come back and find the site loads unnecessarily slowly, because it will download much more data than it should, which means Netlify is leaving performance on the table. The other is that this wastes bandwidth, both for Netlify and for customers, again since the download is larger than it should be. It seems a shame that Netlify can’t get this fixed. In our particular case, a user looking through pages of document that have a lot of data can’t quickly look forward to the next page and then return to the previous page, since the download of the previous page starts from scratch. (I suppose we can do our own caching in a service worker, but it’s extra engineering for something that should just simply work.)
Hi, @dicta. I agree that the 200 response should not happen when the if-none-match header matches the etag. The situations here isn’t that this cannot be fixed. It is that this issue isn’t as high a priority as other bugs or feature requests at this time.
I would also like to see this fixed. However, as I knew it wouldn’t happen soon I wanted to be transparent with you about that timeline.
Chiming in to say that I’m seeing the behaviour as described in this topic, so I assume that this hasn’t been fixed, two years later. I understand the need to prioritise, but this should be fixed.
Hi, @bep. Is this issue causing some major impact for your sites or account? I ask because it shouldn’t be causing any problems (none at all) for site visitors nor impacting your account in any way. However, if I’m mistaken, please do let us know what impact this is causing you.
It may also help to clarify this to take a look at some of the factors that are being used to prioritize this issue:
only three people have reported this in a time window of over three years (less than one person per year)
the issue doesn’t cause any user facing problems nor does it break sites in any way
the issue occurs rarely and only happens for uncached content on low traffic sites (so it does not greatly impact bandwidth use)
fixing the issue is complex and would require non-trivial infrastructure changes
There is next to zero user facing impact and a high cost to fix. Based on these factors above, it is a low priority issue and unlikely to be fixed anytime soon.
However, if you believe any of the factors above are untrue (for example, it is breaking your site) or if they should be discounted for any reason, please let us know. Likewise, if there are questions, please reply here anytime and we’ll do our best to answer them.