Angular Proxy not forwarding if response code 204 received from backend

[c-goldschmidt]

Which @angular/* package(s) are the source of the bug?

Don't known / other

Is this a regression?

Yes

Description

Using a simple proxy configuration:

{
    "/api": {
        "target": "https://<backend domain>",
        "secure": false,
        "changeOrigin": true,
        "logLevel": "debug",
        "pathRewrite": {"^/api" : "https://<backend domain>/api"}
    },

The proxy responds correctly to any request. Except if that request happens to respond with a 204 and no body.

CURLing to the backend directly delivers the following:

[...request omitted...]
> content-length: 23
>
* We are completely uploaded and fine
* [CONN-0-0][CF-SSL] TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* [CONN-0-0][CF-SSL] TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
< HTTP/2 204 
< date: Fri, 29 Nov 2024 13:52:15 GMT
< vary: Accept-Language, Cookie
< content-language: de
< x-content-type-options: nosniff
< referrer-policy: same-origin
< x-frame-options: DENY
< set-cookie: language=de; Path=/; Secure
< set-cookie: ###REDACTED###
< strict-transport-security: max-age=15724800; includeSubDomains
<
* Connection #0 to host ###REDACTED### left intact

The same request to the angular proxy on localhost:

[...request omitted...same as above]
> Content-Length: 23
>

...and that's it. i do control the backend somewhat, so i changed my response to a 200 with json encoded "OK" as answer. That works with the proxy:

[...request omitted...same as above]
> Content-Length: 23
>
* [CONN-0-0][CF-SSL] TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* [CONN-0-0][CF-SSL] TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< X-Powered-By: Express
< Access-Control-Allow-Origin: *
< date: Fri, 29 Nov 2024 14:06:47 GMT
< content-type: application/json
< content-length: 4
< connection: close
< vary: Accept-Language, Cookie
< content-language: de
< x-content-type-options: nosniff
< referrer-policy: same-origin
< x-frame-options: DENY
< set-cookie: language=de; Path=/; Secure
< set-cookie: ###REDACTED###
< strict-transport-security: max-age=15724800; includeSubDomains
<
"OK"* Closing connection 0

just for completeness, the only difference i see in the server response for the 200 are these 4 headers:

< content-type: application/json
< content-length: 4
< vary: Accept-Language, Cookie
< content-language: de

these are present in the 200 answer, but not the 204 answer (which makes sense, because there is no body). Apparently, the angular proxy is waiting for these headers to be sent, but never receives them and is thus stuck in an infinite loop.

Since 204s are rather common for DELETE statements (in this case it's a POST, but the same happens with DELETE and any other method), it would be nice if this issue could be addressed.

Please provide a link to a minimal reproduction of the bug

No response

Please provide the exception or error you saw

Please provide the environment you discovered this bug in (run ng version)

Angular CLI: 18.2.12
Node: 18.20.3
Package Manager: npm 10.8.1
OS: win32 x64

Angular: 18.2.3
... animations, common, compiler, compiler-cli, core, forms
... language-service, localize, platform-browser
... platform-browser-dynamic, router, service-worker, upgrade

Package                            Version
------------------------------------------------------------
@angular-devkit/architect          0.1802.12
@angular-devkit/build-angular      18.2.12
@angular-devkit/core               18.2.12
@angular-devkit/schematics         18.2.12
@angular/cdk                       18.2.14
@angular/cli                       18.2.12
@angular/flex-layout               15.0.0-beta.42
@angular/material                  18.2.14
@angular/material-moment-adapter   18.2.14
@schematics/angular                18.2.12
rxjs                               7.8.1
typescript                         5.5.4
zone.js                            0.14.10

Anything else?

I Can't really pinpoint which update introduced this issue, we recently updated from angular-16 to 18. I'm pretty sure that this was not an issue in earlier versions. Also not sure what component to select above. is the proxy part of the compiler-cli?

[alan-agius4]

This is not an Angular CLI bug as the proxy is handled by Vite or Webpack-dev-server dependencies. What I did notice is that the content length for your 204 response is 23 and not 0.

[c-goldschmidt]

This is not an Angular CLI bug as the proxy is handled by Vite or Webpack-dev-server dependencies. What I did notice is that the content length for your 204 response is 23 and not 0.

no, that is the request body size (it's post with a payload). in curl, > denotes outgoing, < denotes incoming. the response headers do not include content-size, as there is no content.

[c-goldschmidt]

@alan-agius4 so where should i direct this bug then? because as of now, this is posing a problem for us in angular development.

[alan-agius4]

That depends on which builder you are using, are you using the esbuild/vite or webpack based?

[c-goldschmidt]

That depends on which builder you are using, are you using the esbuild/vite or webpack based?

for all i know, i'm using "builder": "@angular-devkit/build-angular:dev-server" for serve. at version 18.2.3. No idea what's the underlying builder there.

[alan-agius4]

@angular-devkit/build-angular:dev-server can use either vite and webpack-dev-server. What are you using as your build builder?

[c-goldschmidt]

@angular-devkit/build-angular:dev-server can use either vite and webpack-dev-server. What are you using as your build builder?

@angular-devkit/build-angular:browser

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