Page displays random symbols instead of error message on Firefox

后端 未结 4 683
梦毁少年i
梦毁少年i 2020-12-10 03:47

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

相关标签:
4条回答
  • 2020-12-10 03:58

    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);
    
    0 讨论(0)
  • 2020-12-10 04:13

    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

    0 讨论(0)
  • 2020-12-10 04:16

    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.

    0 讨论(0)
  • 2020-12-10 04:18

    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();
    }
    
    0 讨论(0)
提交回复
热议问题