6 Replies Latest reply on Mar 2, 2016 9:38 AM by otruniger

    Invalid mimetype correction?



      I have a question for you regarding this specific URL http://b.company-target.com/ect.html.gz?parent=http://www.splunk.com/ which is embedded in http://www.splunk.com.


      When accessing this URL directly (without MWG) it receives a mimtype of text/html;charset=utf-8 and Content-Encoding of gzip - no special reaction in the browser.

      When accessing this URL through MWG the client receives a mimetype of application/gz and no header field Content-Encoding. This leads to a safe-dowload-file diaglog, which is annoying.


      Obviously MWG "fixes" the mimetype, changing behaviour on client side. Now is this just a security feature or a misbehaviour?

      I don't know if it is a special feature of a browser (Firefox in this case) to receive a gz-content with mimetype text/html to handle automagically inside but it surely looks like this. If this is true, then MWG is disturbing this. And users are annoyed by the dialog.


      Do you have any remarks on this?


      Thank you.

        • 1. Re: Invalid mimetype correction?

          Interesting... I have seen this URL popup the same save as dialog, just on symantec.com, when I was at a customer this week. This was on MWG 7.4. I do not see this on MWG 7.6, nor when going through the Web SaaS (which is on 7.6.1 right now).


          What version of MWG are you running?


          Thanks, Frank

          • 2. Re: Invalid mimetype correction?

            Hi Frank, we are running


            As this behaviour is new to us and MWG didn't change I assume this is a new usage by http://b.company-target.com. I really wonder if this usage of response content of type gzip offered in the response header as mimetype text/html is compliant to browsers and what MWG does about it if it is.

            • 3. Re: Invalid mimetype correction?
              Jon Scholten

              Hi otruinger,


              This is caused by the .gz extension and likley that you came from an older version which we did not and do not plan to migrate the settings (to preserve your existing config).


              Under Configuration > Proxies, directly above the FTP proxy settings is a check box for "Adjust content-type header for request to archives (depending on the content encoding), uncheck this.




              Also in Configuration > Proxies > Advanced settings, there is a radio option for "Compress content to client", select the option for "If the server's response is compressed".



              Best Regards,


              • 4. Re: Invalid mimetype correction?

                Thank you Jon,

                you are right we come all the way from 7.1. I was not aware of this setting or just used adjustment of content-type header as security feature and completely forgot about it.

                Now I'm not really sure if it is really a good idea to deactivate that setting. How do people generally judge on this?


                Could I use an event in a rule to omit content-type header correction?

                • 5. Re: Invalid mimetype correction?
                  Jon Scholten

                  Set it as I have above I forsee no risk (for the content-type checkbox), these are the new defaults for fresh installations.


                  The compression setting may add a little extra load but it should be negligible.


                  Best Regards,


                  • 6. Re: Invalid mimetype correction?

                    Thank you Jon, I appreciate