Revision history - OSM Help

Thanks for the info about the servers (from your comment): * iD: Remote Address:23.209.107.4:443 Request URL:https://ecn.t0.tiles.virtualearth.net/tiles/a0303221012133023123.jpeg?g=587&mkt=en-gb&n=z * potlatch: Remote Address:23.209.107.4:80 Request URL:http://ecn.t0.tiles.virtualearth.net/tiles/a0303221012133023032.jpeg?g=587&mkt=en-gb&n=z I think I got it now: It seems you are served by a Akamai (this is a content distribution service which is apparently used by Microsoft) server from Cambridge (23.209.107.4) (USA) and I by one from Switzerland (2.20.118.87). The *interesting* part (I just hope that I did not make a stupid mistake somewhere): I have circumvented DNS (via [hosts file](//en.wikipedia.org/wiki/Hosts_%28file%29)) and targeted my requests to the Cambridge server (23.209.107.4). Observation: This server serves different images via HTTP respectively HTTPS! Tested with `ecn.t0.tiles.virtualearth.net/tiles/a0303221012133023123.jpeg?g=587&mkt=en-gb&n=z`. Here are screenshots with and without https, ctrl+f5 of course (see in log below: HTTP200 – not HTTP304): [gif animation Cambridge](/upfiles/bingshttpscdnfail_cambridge.gif). Then I reverted my hosts file change (so I am back on 2.20.118.87 via DNS): same, new, content via HTTP respectively HTTPS. [gif animation Switzerland](/upfiles/bingshttpscdnfail_swiss.gif). Note the much faster timing than from Cambridge (that is the reason why usually the nearest server is assigned to you). By the way: Others from near Cambridge or even the whole USA (those "others" who get assigned to this server by MS/Akamai's DNS system) should experience the same as you. As far as I know/guess all who commented here are not editing from the US. *What to do?* * So in principle you should get the new images if you access via HTTP, I am not sure why it seems that you ~~don't (from~~ do not get the new images (judging from your comment above - – maybe ~~Cache?~~ your browser cache? or does iD always use ~~https?).~~ HTTPS for the bing aerial imagery even if accessed via HTTP?). * As a workaround you could use your hosts file to direct your requests to ecn.t0.tiles.virtualearth.net to the IP of the Switzerland server. Add the line `2.20.118.87 ecn.t0.tiles.virtualearth.net` to your hosts file. Note: apparently Chromium (which you seem to use) does not refresh its DNS cache by ctrl+F5. I used ~~firefox~~ Firefox in my test. Chromium only obeyed the change in the hosts file after a restart. * Ask ~~microsoft~~ Microsoft to sync their CDN servers (whyever there is different content for HTTPS on this server ~~…).~~…). * use HTTP Potlatch, get outside and have a look at the real world, wait, … ;-)

