CORS trouble again ...

    Hi,

    I'm in way over my head here. I'm still playing around with krpano 1.17.pr2. I have coded a "proof-of-concept" where the main content is hosted at http://panographica.dk (an alias for an S3 bucket). All my tiles, xml, krpano js, swf and skins are hosted at http://tiles.panographica.dk (A cname for an S3 bucket).

    Everything appeared to work fine. I had tested with IE11, FF26, CHROME32 and Opera 18. Now I'm told that Safari uses on macs have trouble viewing the page. The first time they visit a panorama everything works, but the second time they try they are greeted with the following:

    INFO: krpano 1.17.pr2 (build 2014-01-10)
    INFO: Desktop/MacIntel - Safari 7.0.1
    INFO: Registered to: Christian Obel
    ERROR: plugin[btn_in] loading error: http://tiles.panographica.dk/krpano/single/skin/buttons.png
    ERROR: plugin[btn_out] loading error: http://tiles.panographica.dk/krpano/single/skin/buttons.png
    ERROR: plugin[btn_lft] loading error: http://tiles.panographica.dk/krpano/single/skin/buttons.png
    ERROR: plugin[btn_rgt] loading error: http://tiles.panographica.dk/krpano/single/skin/buttons.png
    ERROR: plugin[btn_up] loading error: http://tiles.panographica.dk/krpano/single/skin/buttons.png

    ...
    The error console in Safari says "Cross-origin image load denied by Cross-Origin Resource Sharing policy."

    I do not a have a mac, so my debugging options are limited. I tried viewing the panos on an ipad and that experience was inconsistant. Sometime I could see a pano and sometime I could not.

    My CORS settings for the tiles.panographica.dk bucket are:

    <?xml version="1.0" encoding="UTF-8"?>
    <CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
    <CORSRule>
    <AllowedOrigin>http://panographica.dk</AllowedOrigin>
    <AllowedMethod>GET</AllowedMethod>
    <MaxAgeSeconds>3000</MaxAgeSeconds>
    <AllowedHeader>*</AllowedHeader>
    </CORSRule>
    </CORSConfiguration>

    Lots of googling did not make me wiser than I was before *sad*
    Does anybody have an idea about what I'm to look for?

    Best regards,

    Einmal editiert, zuletzt von obel (15. Januar 2014 um 23:33)

    I've been playing with Safari 7.0.1 (9537.73.11) on Maverick. Here is what I experience. The first time I load a panorama, everything works as expected. The second time I load I only get the panorama and I get load errors for the images in the skin and for the thumbnails for the tours. The skin and the thumbnails reside on the same domain as the panorama tiles and has the same CORS settings.

    The error console says "Cross-origin image load denied by Cross-Origin Resource Sharing policy.".

    If I use the "Empty caches" in the Develop menu then It repeats. First time fine, next time only panorama loads and no images in the skin.

    Best regards,
    obel

    EDIT:


    Still in over my head, but I have been inspecting the Error Console in Safari. From the timeline I deduce that the skin image files and the thumbs get loaded twice with different request headers. I assume this causes one of the loaded versions to get cached and that this cached version somehow has the wrong CORS "settings" cached. This causes a cache hit, but a CORS failure on the next requests. Something like that. Does it sound crazy?

    Turns out that if I set Cache-Control: max-age=0 then things work again.

    Best regards,
    Obel

    EDIT:


    I've changed the site so that all files reside within one single domain and so that CORS is not needed.
    There might still be an issue here worth looking into.


    Best regards,
    Obel

    2 Mal editiert, zuletzt von obel (19. Januar 2014 um 00:24)

    Hi,

    it works that way:

    The images itself will be loaded via JS (with the HTML5 crossOrigin setting) to be able to get the information about the image itself (size). But then the rendering/displaying of the image will be done via CSS 'background-image'.

    And here the problem - CSS 'background-image' can't have a crossOrigin setting and therefore the browser is requesting the images differently and also getting different response headers from the Server.

    That means that is a bit a problem of HTML5 specs itself - the crossOrigin is missing for the background images and there is no way to access the background image object directly from JS.

    In the most browsers this doesn't seem to be a problem, but in Safari it seems to be one. It seems Safari isn't caching the response headers together with the image (I would calls this a Safari bug), so it gets problems when loading the image again from cache.

    But I will look into that topic and try to find a workaround of course.

    Best regards,
    Klaus

    Hi Klaus,

    after browsing a lot, and testing a lot, i narrowed my situation as exactly described here.

    We have a player, which loads the scenes just fine,
    but static images like thumbs are not loaded.
    thumbs are loaded via a layer, and the url to a amazon server.

    Console giving the cross-origin error on these images.

    this only happens on mac osx chrome, safari, and i believe the iOs devices as well.

    Do you have any suggestion or workaround, or even a fix for loading the images?

    Since, as you said, this is browser specific.

    Many thanks,

    Sander


    version 1.19

    Hi,

    there is Safari CORS bug related to the http headers (probably the 'Vary: Origin' header?) that Amazon S3 is using by default.

    On the first load request everything works, but Safari isn't caching the CORS headers, so when reloading and Safari loads the files from its cache, then the CORS header are missing and so the loading is failing this time.

    There are several threads about that Safari+S3 problem on the web - e.g.:
    https://github.com/photonstorm/phaser/issues/1355
    https://forums.aws.amazon.com/message.jspa?messageID=445325
    http://stackoverflow.com/questions/1249…ew-cors-request

    But there is no 'good' solution so far I see or know...

    But a 'bad' (and working) solution would be possible by disabling the browser caching (either via modifying the urls to be different each time) or by adding no-caching http headers (in the server setup).

    E.g. add to any url:

    Code
    ?nocache=%$random%

    at the end.

    This would prevent the caching of that file because the url will be always randomly different.

    Best regards,
    Klaus

    doohhh, so simple!!!

    yes, that works

    i generate the xml on the backend, and now i add a time stamp to the parameter.
    'url' => $thumb_url . '?nocache=' . time(),


    that did the trick!

    not nice, but works fine


    Thanks Klaus!

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden