Wrong SockJS Host validation with Reverse Proxy

[mistic100]

🐞 Bug report

Angular CLI version : 7.2.3

Command (mark with an x)

- [ ] new
- [ ] build
- [x] serve
- [ ] test
- [ ] e2e
- [ ] generate
- [ ] add
- [ ] update
- [ ] lint
- [ ] xi18n
- [ ] run
- [ ] config
- [ ] help
- [ ] version
- [ ] doc

Is this a regression?

I don't know

Description

When using "ng serve" behind a reverse proxy on a sub-path, the SockJS Server throws 400 errors because it fails to validate the Host/Origin header.

🔬 Minimal Reproduction

I want to have my application served on my workstation at http://dev.local/common-demo

1. Create a new Angular CLI project
2. Configure the serve task in angular.json with

            "host": "localhost",
            "port": 9038,
            "publicHost": "dev.local/common-demo/sockjs-node",
            "baseHref": "/common-demo/",
            "servePath": "/"

3. Configure you workstation reverse proxy with (here Apache is used)

ProxyPass /common-demo http://localhost:9038
ProxyPassReverse /common-demo http://localhost:9038

🔥 Exception or Error

Chrome console shows :

WebSocket connection to 'ws://dev.local/common-demo/sockjs-node/287/kbmqffv3/websocket' failed: Error during WebSocket handshake: Unexpected response code: 400

Invalid Host/Origin header

[WDS] Disconnected!

Notes

If I set disableHostCheck to true, it works, but I don't want to.

If I set publicHost to dev.local the app tries to connect to ws://dev.local/sockjs-node which is not valid as it ignores the baseHref.

The servePath needs to be / as the app is served at the root of localhost:9038 (by default servePath inherits from baseHref but the sub-path is handled by the Reverse Proxy in my setup).

[EdwinChua]

I also faced this problem. @mistic100 This might help:

Brief description of project setup:

• Windows IIS to set up Reverse Proxy
• Matches URL to rewrite to specific port on localhost
  • i.e. localhost:83/4200 redirects to localhost:4200

Command: ng serve --public-host=localhost:83

SockJs tries to connect via: http://localhost:83/sockjs-node/info?t=1550556432730

If I try the command: ng serve --public-host=localhost:83/4200
SockJs tries to connect via: http://localhost:83/4200/info?t=1550556778792

This worked! (Kinda)

Out of desperation, I also tried: ng serve --public-host=localhost:83/4200/sockjs-node, which yielded this error:

sockjs.js:1683 WebSocket connection to 'ws://localhost:83/4200/sockjs-node/642/4rpx323d/websocket' failed: Error during WebSocket handshake: Incorrect 'Sec-WebSocket-Accept' header value

After some searching, I stumbled across this issue. Turns out I had to manually enable the websocket protocol in IIS.

TLDR;

1. Set the --public-host || --publicHost option
2. Append the /sockjs-node to your desired URL

• eg. ng serve --public-host=localhost:83/4200/sockjs-node

localhost can be replaced with an IP address*

* There seems to be a problem with change detection. Using this approach, the default page localhost:4200 reloads and displays the new updates, while the redirected one, localhost:83/4200 refreshes, but shows the old data. Am trying to figure out if this is an IIS issue or a browser caching one. IIS caches the files requested for about 30sec. Disabling it fixed the problem.

Question to the experts working on angular-cli:
Is 2. intended for applications not served at the root of the domain?

[clydin]

@EdwinChua No, you shouldn't have to do that. It appears that the Webpack-dev-server drops the sockjs-node segment of the path if a custom path is provided. The CLI should be able to fix up the path in this case.

[EdwinChua]

@clydin Is that a bug I should report then? Or should I be doing something differently?

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}