Thanks for the info about the servers (from your comment): * iD: Remote Address:23.209.107.4:443 Request URL:https://ecn.t0.tiles.virtualearth.net/tiles/a0303221012133023123.jpeg?g=587&mkt=en-gb&n=z * potlatch: Remote Address:23.209.107.4:80 Request URL:http://ecn.t0.tiles.virtualearth.net/tiles/a0303221012133023032.jpeg?g=587&mkt=en-gb&n=z I think I got it now: It seems you are served by a Akamai (this is a content distribution service which is apparently used by Microsoft) server from Cambridge (23.209.107.4) (USA) and I by one from Switzerland (2.20.118.87). The *interesting* part (I just hope that I did not make a stupid mistake somewhere): I have circumvented DNS (via [hosts file](//en.wikipedia.org/wiki/Hosts_%28file%29)) and targeted my requests to the Cambridge server (23.209.107.4). Observation: This server serves different images via HTTP respectively HTTPS! Tested with `ecn.t0.tiles.virtualearth.net/tiles/a0303221012133023123.jpeg?g=587&mkt=en-gb&n=z`. Here are screenshots with and without https, ctrl+f5 of course (see in log below: HTTP200 – not HTTP304): [gif animation Cambridge](/upfiles/bingshttpscdnfail_cambridge.gif). Then I reverted my hosts file change (so I am back on 2.20.118.87 via DNS): same, new, content via HTTP respectively HTTPS. [gif animation Switzerland](/upfiles/bingshttpscdnfail_swiss.gif). Note the much faster timing than from Cambridge (that is the reason why usually the nearest server is assigned to you). *What to do?* * So in principle you should get the new images if you access via HTTP, I am not sure why it seems that you don't (from your comment above - maybe Cache? or does iD always use https?). * As a workaround you could use your hosts file to direct your requests to ecn.t0.tiles.virtualearth.net to the IP of the Switzerland server. Add the line `2.20.118.87 ecn.t0.tiles.virtualearth.net` to your hosts ~~file. * Ask microsoft to sync their CDN servers (whyever there is different content for HTTPS on this server …). note:~~ file. Note: apparently Chromium (which you seem to use) does not refresh its DNS cache by ctrl+F5. I used firefox ~~therefore.~~ in my test. Chromium only obeyed the change in the hosts file after a ~~restart.~~restart. * Ask microsoft to sync their CDN servers (whyever there is different content for HTTPS on this server …).

Thanks for the info about the servers (from your comment): * iD: Remote Address:23.209.107.4:443 Request URL:https://ecn.t0.tiles.virtualearth.net/tiles/a0303221012133023123.jpeg?g=587&mkt=en-gb&n=z * potlatch: Remote Address:23.209.107.4:80 Request URL:http://ecn.t0.tiles.virtualearth.net/tiles/a0303221012133023032.jpeg?g=587&mkt=en-gb&n=z I think I got it now: It seems you are served by a Akamai (this is a content distribution service which is apparently used by Microsoft) server from ~~the~~ Cambridge ~~(23.209.107.4), US~~ (23.209.107.4) (USA) and I by one from Switzerland (2.20.118.87). The *interesting* part (I just hope that I did not make a stupid mistake somewhere): I have circumvented DNS (via [hosts file](//en.wikipedia.org/wiki/Hosts_%28file%29)) and targeted my requests to the Cambridge server (23.209.107.4). Observation: This server serves different images via HTTP respectively HTTPS! Tested with `ecn.t0.tiles.virtualearth.net/tiles/a0303221012133023123.jpeg?g=587&mkt=en-gb&n=z`. Here are screenshots with and without https, ctrl+f5 of course (see in log below: HTTP200 – not HTTP304): [gif animation Cambridge](/upfiles/bingshttpscdnfail_cambridge.gif). Then I reverted my hosts file change (so I am back on 2.20.118.87 via DNS): same, new, content via HTTP respectively HTTPS. [gif animation Switzerland](/upfiles/bingshttpscdnfail_swiss.gif). Note the much faster timing than from Cambridge (that is the reason why usually the nearest server is assigned to you). *What to do?* * So in principle you should get the new images if you access via HTTP, I am not sure why it seems that you don't (from your comment above - maybe Cache? or does iD always use https?). * As a workaround you could use your hosts file to direct your requests to ecn.t0.tiles.virtualearth.net to the IP of the Switzerland server. Add the line `2.20.118.87 ecn.t0.tiles.virtualearth.net` to your hosts file. * Ask microsoft to sync their CDN servers (whyever there is different content for HTTPS on this server …). note: apparently Chromium does not refresh its DNS cache by ctrl+F5. I used firefox therefore. Chromium only obeyed the change in the hosts file after a restart.

