> Why would any site use the same URIs for API endpoints and frontend/view navigation places?
Simplicity. Ruby on Rails facilitates that approach, for example.
> And in that case should the Content-Type (or Accepts) be the main factor?
Content-Type, yup! Unfortunately Chrome and IE 10 (not sure about Edge) disagree on that.
Without the Vary header, the back button leads to rendering what the server last returned, without taking the Content-Type into account - which is completely nonsensical in my opinion.
Ironically, the section of the HTTP spec they initially referenced in that Chrome bug as justification for closing it as WontFix is precisely the part which explains why Chrome's current behavior is incorrect. Specifically:
> History mechanisms and caches are different. In particular history mechanisms SHOULD NOT try to show a semantically transparent view of the current state of a resource. Rather, a history mechanism is meant to show exactly what the user saw at the time when the resource was retrieved.
Doesn't matter whether a Vary header is sent or not; when a user clicks the back button they should see exactly what they saw when they previously viewed that page; regardless of whether that content is cached or not.
Simplicity. Ruby on Rails facilitates that approach, for example.
> And in that case should the Content-Type (or Accepts) be the main factor?
Content-Type, yup! Unfortunately Chrome and IE 10 (not sure about Edge) disagree on that.
Without the Vary header, the back button leads to rendering what the server last returned, without taking the Content-Type into account - which is completely nonsensical in my opinion.
Chromium bug: https://bugs.chromium.org/p/chromium/issues/detail?id=94369
Repo and page that demonstrate the issue: https://github.com/guilhermesimoes/chrome-bug
This has been going on since at least 2011 so it seems nobody cares.
I honestly do not understand why that Vary header is necessary.
Firefox doesn't seem to need it to render pages from its cache correctly.