One issue I encounter often-ish is that when I'm on a gitlab page then hit the back button in the browser - I get a bunch of JSON spit onto the page instead of an actual HTML document.
Whats up with that?
Whats up with that?
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.
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.
> 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.
Because they are the same underlying thing...
I mean, I know RoR likes magic very much, but it's not totally surprising to separate the backend from the frontend.
And then use a SPA framework and use Ajax to communicate with the backend via a "REST API", because that simplifies the backend. A lot. You don't have to have views, templates, and so on implemented.
So either the REST API is not a REST API, but a lot of interesting endpoints for the frontend dynamic JS magic, or the frontend is not a frontend, just a lot of glitter thrown up on a REST API.
(I quickly tried to get something in JSON from a GitLab URL, but I just get a HTTP 406. :( )
As someone who hacks on a SaaS with a sprawling feature set which ships often, I understand where you're coming from. But I would recommend giving things like that some thought.
A sign of the future. As browser march headlong into being app platforms instead of browsers expect the back button to disappear entirely.