Visual Studio Browser Link trashes response compression

[jhudsoncedaron]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

I was able to completely cut MVC out of the bisection by using a funny looking page generator for /. The real page is a .cshtml file. So yes, you should tolerate the funny looking page generator. This also means the original area bisection by the bot is bunk; but it's usually not so good anyway.

Occasionally a page won't open when developing a web application under visual studio. This has been traced to Visual Studio Browser Link.

On capturing the faulting page response; the brotli stream correctly decompresses to the base stream. However; the capture in Wireshark can't be decompressed because it's been altered (the stream is now too long).

Attached files demonstrating bug:
captures.zip

Uncompressed stream in capturebefore.dat
Compressed stream in captureafter.dat
What was actually sent in amalgumwireshark.dat

Expected Behavior

Visual Studio Source Link does not trash page compression.

I'm pretty sure I need a .UseXXX directive for Visual Studio Browser Link so it gets inserted in the correct place in the middleware stack; otherwise it's going to either not work or mutate something it does not understand; and that makes this the correct repository to file the bug in.

Steps To Reproduce

The reproduction almost bisected. I managed to get Visual Studio Browser Link to trash the page but it doesn't actually display the error message that replaying the malformed responses in the dat file does. If you do view source on the page response you can see that it's damaged.

Github repo: https://github.com/jhudsoncedaron/r57905

Exceptions (if any)

"The page you are trying to view cannot be shown because it uses an invalid or unsupported form of compression."

.NET Version

8.0.401

Anything else?

Turning off BrowserLink in Visual Studio doesn't fix the problem; but starting the project with dotnet run does.

[javiercn]

@jhudsoncedaron thanks for contacting us.

In order to get a faster and better answer, could you file this issue through the Visual Studio report a problem dialog.

That will help us make sure it gets routed to the right team.

[jhudsoncedaron]

@javiercn : You might want to consider what a solution would look like. Getting a working solution other than "I'm pretty sure I need a .UseXXX directive for Visual Studio Browser Link so it gets inserted in the correct place in the middleware stack" seems tricky.

[jhudsoncedaron]

I have filed an issue with Visual Studio and added to my knowledge.

https://developercommunity.visualstudio.com/t/Browser-Link-response-compression/10746995

I am now more confident that a proper fix required a change to the asp.net core codebase to place the injected module in the correct place in the .Use stack.

[jhudsoncedaron]

I found a half-duplicate: #45213

If that item gets completed; this item can be closed as a duplicate; however the converse is not true. That item is talking about a full rebuild of hot reload to not use the same injection mechanism, while I am talking about a marker .Use() that says inject here as a stopgap solution that can be done very quickly.

[MackinnonBuck]

Thanks for reaching out, @jhudsoncedaron. We're going to close out this issue and use the VS Feedback Ticket you opened to track the problem.