InvalidOperationException: Response Content-Length mismatch when enabling BrowserLink

[kevinchalet]

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

[kevinchalet]

Hey,

Did you try to disable BrowserLink?

[kevinchalet]

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.

[kevinchalet]

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.

[kevinchalet]

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

[kevinchalet]

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.

[Tratcher]

This issue was moved to aspnet/KestrelHttpServer#1289

[netcore-jroger]

I have this issue too. Then I disabled "Enable Browser Link" , there is no problem.