500 on swagger json endpoint while logging response using middleware

[VigneshPrasadV]

When I tried logging the response with the method provided here, I am getting 500 on the swagger endpoint. While I am able to get the response on calling the URI. Same issue mentioned in the comment.

[domaindrivendev]

Can you provide more details around the 500 response? For example, the exception that's driving it. You may need to enable the developer exception page to see this - i.e. UseDeveloperExceptionPage.

[VigneshPrasadV]

Microsoft.AspNetCore.Server.Kestrel:Error: Connection id "0HL2Q5QC2C2OS": An unhandled exception was thrown by the application.

System.ObjectDisposedException: Cannot access a closed Stream.
at System.IO.__Error.StreamIsClosed()
at System.IO.MemoryStream.Seek(Int64 offset, SeekOrigin loc)
at PayloadLogging.PayloadLogging.d__2.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddleware.d__7.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddleware.d__7.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.AspNetCore.Server.IISIntegration.IISMiddleware.d__8.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.AspNetCore.Hosting.Internal.RequestServicesContainerMiddleware.d__3.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at Microsoft.AspNetCore.Server.Kestrel.Internal.Http.Frame`1.d__2.MoveNext()

[jasneetbhatti]

@domaindrivendev The issue is with this line.

Disposing the StreamWriter causes the underlying stream to get closed as well. Perhaps might be a good idea to just flush it instead.

[rboada04]

You can add the swagger middleware before adding the request/response logging middleware, so swagger requests won't get handled by the logging middleware.

public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
{
loggerFactory.AddConsole(Configuration.GetSection("Logging"));
loggerFactory.AddDebug();
app
.UseSwagger()
.UseSwaggerUI(c => c.SwaggerEndpoint("/swagger/v1/swagger.json", "My API")
// add logging middleware
.UseMiddleware<LogResponseMiddleware>()
.UseMiddleware<LogRequestMiddleware>()
.app.UseMvc();
}

[Domanser]

Maybe is it better not to close stream in RespondWithSwaggerJson() method?

For example, Swashbuckle.AspNetCore conflicts with ZNetCS.AspNetCore.Compression because stream is closed (see this issue). There are some workarounds in this case: we can ignore compression for swagger.json or change order of middlewares. But in general, stream closing could be a problem.

[treziac]

I hit the same issue, and ended with same analysis : it's not necessarly a good thing to close the stream (it doesn't add anything and can cause problems). Would you accept a PR to modify this?

[Grynet]

Having the same problem. Seems like other issues are being opened for the same underlying problem.
Like: #520.

+1 on leaving the stream open. The .Net core 2 WebApi docs are lacking but I don't think ur supposed to close the stream.

[domaindrivendev]

@treziac - sorry about the slow response. This does seem like a critical issue that could be easily remedied. A PR would certainly be welcomed!

[treziac]

@domaindrivendev #509 solves the issue, would be nice to see it merged ;)

[helloserve]

Yay! Just in time with this merge. Thanks all!