Skip to content
This repository has been archived by the owner on Dec 18, 2018. It is now read-only.

InvalidOperationException: Response Content-Length mismatch when enabling BrowserLink #1289

Closed
Tratcher opened this issue Jan 6, 2017 · 16 comments
Assignees

Comments

@Tratcher
Copy link
Member

Tratcher commented Jan 6, 2017

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
Copy link
Member Author

Tratcher commented Jan 6, 2017

From @PinpointTownes on January 5, 2017 19:7

Hey,

Did you try to disable BrowserLink?

@Tratcher
Copy link
Member Author

Tratcher commented Jan 6, 2017

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
Copy link
Member Author

Tratcher commented Jan 6, 2017

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
Copy link
Member Author

Tratcher commented Jan 6, 2017

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
Copy link
Member Author

Tratcher commented Jan 6, 2017

From @PinpointTownes on January 5, 2017 19:12

Here's a tiny repro:

image

{
  "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
Copy link
Member Author

Tratcher commented Jan 6, 2017

This is actually a Kestrel bug:

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
Copy link

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

@cesarblum
Copy link
Contributor

@muratg This should go in 1.1.1.

@Eilon
Copy link
Member

Eilon commented Jan 10, 2017

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

@cesarblum
Copy link
Contributor

@Eilon #1303

@Eilon
Copy link
Member

Eilon commented Jan 10, 2017

Thanks!

@Eilon
Copy link
Member

Eilon commented Jan 13, 2017

Done?

@cesarblum
Copy link
Contributor

@Eilon Missed that. Thanks!

@cesarblum
Copy link
Contributor

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
Copy link

@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
Copy link

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

7 participants