We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation .
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement . We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
When running parcel serve where the --port is the same as the --hmr-port (the default behavior AFAIK), the WebSocket proxy (i.e. .proxyrc ) no longer functions properly.
parcel serve
--port
--hmr-port
.proxyrc
$ cat .proxyrc.json
{ "/ws" : { "target" : " http://localhost:1235/ " , "ws" : true } }
Running this command exhibits the bug:
parcel index.html
WebSocket proxy should work. When the browser connects to ws://localhost:1234/ws , it should be proxied to localhost:1235/ws using http-proxy-middleware
ws://localhost:1234/ws
localhost:1235/ws
When the browser establishes the WebSocket connection to ws://localhost:1234/ws , parcel indicates that the web browser immediately disconnects:
$ parcel --port 1234 --hmr-port 1234 index.html Server running at http://localhost:1234 ? Built in 1.76s console: [HPM] Upgrading to WebSocket console: [HPM] Client disconnected
On the WebSocket server running in Go on port 1235, I get an error that seems to indicate that the socket is closed:
failed to get reader: failed to read frame header: EOF
On the browser (Firefox), I get a message like this:
The connection to ws://localhost:1234/ws was interrupted while the page was loading.
which occurs on the line where I create the new WebSocket(...) .
new WebSocket(...)
Everything runs fine without parcel . If I parcel build and bypass the parcel server and HMR server, it works.
parcel
parcel build
Running Parcel with a different HMR port also seems to work (note that HMR port is set to 1236 ):
parcel --port 1234 --hmr-port 1236 index.html
$ parcel --port 1234 --hmr-port 1236 index.html Server running at http://localhost:1234 ? Built in 392ms console: [HPM] Upgrading to WebSocket
... and in this case, it all works splendidly.
This seems to indicate that parcel serve does not properly handle WebSocket proxying with http-proxy-middleware when the HMR server is running on the same port as the normal parcel HTTP server.
I'm just trying to run parcel serve [entry_point] and have it work (ideally without a separate HMR port).
parcel serve [entry_point]
I can provide a sample upon request, but it will take time.
The text was updated successfully, but these errors were encountered:
Thank you. Had the exact same issue, your solution worked perfectly.
Sorry, something went wrong.
+1 here also. I'm on parcel ^2.0.1 and socket.io-client ^4.3.2 , changing the hmr socket worked for me.
^2.0.1
socket.io-client
^4.3.2
Thank you. Your solution worked for me.
Thank you so much! I was getting something like below (in case others run into this) on the server side (Scala/Java).
io.netty.handler.codec.http.websocketx.CorruptedWebSocketFrameException: bytes are not UTF-8
AFAIK, this is still an issue. Either a documentation change should be made to inform users of this, or the bug should be fixed.
This issue is still exist in the latest version.
This is the relevant code for the case of --port === --hmr-port .
parcel/packages/reporters/dev-server/src/ServerReporter.js
Lines 46 to 55 in 2facd5d
parcel/packages/reporters/dev-server/src/HMRServer.js
Line 89 in 2facd5d
The HTTP server creation including proxyrc is here (the server here becomes devServer in HMRServer above):
server
devServer
parcel/packages/reporters/dev-server/src/Server.js
Lines 465 to 497 in 2facd5d
I think the issue is that the HMR server uses ws to create a new WebSocket server with the server option set:
This basically ensures that this.wss now handles all WebSocket requests for this.options.devServer ; thus, only HMR WebSocket requests work and WebSocket proxy requests using http-middleware-proxy are essentially closed preemptively by the HMR WebSocket upgrade handler. Here's the relevant code from the ws library: https://github.com/websockets/ws/blob/06728e444d8f54aa5602b51360f4f98794cb1754/lib/websocket-server.js#L260-L263
this.wss
this.options.devServer
ws
The solution here is to tell the HMR WebSocket.Server to run in noServer mode and only handle upgrade events when it's for the HMR. See ws docs here . So line 89 above would change to:
WebSocket.Server
noServer
this . wss = new WebSocket . Server ( { noServer : true } ) ;
and then the server's upgrade event would need to be handled manually as shown in this ws usage example :
server . on ( 'upgrade' , function upgrade ( req , socket , head ) { let { pathname } = url . parse ( req . originalUrl || req . url ) ; if ( pathname != null && pathname . startsWith ( HMR_ENDPOINT ) ) { this . wss . handleUpgrade ( req , socket , head , function done ( ws ) { this . wss . emit ( 'connection' , ws , req ) ; } ) ; } // else, we simply do nothing and hope the request got proxied } ) ;
Anyway, hope this is an easy fix. If you want, I can try my hand at a PR for this.
Fix HMR server when WebSocket proxy is running on the same port ( fixes …
76b6121
…parcel-bundler#6994 )
a35e573
PR is still open
Successfully merging a pull request may close this issue.