search

bripkens / connect-history-api-fallback

Fallback to index.html for applications that are using the HTML 5 history API
MIT License
1.83k stars 143 forks source link

HEAD requests are not accepted #72

Open dsinni opened 4 years ago

dsinni commented 4 years ago

Hello,

Currently, it appears that this does not accept HEAD requests with the default configuration, which results in 404 errors for those requests.

Is there a way to allow this through configuration currently? If not, would it maybe be worthwhile to add support for HEAD requests as well since they're basically simplified GET requests for header info?

Hoping someone can point me in the right direction here.

Appreciate your time.

bripkens commented 4 years ago

Hey @dsinni,

could you describe the use case behind this for me? Preferably with an example app in a PR so that I understand why this needs to be done (and to test changes)?

dsinni commented 4 years ago

Hi, @bripkens.

Thanks for the reply.

I'm currently using connect-history-api-fallback in conjunction with vue-router's history mode.

Not sure I'll be able to provide an app at the moment, but an example seems to be the use of socket.io which appears to use HEAD requests. I've also seen that other libraries check for the existence of paths/files using HEAD requests as they're lighter than GET since there is no response body.

AFAIK, express will accept HEAD requests through GET routes, if HEAD routes are not set explicitly, which seems like it would do the trick, but connect-history-api-fallback looks like it's rejecting these requests, resulting in 404s.

A simple test could be done by comparing GET with HEAD:

// GET: works as expected
fetch(url, { method: 'get' }).then(res => console.log(res));

// HEAD: results in 404 Not Found
fetch(url, { method: 'head' }).then(res => console.log(res));

These errors are more apparent in Google Chrome, but can also be seen in the Network tab in Firefox DevTools.

Since HEAD requests are very similar to GET in nature, and express handles them as GET for the most part, it seems it would make sense to make it an option to accept them, if not by default.

I'm not sure if this will provide additional context, but also may be worth a look: https://github.com/webpack/webpack-dev-server/issues/924

I appreciate your attention to this, as it could really help out with the issues I'm facing.

watery commented 3 years ago

Hi @bripkens and @dsinni, any update on this?