Thanks for the info about the servers (from your comment): * iD: Remote Address:23.209.107.4:443 Request URL:https://ecn.t0.tiles.virtualearth.net/tiles/a0303221012133023123.jpeg?g=587&mkt=en-gb&n=z * potlatch: Remote Address:23.209.107.4:80 Request URL:http://ecn.t0.tiles.virtualearth.net/tiles/a0303221012133023032.jpeg?g=587&mkt=en-gb&n=z I think I got it now: It seems you are served by a Akamai (this is a content distribution service which is apparently used by Microsoft) server from the Cambridge (23.209.107.4), US and I by one from Switzerland (2.20.118.87). The *interesting* part (I just hope that I did not make a stupid mistake somewhere): I have circumvented DNS (via [hosts file](//en.wikipedia.org/wiki/Hosts_%28file%29)) and targeted my requests to the Cambridge server (23.209.107.4). Observation: This server serves different images via HTTP respectively HTTPS! Tested with `ecn.t0.tiles.virtualearth.net/tiles/a0303221012133023123.jpeg?g=587&mkt=en-gb&n=z`. Here are screenshots with and without https, ctrl+f5 of course (see in log below: HTTP200 – not HTTP304): [gif animation Cambridge](/upfiles/bingshttpscdnfail_cambridge.gif). Then I reverted my hosts file change (so I am back on 2.20.118.87 via DNS): same, new, content via HTTP respectively HTTPS. [gif animation ~~Switzerland](/upfiles/bingshttpscdnfail_swiss.gif).~~ Switzerland](/upfiles/bingshttpscdnfail_swiss.gif). Note the much faster timing than from Cambridge (that is the reason why usually the nearest server is assigned to you). *What to do?* * So in principle you should get the new images if you access via HTTP, I am not sure why it seems that you don't (from your comment above - maybe Cache? or does iD always use https?). * As a workaround you could use your hosts file to direct your requests to ecn.t0.tiles.virtualearth.net to the IP of the Switzerland server. Add the line `2.20.118.87 ecn.t0.tiles.virtualearth.net` to your hosts file. * Ask microsoft to sync their CDN servers (whyever there is different content for HTTPS on this server …). note: apparently Chromium does not refresh its DNS cache by ctrl+F5. I used firefox therefore. Chromium only obeyed the change in the hosts file after a restart.

Thanks for the info about the servers (from your comment): * iD: Remote Address:23.209.107.4:443 Request URL:https://ecn.t0.tiles.virtualearth.net/tiles/a0303221012133023123.jpeg?g=587&mkt=en-gb&n=z * potlatch: Remote Address:23.209.107.4:80 Request URL:http://ecn.t0.tiles.virtualearth.net/tiles/a0303221012133023032.jpeg?g=587&mkt=en-gb&n=z I think I got it now: It seems you are served by a Akamai (this is a content distribution service which is apparently used by Microsoft) server from the Cambridge (23.209.107.4), US and I by one from Switzerland (2.20.118.87). The *interesting* part (I just hope that I did not make a stupid mistake somewhere): I have circumvented DNS (via [hosts file](//en.wikipedia.org/wiki/Hosts_%28file%29)) and targeted my requests to the Cambridge server (23.209.107.4). Observation: This server serves different images via HTTP respectively HTTPS! Tested with `ecn.t0.tiles.virtualearth.net/tiles/a0303221012133023123.jpeg?g=587&mkt=en-gb&n=z`. Here are screenshots with and without https, ctrl+f5 of course (see in log below: HTTP200 – not HTTP304): [gif animation Cambridge](/upfiles/bingshttpscdnfail_cambridge.gif). Then I reverted my hosts file change (so I am back on 2.20.118.87 via DNS): same, new, content via HTTP respectively HTTPS. [gif animation Switzerland](/upfiles/bingshttpscdnfail_swiss.gif). *What to do?* * So in principle you should get the new images if you access via HTTP, I am not sure why it seems that you don't (from your comment above - maybe Cache? or does iD always use https?). * As a workaround you could use your hosts file to direct your requests to ecn.t0.tiles.virtualearth.net to the IP of the Switzerland ~~server.~~ server. Add the line `2.20.118.87 ecn.t0.tiles.virtualearth.net` to your hosts file. * Ask microsoft to sync their CDN servers (whyever there is different content for HTTPS on this server …). note: apparently Chromium does not refresh its DNS cache by ctrl+F5. I used firefox therefore. Chromium only obeyed the change in the hosts file after a restart.