Kestrelhttpserver: InvalidOperationException: Response Content-Length mismatch when enabling BrowserLink

[Tratcher]

_From @PinpointTownes on January 5, 2017 19:7_

_Moved from https://github.com/aspnet-contrib/AspNet.Security.OpenIdConnect.Server/issues/365._

---

Hello

I have managed to get the Authorization Code Flow to work. Everything works fine if the user 'Authorizes'. However, if the user denies the authorize the request (i.e. Forbid(OpenIdConnectServerDefaults.AuthenticationScheme) executes in the controller) I get the following exception:

System.InvalidOperationException: Response Content-Length mismatch: too many bytes written (1024 of 806).
   at Microsoft.AspNetCore.Server.Kestrel.Internal.Http.Frame.VerifyAndUpdateWrite(Int32 count)
   at Microsoft.AspNetCore.Server.Kestrel.Internal.Http.Frame.<WriteAsyncAwaited>d__183.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.VisualStudio.Web.BrowserLink.Runtime.ScriptInjectionFilterStream.<>c__DisplayClass40_0.<<CreateResponseHandler>b__0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.VisualStudio.Web.BrowserLink.Runtime.SocketReader.<ReadBytesIntoResponseHandler>d__9.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.VisualStudio.Web.BrowserLink.Runtime.HttpSocketAdapter.ResponseReader.<ReadBytesIntoResponse>d__22.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.VisualStudio.Web.BrowserLink.Runtime.HttpSocketAdapter.ResponseReader.<ReadChunkedContent>d__20.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.VisualStudio.Web.BrowserLink.Runtime.HttpSocketAdapter.ResponseReader.<ReadResponse>d__17.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.VisualStudio.Web.BrowserLink.Runtime.ScriptInjectionFilterStream.<WaitForFilterComplete>d__19.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.VisualStudio.Web.BrowserLink.Runtime.BrowserLinkMiddleware.<ExecuteWithFilter>d__7.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddleware.<Invoke>d__7.MoveNext()

I am not sure if this is a problem on my side or now. I would appreciate some advice.

Thanks
Andrew

_Copied from original issue: aspnet/Tooling#933_

[Tratcher]

_From @PinpointTownes on January 5, 2017 19:7_

Hey,

Did you try to disable BrowserLink?

[Tratcher]

_From @PinpointTownes on January 5, 2017 19:7_

FYI, I managed to reproduce this bug on my machine by enabling BrowserLink AND updating Kestrel to 1.1.0 (Kestrel 1.0.0 doesn't compare the number of bytes written to the response stream with the Content-Length response header).

Since this really sounds like a BrowserLink bug, I marked it as "external" so it can be moved to the right place.

@Eilon what would be the best place to report BrowserLink bugs? Microsoft Connect? If you think it's worth investigating, I'll try to create a tiny repro that demonstrates the bug, without relying on ASOS.

@Tratcher for some reasons, ANCM or IIS seems to force chunking for responses that specify a Content-Length. Running Kestrel without IIS works as expected (i.e doesn't chunk the response). Is that the intended behavior?

Thanks.

[Tratcher]

_From @PinpointTownes on January 5, 2017 19:7_

Thank you @PinpointTownes . I can confirm that it is working fine when I disable BrowserLink. You are correct, I have just upgraded to v1.1.0.

[Tratcher]

_From @PinpointTownes on January 5, 2017 19:7_

You can contact @jodavis for BrowserLink issues, or also you could post bugs here: https://github.com/aspnet/Tooling/issues/

[Tratcher]

_From @PinpointTownes on January 5, 2017 19:12_

Here's a tiny repro:

{
  "dependencies": {
    "Microsoft.AspNetCore.Diagnostics": "1.1.0",
    "Microsoft.AspNetCore.Server.IISIntegration": "1.1.0",
    "Microsoft.AspNetCore.Server.Kestrel": "1.1.0",
    "Microsoft.Extensions.Logging.Debug": "1.1.0",
    "Microsoft.NETCore.App": { "version": "1.1.0", "type": "platform" },
    "Microsoft.VisualStudio.Web.BrowserLink.Loader": "14.1.0"
  },

  "frameworks": {
    "netcoreapp1.1": { }
  },

  "buildOptions": {
    "emitEntryPoint": true,
    "preserveCompilationContext": true
  },

  "publishOptions": {
    "include": [
      "wwwroot",
      "web.config"
    ]
  }
}

using System.IO;
using Microsoft.AspNetCore.Hosting;
using Microsoft.Extensions.Logging;

namespace BrowserLinkBug {
    public class Program {
        public static void Main(string[] args) {
            var host = new WebHostBuilder()
                .ConfigureLogging(options => options.AddDebug())
                .UseKestrel()
                .UseContentRoot(Directory.GetCurrentDirectory())
                .UseIISIntegration()
                .UseStartup<Startup>()
                .Build();

            host.Run();
        }
    }
}

using System.Text;
using Microsoft.AspNetCore.Builder;
using Microsoft.AspNetCore.Hosting;
using Microsoft.AspNetCore.Http;

namespace BrowserLinkBug {
    public class Startup {
        public void Configure(IApplicationBuilder app) {
            app.UseDeveloperExceptionPage();

            app.UseBrowserLink();

            app.Run(context => {
                var encoding = new UTF8Encoding(encoderShouldEmitUTF8Identifier: false);

                var document = @"<!doctype html>
<html>
<body>
<strong>Hello world</strong>
</body>
</html>";

                context.Response.ContentLength = encoding.GetByteCount(document);
                context.Response.ContentType = "text/html;charset=UTF-8";

                return context.Response.WriteAsync(document, encoding, context.RequestAborted);
            });
        }
    }
}

[Tratcher]

This is actually a Kestrel bug:
https://github.com/aspnet/KestrelHttpServer/blob/cedbe76f5263f4fbb34dac1327cc048c10ca0d8e/src/Microsoft.AspNetCore.Server.Kestrel/Internal/Http/Frame.cs#L616-L618

BrowserLink does this:

                httpContext.Response.OnStarting(delegate ()
                {
                    httpContext.Response.ContentLength = null;

But Kestrel snapshots the ContentLength before invoking OnStarting callbacks.

I'll move this bug to Kestrel.

[kevinchalet]

@Tratcher thanks for the explanation (and for moving this ticket to the right repo :sweat_smile:)

[cesarblum]

@muratg This should go in 1.1.1.

[Eilon]

@cesarbs can you open a new bug and put it in that milestone?

[cesarblum]

@Eilon https://github.com/aspnet/KestrelHttpServer/issues/1303

[Eilon]

Thanks!

[Eilon]

Done?

[cesarblum]

@Eilon Missed that. Thanks!

[cesarblum]

Quick update. There's a work around for people running into this issue when serving static HTML content with StaticFiles:

app.UseStaticFiles(new StaticFileOptions
{
    OnPrepareResponse = context =>
    {
        context.Context.Response.Headers.Remove("Content-Length");
    }
});

[eriksendc]

@cesarbs Is the workaround for static files something related to BrowserLink or just something to fix a general underlying bug? I'm having sporadic issues in production where the "signature" of the error in the stdout logs is

fail: Microsoft.AspNetCore.Server.Kestrel[13]
      Connection id "0HL4LUEF54SHK": An unhandled exception was thrown by the application.
System.InvalidOperationException: Response Content-Length mismatch: too few bytes written (39845888 of 93982840).

Wondering if your workaround is appropriate for my situation.

Thanks!
-Brian Eriksen

[devtrends]

Did this fix not make it into either 1.1.1 or 1.1.2? I see the Milestone is now set to 2.0.0 despite the patch being approved in January.