3 Replies Latest reply on Aug 9, 2010 11:33 PM by michael_schneider

    BING Maps not loading


      Using McAfee Web Gateway 6.8.7 build 7612, bing maps fail to load using IE or Firefox.  We've built a whitelist that exempted everything and they still do not load.  Also tried adding bing.com to Bypass SSL Scanner setting under HTTPS Proxy and Bypass ICAP Server under ICAP Services - HTTP Proxy.  We are using the Web Gateway as an explicit proxy and WCCP.


      Anyone know how to get BING maps to work?

        • 1. Re: BING Maps not loading

          They are loading fine here. So I would assume that this subject to your policy.

          Not sure if you are blocking any scripts, or filtering Business or Software/Hardware in URL Filter. Are you blocking jpegs?


          You could also try whitelisting virtualearth.net, as this is the host where the images are comming from.






          Message was edited by: Michael Schneider on 04/08/2010 16:33:42 CEST
          1 of 1 people found this helpful
          • 2. Re: BING Maps not loading

            So I added virtualearth.net to the http icap services and after clearing the IE downlaod cache, it works.  I will dig through the policies to see which is causing the problem.  Is there any type of debugger to see which area is blocking the content?


            Update: The standard version of Bing Maps works with no issues, it is only when we used the silverlight version that we had the issues.  We resolved it by whitelisting virtualearth.net for "Content Type Adaptation".  What in our policy would be causing the need for us to have to whitelist content type adaptation?



            Message was edited by: jspanitz on 8/9/10 1:54:33 PM CDT
            • 3. Re: BING Maps not loading

              Content Type adaption, is part of Media Type Security.

              In case you have a malformed webserver config, and it send an exe as txt according to the mime type, the usual web gateway will let it go through and you can happily download what ever you want

              MWG is not trusting headers or file extensions, it performs its magic bytes checks and will try to correct the mdeia type. I assume that in this case, they use some proprietary media type, such as a special XML which is converted to plain xml (just an assumption).

              For example, in case a response contains:


              • Content-Type: application/x-Silverlight-XML
              • MWG now looks ito the file and sees: <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
              • The above is plain standard XML and MWG will therefore make sure the mime info is correct and will change it to: Content-Type: text/xml

              the above is know as content type adaption in MWG and in case an application is built to require the wrong header, then situations like yours happen.