AllowSynchronousIO set to false causes compression exception in ASP.NET Core 2.2.

[kieronlanning]

When AllowSynchronousIO is configured to false, essentially barring any blocking calls from the request pipeline, compression failed with the following exception:

System.InvalidOperationException: Synchronous operations are disallowed. Call WriteAsync or set AllowSynchronousIO to true instead.
   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpResponseStream.Write(Byte[] buffer, Int32 offset, Int32 count)
   at System.IO.Compression.DeflateStream.PurgeBuffers(Boolean disposing)
   at System.IO.Compression.DeflateStream.Dispose(Boolean disposing)
   at System.IO.Stream.Close()
   at System.IO.Compression.GZipStream.Dispose(Boolean disposing)
   at System.IO.Stream.Close()
   at Microsoft.AspNetCore.ResponseCompression.BodyWrapperStream.Dispose(Boolean disposing)
   at System.IO.Stream.Close()
   at Microsoft.AspNetCore.ResponseCompression.ResponseCompressionMiddleware.Invoke(HttpContext context)
   at Microsoft.AspNetCore.ResponseCaching.ResponseCachingMiddleware.Invoke(HttpContext httpContext)
   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpProtocol.ProcessRequests[TContext](IHttpApplication`1 application)

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 9795b92f-db24-8f1f-88c0-c36666d3526f
• Version Independent ID: 2d56d9b6-3d7b-0204-6c08-8e584fccecc2
• Content: Response compression in ASP.NET Core
• Content Source: aspnetcore/performance/response-compression.md
• Product: aspnet-core
• GitHub Login: @guardrex
• Microsoft Alias: riande

[guardrex]

Hello @kieronlanning ... This is going to be fixed with the release of 3.0 (see this remark). The error message is clear, so I'm not too worried about noting it in the 2.2 version of the topic.

[kieronlanning]

Thanks @guardrex - is this not being backported to 2.x?

I would have thought a note in the docs would be a good value add, setting AllowSynchronousIO to false is a good move. But as the middleware doesn't support it, a quick note would save people a lot of time.

[guardrex]

I was told that the decision on that is made a little later in the release cycle. The announcement for the AllowSynchronousIO updates seem to indicate 3.0+.

Ping them on the discussion issue for the announcement to ask about that: dotnet/aspnetcore#7644 ... and then come back and mention the answer over here.

quick not would save people a lot of time

We actively don't document every error condition. Management would like us to let the error message cover the scenario. Also note that this is the first time this has come up for this topic (AFAIK) since the topic was written.

[Tratcher]

No it won't be backported. We needed new APIs like DisposeAsync to make it work right.

[guardrex]

@Rick-Anderson It could be seen to fall into the bucket of not documenting every error condition that an error message explains. This is the first time this has ever come up. Not sure it's worth the space/trouble, especially given that this goes away with 3.0. I suggest closing, but let me know otherwise if you would like something done.

[Rick-Anderson]

It's unexpected behavior I think is worth pointing out. @tdykstra and @scottaddie may differ.

@danroth27 do we have a policy on this?

[danroth27]

@Rick-Anderson I'm not aware of any policy on this.

The error message seems pretty clear and this is getting fixed in 3.0, so I don't see a lot of value in documenting this for 2.x.