InvalidOperationException: Response Content-Length mismatch when enabling BrowserLink

[Tratcher]

From @PinpointTownes on January 5, 2017 19:7

Moved from aspnet-contrib/AspNet.Security.OpenIdConnect.Server#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:

KestrelHttpServer/src/Microsoft.AspNetCore.Server.Kestrel/Internal/Http/Frame.cs

Lines 616 to 618 in cedbe76

	VerifyAndUpdateWrite(data.Count);
	await ProduceStartAndFireOnStarting();

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 😅)

[cesarblum]

@muratg This should go in 1.1.1.