Should History API fallback use HTTP content negotiation?

[ezzatron]

Hey there, I was looking at the implementation here as a I guide for the correct way to implement fallback in my own application. I noticed this package is using HTTP content negotiation. I had considered that approach myself in the past, since it seems to work nicely to avoid getting served HTML in inappropriate contexts. But I have some concerns that maybe there are problems with the approach too.

I went to the trouble of writing up a StackOverflow question going into more detail. I thought you might be interested, seeing as this package is probably the most popular implementation of History API fallback in the JS ecosystem.

To summarize, my concerns are mostly around the use of 404 responses instead of 406 responses when a request indicates that HTML is not acceptable, and also potential HTTP caching issues arising from not utilizing the Vary header to indicate that the response must be cached independently for each value of the request's Accept header. In particular, these two things don't really seem to match up with how HTTP content negotiation is intended to work.

Anyway, I was wondering if you had some insight about the content negotiation aspect of the implementation in this package. Maybe there's something I'm misunderstanding?