Fuse can not load image from particular URL

Bug Reports
1

Issue: url1 do not loads

No error messages in the console

  • url1 - Image which can not be loaded by Fuse
  • url2 - Another image, just to test
  • url3 - Same image as url1 but uploaded to different server

Fuse 1.0.1 (13566)
MacOS

<App>
    <JavaScript>
    module.exports = {
        url1: 'https://www.worldprivilegeplus.com/resources/images/e8899d12-404d-4a55-87d0-0aa2d69b21b1.jpg',
        url2: 'https://s3-us-west-1.amazonaws.com/neon-dev/business/523/16688_58045758cf411.jpg',
        url3: 'https://s3-us-west-1.amazonaws.com/neon-global/1/3296_594e01d05044f.jpg'
    }
    </JavaScript>
    <StackPanel>
        <Rectangle Width="100" Height="100">
            <Image Url="{url1}" Layer="Background" />
        </Rectangle>
        <Rectangle Width="100" Height="100">
            <Image Url="{url2}" Layer="Background" />
        </Rectangle>
        <Rectangle Width="100" Height="100">
            <Image Url="{url3}" Layer="Background" />
        </Rectangle>
    </StackPanel>
</App>
2

Hi,

so you’re saying that if you upload the same image to another server, it then loads fine from that other server?

If that is the case, then the problem must be in how the first server serves content. It might be anything, like wrong / incomplete content-type headers because of the server configuration etc.

3

Yes exactly same file uploaded to another server is working fine.
Would be great to have some error message in the console or hint on what’s wrong.

4

Well for now you could simply open the picture from both servers and compare what’s the difference in the requests/responses. I’m fairly certain that would be a great starting point to understand what’s wrong - with the first server, or with how Fuse handles a particular header config.

Without that information, there’s very little we can do, since any one server on the internet may have a totally unique configuration.

5

Here is what I found.
Response headers for both images below.

Image with a problem:

accept-ranges:bytes
access-control-allow-credentials:
access-control-allow-headers:
access-control-allow-methods:
access-control-allow-origin:
access-control-expose-headers:
cache-control:public, max-age=86400
cf-cache-status:MISS
cf-ray:374ed914fd168691-ARN
content-length:94056
content-type:image/jpeg
date:Mon, 26 Jun 2017 08:38:01 GMT
etag:W/"16f68-153617899d8"
expires:Tue, 27 Jun 2017 08:38:01 GMT
last-modified:Thu, 10 Mar 2016 17:00:07 GMT
server:cloudflare-nginx
status:200
vary:Accept-Encoding
x-content-type-options:nosniff
x-dns-prefetch-control:off
x-download-options:noopen
x-frame-options:SAMEORIGIN
x-xss-protection:1; mode=block

Same image from another server:

Accept-Ranges:bytes
Content-Length:110661
Content-Type:image/jpeg
Date:Mon, 26 Jun 2017 08:39:21 GMT
ETag:"b3758f6c82870270eed820279c80e6a6"
Last-Modified:Sat, 24 Jun 2017 06:08:17 GMT
Server:AmazonS3
x-amz-id-2:EqpnNLuQ8+gGY+YFBZseu4AoL3mBgd9/Cyae/ZN4VTrohdkHC0CFUSNDIkmV5MBWv06geXXWUuQ=
x-amz-request-id:44B9F49BA4FF0A96
6

This appears like it could be a defect, so an internal issue to investigate it further has been raised.

Thanks for testing and providing a proper repro and the headers responses!