Randomly, on a few projects, some pages display random symbols instead of an error message. Like this one :
��������I�%&/m�{J�J��t��
$@�����iG#)�*��e
This is looks like gZip error decoding.
Check if you set the Content-Length in a way on your pages, and then use gZip filter. If yes then remove the Content-Length set from your code.
This can happend when you send the Content-Length and later you compress it and iis can not change the header Content-Length to the new compressed one, and send the wrong size, then browser is reading the wrong size and fail to decompress it correct.
reference:
ASP.NET site sometimes freezing up and/or showing odd text at top of the page while loading, on load balanced servers
Other possible reason is to set a wronge Response.ContentType, for example to set it as text and you send a gif image, or to set it as image and you send a text.
Maybe the error is on the the content type. Set this headers:
context.Response.ContentType = "application/octet-stream";
context.Response.AppendHeader("Content-disposition", "attachment; filename=" + cFileNameToShowAndDownload);
Another workaround for anyone stumbling across this could be to remove the response filter on application error, which will get rid of the encoding and send it through uncompressed. Since this is only for error messages the impact on performance should be minimal.
In your Global.asax
VB
Sub Application_Error()
Response.Filter = Nothing
End Sub
C# (I assume this is right, see blog link below)
protected void Application_Error(object sender, EventArgs e)
{
Response.Filter = null;
}
All credit to Rick Strahl with this blog post for the workaround.
Note: I also added this an an answer to my own question here - IISExpress garbled HTTP 500 error message
I did not find any real solution, but I found a satisfying workaround.
Keep in mind that the problem only arises under those conditions :
The workaround is simple : refuse gzip-compressed content in the browser. In Firefox, as seen in http://forgetmenotes.blogspot.com/2009/05/how-to-disable-gzip-compression-in.html :
On my website, it did some weird things with the CSS (and StackOverflow does not have any CSS at all after that), but at least it correctly showed me the error message, which enabled me to fix the bug.
Hopefully it will help someone.
I ran into a similar issue with dotnet core. (This question is closing in on 9 years old right now. Don't think this will help op, but maybe other people will find this helpful).
I was getting similar garbled text, it looked like gzip encoding. Disabling compression in firefox like the selected answer seemed to verify this. The problem only showed up when trying to render a partial view with a script block with non-standard content (kendo template). It wasn't anything related to when an exception was occurring or not.
The problem came down to configuration. We were using a 3rd party library that was breaking the response. Using compression as Microsoft outlines at https://docs.microsoft.com/en-us/aspnet/core/performance/response-compression?view=aspnetcore-2.2 fixed the problem (we stopped using the 3rd party lib). As mentioned on https://stackoverflow.com/a/54372810/1462295 , the ordering matters when configuring the compression and static file setup.
public void ConfigureServices(IServiceCollection services)
{
services.AddResponseCompression(options =>
{
options.Providers.Add<BrotliCompressionProvider>();
options.Providers.Add<GzipCompressionProvider>();
});
}
public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
// ordering matters here
app.UseResponseCompression();
app.UseStaticFiles();
}