No, I think the OP is suggesting that the same URL will have been requested in both JSON and HTML formats, and the browser cache is not differentiating between them.
Yes, I understand that, but that seems crazy on multiple levels.
Why the X-Requested-With should be in Vary when the same client did the request? (Yes, I see, Ajax libs populate this field, whereas usual browser navigation doesn't. Makes no sense.)
Why is that resource in cache anyhow, when it should be Cache-Control: no-cache (or at least must-revalidate, but it probably is, but of course that again means that the cache returns the JSON after getting the 304 from the backend, because it doesn't differentiate between responses with different Content-Type)?
It seems to me that the X-Requested-With is again a hack on top of "representational state transfer", because it was easier than trying to use Content-Type.
Why the X-Requested-With should be in Vary when the same client did the request? (Yes, I see, Ajax libs populate this field, whereas usual browser navigation doesn't. Makes no sense.)
Why is that resource in cache anyhow, when it should be Cache-Control: no-cache (or at least must-revalidate, but it probably is, but of course that again means that the cache returns the JSON after getting the 304 from the backend, because it doesn't differentiate between responses with different Content-Type)?
It seems to me that the X-Requested-With is again a hack on top of "representational state transfer", because it was easier than trying to use Content-Type.