vitejs / vite

Next generation frontend tooling. It's fast!
http://vite.dev
MIT License
68.31k stars 6.16k forks source link

Ping requests reach the user defined middlewares #13109

Closed gtm-nayan closed 1 year ago

gtm-nayan commented 1 year ago

Describe the bug

When the server shuts down, the client starts sending periodic ping requests to check if the server is back up and then reload. These requests reach the middlewares defined by the users but it should probably be handled by vite before it reaches any of these like the initial websocket upgrade request does. There is also no reliable way to identify these requests for the middlewares to ignore it themselves.

ref: https://github.com/sveltejs/kit/issues/6910 ref: https://github.com/sveltejs/kit/issues/7218

https://github.com/vitejs/vite/blob/c63ba3fa08a64d75bfffa6885dc4c44875b9c5ba/packages/vite/src/client/client.ts#L318-L324 Here it uses the no-cors mode so custom headers won't be sent along, can't use that to identify the ping request, but that can be worked around by abusing the Accept header, something like Accept: text/x-vite-ping and check that instead.

I could submit a PR, but can't tell which file would be responsible for intercepting it, is it ws.ts?

Reproduction

https://github.com/gtm-nayan/vite-ping-repro

Steps to reproduce

  1. Run pnpm install

  2. Run pnpm dev

  3. Open the page

  4. Turn off dev server

  5. Restart the dev server (ideally set a breakpoint on this line to avoid the clutter from unrelated requests)

  6. Observe that the custom middleware from vite.config.js will have first logged the request URL from the ping request

System Info

npmPackages:
    vite: ^4.3.5 => 4.3.5

Used Package Manager

pnpm

Logs

No response

Validations

bluwy commented 1 year ago

We used to have a __vite_ping endpoint that the client will ping, but that was removed at https://github.com/vitejs/vite/pull/6819 and https://github.com/vitejs/vite/pull/8133, because it was changed to ping the HMR host instead of Vite's http server host. By default, both host are the same but some configuration can have custom setups.

I think it makes sense to handle this in the http server still, so adding a middleware here should be good enough. I'm also fine with the custom Accept header to recognize it.