Content negotiation in Inertia responses

[SimoneStefani]

In the current Inertia implementation and according to the protocol documentation page, Inertia requests (i.e. requests with the X-Inertia: true header) have the Accept header set to text/html, application/xhtml+xml while the expected response has Content-Type: application/json.

To my understanding this breaks the purpose of content negotiation. In fact certain frameworks (e.g. Ktor) don't accept this scenario and throw 406 Not Acceptable.

Any thoughts around this topic?

[ajnsn]

Hey @SimoneStefani

Yes, Inertia is a rebel. I think the original reason why Inertia masquerades as an HTML request is that Jonathan wanted Inertia to always trigger the backend behavior for a normal HTML request, e.g. Laravel has this unauthenticated method inside the exception Handler which would Inertia requests not redirect to the login page and instead provide a json response.

As you are totally right with your understanding and this would also be mine but I think content negogiation at it's heart is broken. It's getting ignored at all the time. The server can somehow decide what it's willing to send, e.g. client requesting GIF and server responds with an PDF download.

The spec also seems to be very vague in terms of the 406 response. It's more of a "should" than a "must"?

There is also a wiki page at WHATWG that shows you all the downsides. This page is also linked fairly prominently on the MDN page.

[RobertBoes]

This is really interesting, this could also be the root cause of #1013 since Chrome might cache the wrong response because it was requested as an ordinary HTML page

[SimoneStefani]

Thanks for the responses! Totally understand where Inertia comes from and the state of content negotiation. Will look for a workaround for my specific use case.