none
Specific "Access to XMLHttpRequest at 'https://www.bing.com/fd/ls/lsp.aspx' has been blocked by CORS policy" issue? RRS feed

  • Question

  • Hi, 

    I am sometimes getting an error like this one when using a V8 web map control:

    Access to XMLHttpRequest at 'https://www.bing.com/fd/ls/lsp.aspx' from origin '[domain]' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

    After some searches, the error comes from these calls below. As we see, indeed this call does not return Access-Control-Allow-Origin header.

    This seem to be some error reporting mechanism within the control, given the payload. So I don't really expect this to cause much problem on the use of the map itself, but one never knows, it is a bit weird to get those errors from time to time. Could the header be added so we stop getting that error ?

    Thanks!

    

    Friday, November 9, 2018 9:04 PM

All replies

  • Well, from what I read from this post, it seems that the www.bing.com server should reply with a Allow-Control-Allow-Origin header, which it does not, in order for my browser to really do the call that is requested with the shown payload.

    I do not control www.bing.com IIS server, so I can't enable it, that's why I'm asking your team to enable it. (They can refer to the post you just sent, if it can help :) )

    Monday, November 12, 2018 2:21 PM
  • Hi Raphael,

    From the Other thread:

    Hi Vikas,

    Would you please share the error text from the IE web console tab? You may need to enable CORS on IIS to get this to work.

    Thanks

    Kelvin Goseng

    Sincerely,

    IoTGirl

    Monday, November 19, 2018 9:39 PM
    Owner
  • Hope this is helpful to someone, given that I had already posted the full request and response description in OP...

    Monday, November 19, 2018 9:58 PM
  • Hi Raphael,

    I am sorry you are not able to update your CORS settings.  Maybe this post will help you understand what is happening. http://www.web-maps.com/gisblog/?p=2515

    Sincerely,

    IoTGirl

    Tuesday, November 20, 2018 5:45 AM
    Owner
  • This post is referring to a custom tile layer from the customers own azure blob...

    'http://onterratest.blob.core.windows.net/bingtiles2/county/{quadkey}.png'

    His calls are trying to get .png files...

    Hopefully, he controls his tile server.

    I dont have custom tile layer, the request is not requesting a tile, but performing a POST request, to a www.bing.com server, with a payload that seems to be reporting that I somehow previously got a 500 error trying to request a tile from t.ssl.ak.dynamic.tiles.virtualearth.net...

    The error with CORS issue is not the one to the virtualearth.net, it the one that tries to warn your team that there was an issue.

    The next step I could go for is to pull out the call stack as to where this error is actually been reported from in Bing's SDK, but since I really feels that the posts are not really read correctly, I dont feel like bothering with it, as I'd probably be wasting my time.

    Tuesday, November 20, 2018 1:22 PM
  • Hi Raphael,

    I am sorry you feel your posts are not read correctly but potentially you are not providing enough information. For example, you just mentioned the 500 issue.  This is likely due to the fact that the tile server URL does change when the imagery is updated so you will need to use the Metadata call to get a fresh URL at each launch.

    https://msdn.microsoft.com/en-us/library/ff701716.aspx

    Microsoft has a fairly comprehensive template we use internally to ensure enough data is collected for bug reporting.  I have created a much smaller version of that template for external use that might help you provide enough information for someone at Microsoft can see your issue:

    ENVIRONMENT:

    What Computers, OS and devices are involved with this repro? How are they connected? What needs to be setup for someone at Microsoft to reproduce your error?

    REPRO STEPS:

    What steps do I need to follow to see the issue?

    RESULTS:

    What did you Expect to happen?

    What did Actually happen?

    NOTES:

    Any other details/workarounds potentially related info

    Please replace the italic portions with your specific details as that will go quite a long way in Microsoft successfully diagnosing your issue.

    Sincerely,

    IoTGirl


    Wednesday, November 21, 2018 5:07 AM
    Owner
  • Hi Raphael,

    The V8 control team has reviewed your issue and have asked for more details.  Specifically:

    1. The error listed above is a Bing.com test and should not impact functionality

    2. Can you provide a sample page showing how do you call our SDK? Or a public URL showing your map page? 

    3. Can you document the issue as it appears on your map instance?  What is the functionality impacted?

    Sincerely,

    IoTGirl

    Wednesday, November 21, 2018 5:09 PM
    Owner
  • Hi,

    Regarding your previous post, the 500 error was shown in the image that I attached, so I started wondering after looking at your answers if the system you use to access the forum was different than the public version, and if you were actually seeing images from the initial post?

    Anyway, for the questions in the last post, here are my answers:

    1. Good to get that confirmation.
    2. Yes, however it is a bit different, see the Description below.
    3. As you mention in point 1, this does not impact my map, at least not visually (I dont see holes or stuff like that) It only gives CORS errors, and probably impact the reports that your team are probably not getting, as this is not only used for Tile issue, but for other stuff as well, (Image D) which probably dont work correctly neither.

    Description

    1. Go to https://www.bing.com/api/maps/sdk/mapcontrol/isdk/loadmapasync
    2. Select Aerial layer
    3. Zoom in to the furthest that the map allow, then "play" with the zoom in and out, and move around a bit.
    4. For my tests, I was around Montreal, Quebec, Canada, but I've seen it occurs elsewhere too, however I couldn't find a "hot spot" to get these error, and as you can see, my browser language is set to en-CA.

    Note that none of these actually generates CORS errors as they are served from www.bing.com, however I dont have much time to set up a public website for this, so I think the issue can be tracked from your own site. (I tried to find "live" examples on other site but this is the one I found) I think that setting that same demo site on a different domain would actually start generating the CORS errors.

    Image A: This is the listing of all network calls, we can see that most calls that are in the form 030230333...?mkt=en-CA&it=A,G,RL... are of type "jpeg" with a size in KB. However there are some that are actually of type "text/plain" and size of around 350B.

    Image B: This is the detail of the first "text/plain" call, which does have a allow-control-allow-origin header, but a content-length of 0 and an x-ve-tile-info of "no-tile".

    Image C: This is the detail of the "lsp.aspx" call that relates to the Image B call (see the "stack" in the Request Payload. Notice that this call does not have an Allow-control-allow-origin header, and while it does work in that example since it is a call to its self domain, it is the call that is throwing CORS error on my site. There is no special SDK configuration to get these calls.

    Image D: While doing these test, I found that this call was made systematically when opening that URL, this is a different report, but it is using the same report mechanism, with no "Allow-control-access-origin" header. So I thought that since this was systematic, it might help find what function actually makes these calls. However I did not get that particular call on my own map, so I'm not sure where this one comes from.

    Image A

    Image B

    Image C

    Image D

    Thursday, November 22, 2018 2:58 PM
  • I noticed that for the Image D, the payload is not shown in the screenshot, here it is:

    <ClientInstRequest>
    <Events>
    <E>
    <T>Event.ClientInst</T>
    <IG>CF0E7EF680904FEC871C1E58B4FE8E86</IG>
    <TS>1542899129041</TS>
    <D><![CDATA[{
    "feature":"IS",
    "action":"C",
    "data":{
    "version":"release1",
    "target":"RUN",
    "scenario":"loadmapasync",
    "mode":"JS"
    },
    "T":"CI.ClientClick",
    "FID":"CI"}]]>
    </D>
    </E>
    </Events>
    </ClientInstRequest>

    Raphael


    Thursday, November 22, 2018 3:07 PM
  • Hi Raphael,

    I still don't have a clear understanding of how this is impacting your usage of the control.  The developer from the Maps control team asked for the call that you are using such that he might try it and see your issue.  The bing maps cors error is literally there just to confirm if you are or not on the bing domain.  It should have zero impact.

    So specifically can you please provide the steps to see the error and expected versus actual results?

    Sincere thanks,

    IoTGirl

    Friday, November 23, 2018 8:59 AM
    Owner
  • I give up, I wanted to help, but I'm spending too much time on this, and I don't feel like helping anymore.

    I'm not making calls to anything, I instantiates a map control, switch to aerial then browse in it using the mouse pointer and wheel. (I get that I didn't specifically use "mouse pointer and wheel" in the previous post, but "zoom in and out, and move around a bit" was meant to be executed with the mouse), and when doing so, sometimes CORS errors appears.

    Why a public SDK is throwing error if it is not used on its provider web site is beyond me, but it seems that this is expected behavior.

    The impact is CORS errors that shows up in console, I don't expect errors to show up that I cannot fix when doing a simple use of a SDK.

    Friday, November 23, 2018 1:56 PM
  • Hi Raphael,

    So there is no actual issue with the usage of the control?  You are having no issue except the test for Bing.com shows up in your console window?

    I can confirm that message is for debugging and that is why it is expected in a console window.  The team will evaluate removing it in the future based on your confusion.

    Sincerely,

    IoTGirl


    Saturday, November 24, 2018 7:27 AM
    Owner