devServer proxy strips Access-Control-Allow-* headers

[schmkr]

Command

serve

Is this a regression?

• Yes, this behavior used to work in the previous version

The previous version in which this bug was not present was

14.1

Description

Since version 14.2, proxied OPTIONS requests are missing Access-Control-Allow-* headers from the origin (and seem to add/replace Access-Control-Allow-Origin).

Before, up to version 14.1, having a proxy configured like so:

{
  "/api": {
    "target": "http://localhost:18080",
    "changeOrigin": true,
    "ws": true
  }
}

Worked fine when the browser was making an CORS preflight OPTIONS request.

Here's 3 requests, first directly to the origin, second using local dev-server with Angular CL v14.1 and third using v14.2.

Request to origin:

curl -v 'http://localhost:18080/api/log' \
  -X 'OPTIONS' \
  -H 'access-control-request-headers: content-type' \
  -H 'access-control-request-method: POST' \
  -H 'origin: http://localhost:4200'

< HTTP/1.1 200 OK
< Date: Mon, 05 Sep 2022 10:06:10 GMT
< Cache-Control: must-revalidate,no-cache,no-store
< Access-Control-Allow-Origin: http://localhost:4200
< Vary: Origin
< Access-Control-Allow-Credentials: true
< Access-Control-Max-Age: 60
< Access-Control-Allow-Methods: GET,POST,DELETE,PUT,HEAD,PATCH
< Access-Control-Allow-Headers: Accept,Accept-Language,Authorization,Content-Type,Origin,User-Agent,X-Requested-With
< Content-Type: text/plain
< Allow: POST,OPTIONS
< Content-Length: 13

Same request, but proxied by dev-server in v14.1:

curl -v 'http://localhost:18080/api/log' \
  -X 'OPTIONS' \
  -H 'access-control-request-headers: content-type' \
  -H 'access-control-request-method: POST' \
  -H 'origin: http://localhost:4200'

< HTTP/1.1 200 OK
< X-Powered-By: Express
< access-control-allow-origin: http://localhost:4200
< connection: close
< date: Mon, 05 Sep 2022 10:38:12 GMT
< cache-control: must-revalidate,no-cache,no-store
< vary: Origin
< access-control-allow-credentials: true
< access-control-max-age: 60
< access-control-allow-methods: GET,POST,DELETE,PUT,HEAD,PATCH
< access-control-allow-headers: Accept,Accept-Language,Authorization,Content-Type,Origin,User-Agent,X-Requested-With
< content-type: text/plain
< allow: POST,OPTIONS
< content-length: 13

Same request, but proxied by dev-server in v14.2:

curl -v 'http://localhost:18080/api/log' \
  -X 'OPTIONS' \
  -H 'access-control-request-headers: content-type' \
  -H 'access-control-request-method: POST' \
  -H 'origin: http://localhost:4200'

< HTTP/1.1 204 No Content
< X-Powered-By: Express
< Access-Control-Allow-Origin: *
< Content-Length: 0
< Date: Mon, 05 Sep 2022 10:49:26 GMT
< Connection: keep-alive
< Keep-Alive: timeout=5

Also, only noticing now after writing this, I see that the response status code is also changed/overriden.

Minimal Reproduction

• Create a new app with ng new ng-cli-cors-headers, cd into its directory.
• Create a file proxy.conf.json with above contents (although using a different target that also responds to OPTIONS requests with specific Access-Control-Allow-* response headers)
• ng serve --proxy-config proxy.conf.json
• issue above mentioned curl requests and observe the missing headers

Exception or Error

No response

Your Environment

Angular CLI: 14.2.1
Node: 18.7.0 (Unsupported)
Package Manager: npm 8.15.0
OS: darwin x64

Angular: 14.2.0
... animations, cdk, common, compiler, compiler-cli, core, forms
... language-service, localize, material, platform-browser
... platform-browser-dynamic, router

Package                         Version
---------------------------------------------------------
@angular-devkit/architect       0.1402.1
@angular-devkit/build-angular   14.2.1
@angular-devkit/core            14.2.1
@angular-devkit/schematics      14.2.1
@angular/cli                    14.2.1
@schematics/angular             14.1.2
rxjs                            7.5.6
typescript                      4.7.4
webpack                         5.74.0

Anything else relevant?

We also have http-proxy-middleware as a direct dependency installed, so also listing that here:

$ npm ls http-proxy-middleware
├─┬ @angular-devkit/[email protected]
│ └─┬ [email protected]
│   └── [email protected] deduped
└── [email protected]

[alan-agius4]

This seems to be related to a change in webpack-dev-server. Context: webpack/webpack-dev-server#4551

Are you able to test if by updating node_modules/webpack-dev-server/lib/Server.js to https://gist.github.com/alan-agius4/156a7c36c2927986ef4e1dc6ffcdc97a the issue still persists?

[alan-agius4]

Based on the reproduction in #23859 it does seem like it's a matter of registration order.

[schmkr]

Hi @alan-agius4, I can confirm that changing the contents of node_modules/webpack-dev-server/lib/Server.js to the mentioned Gist does seem to solve the issue we are experiencing.

[schmkr]

For what it is worth, something else related to proxying that used to work up to v14.1 was defining a onProxyRes-callback does not work anymore in v14.2

[alan-agius4]

For what it is worth, something else related to proxying that used to work up to v14.1 was defining a onProxyRes-callback does not work anymore in v14.2

This seems to be a separate issue. I suggest you file an issue with a minimal reproduction with webpack-dev-server.

[alan-agius4]

Closed via #23869

[schmkr]

Thanks for the quick resolution, @alan-agius4. Already managed to validate the fix by using the overrides key in package.json to request the fixed version of webpack-dev-server.

And regarding the mentioned onProxyRes callback not working, that seems to be working again as well (wanted to wait with creating a new issue until after this was resolved, to not create redundant issues).

[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.}