connect-history-api-fallback

connect-history-api-fallback copied to clipboard

It's unreasonable to serve html for non-html requests with status code 2xx. so connect-history-api-fallback shouldn't redirect to index page if browsers don't explicitly accept html, thus options.htmlAcceptHeaders should default to ["text/html"] from ["text/html","*/*"] since most dependents(at least those I 'm using) and developers don't set that option and most browsers' request header 'accept' contains "text/html"

Chrome:
	Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Safari:
	Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Firefox:
	Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Internet Explorer:
	Accept: text/html, application/xhtml+xml, image/jxr, */*

See also my history-api-fallback solution for Nginx React-router and nginx

So you are proposing to remove */* from the default options.htmlAcceptHeaders configuration? Why is this? Is this coming from an actual problem you are having?

Yes，yes!

Most type of auto-sent requests will accept */*, e.g. requests initiated by <img>,<link>,<script>, etc.

• image accept: image/webp,image/apng,image/*,*/*;q=0.8
• css accept: text/css,*/*;q=0.1
• javascript accept: */*
• font accept: */*

If we keep */* in option htmlAcceptHeaders by default, thus we think requests initiated by <img>,<link>,<script> are html requests. back to top: it's unreasonable to serve html for non-html requests with status code 2xx. it causes developers hard to detect missing resources.

I am well aware of the theory behind this, but so far this library seems to have worked very well for its users. This is why I asked for an actually existing problem caused by this default configuration option.

Given a download rate of currently over 4 million times per week, I am not willing to make such a potentially breaking change and through that affect users.

any workaround for this?

my issue is described here https://github.com/shellscape/webpack-plugin-serve/issues/130

it only happens when disableDotRule is enabled

@bripkens this is a real issue affecting users. It's wonderful that the module has so many downloads! But that doesn't discount the effect of a small bug when one is found. Breaking changes are tough; they require documentation, a major release, and lots of questions from users.

Wouldn't a more reasonable solution then be an option to allow for different behavior to resolve this case? That would only mean a minor version, minimal documentation, and no effect to users who didn't want to change the original behavior. You could even ask for feedback in the future on whether or not users on the whole would like to see the option become the default.

Wouldn't a more reasonable solution then be an option to allow for different behavior to resolve this case? That would only mean a minor version, minimal documentation, and no effect to users who didn't want to change the original behavior. You could even ask for feedback in the future on whether or not users on the whole would like to see the option become the default.

Sounds like a fair approach @shellscape. Also, I would very much appreciate a sample app under examples/ which illustrates when this is needed 👍

Thank you @bripkens

@sibelius @fuweichin can either of you take up the effort for this contribution?