Aspnetcore: Response that returns 204 fails with HTTP_1_1_REQUIRED/INVALID_HTTP_RESPONSE in ANCM In-process

[jkotalik]

Associated issue for #4397

Patch reason:

Today, when and HTTP/2 request is sent to ANCM Inprocess, on a 204 response, IIS will add the header "transfer-encoding"="chunked". This is an invalid response, and web browsers like chrome explicitly show the error HTTP_1_1_REQUIRED (ERR_HTTP_1_1_REQUIRED)/INVALID_HTTP_RESPONSE(ERR_INVALID_HTTP_RESPONSE ) when returning a 204, which surfaced through the above issue. Other browser still have the issue, but they retry a HTTP/1.1 request afterwards.

This means that all HTTP responses which:

• Set a status code of 204
• Use HTTPS
• Support HTTP/2

will explicitly fail in chrome and silently fail/retry in other browsers.

Work Arounds:

In user code, someone can add a middleware to set ContentLength=0 on responses with status code 204.

For example:
c# app.Use(async (ctx, next) => { await next(); if (ctx.Response.StatusCode == 204) { ctx.Response.ContentLength = 0; } });

Risk:

Low. The change only affects 204, 205, and 304 status code responses, which aren't allowed to have a body anyways. This change only sets a bool to false on flush, which is checked when IIS is determining if it should set the encoding to chunked or not.

[muratg]

cc @Eilon

[martincostello]

I've just stumbled across this while investigating an intermittent issue with an ASP.NET 4.6.1 application where HTTP requests to an ASP.NET Core 2.2.0 application using in-process hosting are sometimes failing with a WebException with the message The server committed a protocol violation. Section=ResponseStatusLine.

This isn't with HTTP/2, but HTTP 1.1. Would this scenario be affected by this same issue?

[jkotalik]

@martincostello can you file a separate issue for what you are seeing. Specifically, what type of request/response is causing this failure and the content?

[martincostello]

@jkotalik Have opened #4437.

[slubowsky]

I've been seeing intermittent CORS related failures since trying to upgrade to 2.2.0 with options requests intermittently failing. Couldn't figure out what the issue was. Workaround described above solves the problem for me. Sample error below:

[martincostello]

Has the patch for this issue been reconciled with the fact that it was initially thought to only affect HTTP/2 and confirmed that it also resolves the issue generally as described in #4437 and the comment above about OPTIONS requests?

[jkotalik]

We didn't explicitly test OPTIONS, but the fix works for both HTTP/1.1 and 2.0. I'll go ahead and test OPTIONS just to be sure.

[jkotalik]

This should now be fixed in the latest release of 2.2.

[Rasetti]

This is still not fixed in version 2.2.2.
We use the mentioned workaround and updating the application to 2.2.2 has the same issue if we remove the workaround

app.Use(async (ctx, next) => { await next(); if (ctx.Response.StatusCode == 204) { ctx.Response.ContentLength = 0; } });

[jkotalik]

Can you provide more details on what response you are sending? Also, can you confirm that your app is running against 2.2.2 and the aspnetcorev2_inprocess.dll that is part of your app is updated to 2.2.2? (commit hash in the file description SHOULD be 522705f if github tags are correct).

[Rasetti]

Actually this is behaving as expected and it is working now in 2.2.2. The problem we had was that, since the Visual Studio UI won't tell you the patch version the app is using, we had assumed it was using the latest SDK installed, which we thought to be 2.2.2 but it was actually 2.2.0.

[dylanvdmerwe]

@jkotalik how can this be verified?

[jkotalik]

In your deployed/built app, there will be a dll call aspnetcorev2_inprocess.dll in the app directory. Right click on the dll and check the details tab. The commit hash will be listed after the file description.

[thomas-parrish]

Did this get reintroduced? We have this issue with SDK 2.2.401.