Page displays random symbols instead of error message on Firefox

Question

Randomly, on a few projects, some pages display random symbols instead of an error message. Like this one :

��������I�%&/m�{J�J��t��$@�����iG#)�*��eVe]f@�흼 ��{���{��;�N'���?\fdl��J�ɞ!���?~|?"��Ey�')=��y6����h�����Ųi��- �ez����7i޴i�L���,�4�̧i���Ίe��Ͼ|uz����:�}���U{���������΋��~�ȗu.-�����l>F'�����Y�l��$k�tF������{�� ��[����'U���|6J�lR��b6��юG�k�^,ӏ��߿�}<~<�;c�R鱕iV��m�|��� �yDl���tRͮ�|N��>�Ey�裟�k��!z���Ѳ�Y)5��G��A�8$D��Ѥ̦oI��]�P �"�/��v[����W�~���m`N�rvk���Mqz3���wV�

It happens quite randomly, and seems to be caused by different factors. Here, it's on a file upload.

We use SharpZipLib on this page, but the codepath shouldn't use it.

Does anyone knows why this happens, and how to prevent it ?

EDIT : it only happens on Firefox. IE(8) displays the error message correctly.

EDIT 2 : it seems to happen quite randomly, only on some pages/sites. The same page on another IIS site works well. It seems to do this only on IIS7 ; I have no reports of those on IIS6, and I haven't encountered it on my dev machine.

EDIT 3 : it looks like it happens only when the page crashes.

EDIT 4 : Ok, so, it happens only on IIS7, and only when I get an error 500. I think it might be the IIS error pages that have a problem. How can I try to change them ?

Firebug gives me those headers :

Response
Cache-Control private
Content-Type text/html; charset=utf-8
Server Microsoft-IIS/7.0
X-AspNet-Version 2.0.50727
X-Powered-By ASP.NET
Date Mon, 04 Apr 2011 10:31:24 GMT
Content-Length 2284
Request
Host xxxx
User-Agent Mozilla/5.0 (Windows; U; Windows NT 6.1; fr; rv:1.9.2.16) Gecko/20110319 Firefox/3.6.16 ( .NET CLR 3.5.30729; .NET4.0E)
Accept text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Accept-Language fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding gzip,deflate
Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive 115
Connection keep-alive
Referer xxxxx
Cookie xxxxxx

Is there any way for me to say "on this page, I don't accept gzip compression at all" ?

Answer 1

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 website is configured on IIS7 / Windows Server 2008.
• The page displaying the garbage symbols has, in reality, crashed. The resulting "garbage" is, in fact, an gzip-compressed error message that has not been decompressed, or something like that.
• Disabling gzip compression on either dynamic or static content does'nt change anything

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 :

1. Type about:config in the URL bar (Accept the disclaimer)
2. Type encoding in the filter field underneath the URL bar
3. Doubleclick the line "network.http.accept-encoding"
4. Empty the value

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.

Answer 2

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

Answer 3

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

Update

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.

Update 2

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

Answer 4

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();
}

Answer 5

You can also "fix" this in Chrome (or Brave) with the ModHeader extension. Then just add a Request header with the name Accept-encoding and value of nothing and reload your page: