Images on Coursera...

[Abdorhman]

Hi there, Palemoon is unable to load Images on Coursera, I'm using the latest version (27.4.2), the problem occurs on both Gnu/Linux and Windows 8

respectfully

[adesh]

I can confirm. Images not being displayed on https://www.coursera.org/
DevTools show that image is actually getting transferred across the wire.

[coffeebreak]

Confirmed also on Windows 7 x86, PM 27.4.2

[Moonchild]

If inspected, the images linked as background image come up with "could not load the image", so there is an issue with them.

Looking further, the problem is that the image is indicated as being a PNG (by extension as well as MIME type given), but the actual image served is a JPG. The headers also state "nosniff" meaning that the browser is told not to sniff the file contents to determine the file type (even so, stated content type in the header should take precedence). The JPG is therefore fed to the PNG decoder which comes (logically) back with an image that can't be decoded.

To blame here is the use of cloudfront that changes the filetype by recompressing the images on-the-fly as JPG, but sending a MIME type header as image/png indicating the type.

e.g.:

https://d3njjcbhbojbot.cloudfront.net/a ... logo-thumb.png?auto=format%2Ccompress&dpr=1&fit=crop&w=225&h=130

The accompanying headers for it:

X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
X-Firefox-Spdy: h2-16
x-coursera-trace-id-hex: d4f8f3ceac37c163
x-coursera-request-id: zIwW_Y1cEeeU3Q5gvVEEgg
X-Content-Type-Options: nosniff
X-Cache: Hit from cloudfront
X-Amz-Cf-Id: 1xhPZ0zEmGay1nYjoayNqdj4DxnVCxT8dvO4W9mXrN0Ahpjh_t5-FA==
Via: 1.1 85c8f2e63c405fa7a2374a7644319cce.cloudfront.net (CloudFront)
Vary: Accept,Accept-Encoding
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Date: Wed, 30 Aug 2017 08:25:36 GMT
Content-Type: image/png
Content-Encoding: gzip
Cache-Control: public,max-age=604800,must-revalidate
Age: 265010

Actual image is a JPEG when opened. (I had to add a .jpg extension for phpBB to accept it since it refuses mis-matching file types)

jhu-logo-thumb.png.jpg (6.77 KiB) Viewed 1924 times

Pale Moon is doing exactly what it is told to do according to all applicable standards. If other browsers display these images then they are not being standards compliant (and potentially not being as secure as they claim to be by ignoring "nosniff")

[Abdorhman]

Many thanks for CoffreBreak and Adesh, as for Moonchild, is there is anything I can do to change that in my Palemoon??
Of course I'm going to report this to Coursera.

[adesh]

These images issues are becoming a recurring theme (and a time sink).

Interestingly, sending */* in Accept header makes cloudfront return correct content-type.
With Pale Moon Accept header:

Code: Select all

$ curl -I -H "Accept: image/webp,image/jxr,image/png,image/*;q=0.8,*/*;q=0.5" -H 'Accept-Encoding: gzip, deflate' 'https://d3njjcbhbojbot.cloudfront.net/api/utilities/v1/imageproxy/https://d15cw65ipctsrr.cloudfront.net/eb/8e18e0a4f111e59ae9c776a3dd0526/jhu-logo-thumb.png?auto=format%2Ccompress&dpr=1&fit=crop&w=225&h=130'
HTTP/2 200 
content-type: image/png
cache-control: public,max-age=604800,must-revalidate
content-encoding: gzip
date: Sat, 02 Sep 2017 07:30:33 GMT
strict-transport-security: max-age=31536000; includeSubDomains; preload
x-content-type-options: nosniff
x-coursera-request-id: mzB2QY-wEeeUkhKfilZ5nA
x-coursera-trace-id-hex: d2e113796d37860e
x-frame-options: SAMEORIGIN
x-xss-protection: 1; mode=block
vary: Accept,Accept-Encoding
age: 33346
x-cache: Hit from cloudfront
via: 1.1 0aab82de59c9f65f487a4cc5f1234c65.cloudfront.net (CloudFront)
x-amz-cf-id: 86McITlQObZcC0hg8qa7lZn8pA3JsJqhwuWBwL2kZ6tTdDfOFAU-rg==

With */* in Accept header:

Code: Select all

$ curl -I -H "Accept: */*" -H 'Accept-Encoding: gzip, deflate' 'https://d3njjcbhbojbot.cloudfront.net/api/utilities/v1/imageproxy/https://d15cw65ipctsrr.cloudfront.net/eb/8e18e0a4f111e59ae9c776a3dd0526/jhu-logo-thumb.png?auto=format%2Ccompress&dpr=1&fit=crop&w=225&h=130'HTTP/2 200 
content-type: image/jpeg
cache-control: public,max-age=604800,must-revalidate
content-encoding: gzip
date: Tue, 29 Aug 2017 09:29:36 GMT
strict-transport-security: max-age=31536000; includeSubDomains; preload
x-content-type-options: nosniff
x-coursera-request-id: kqdlHYycEeeypA735C_k2g
x-coursera-trace-id-hex: c2e4b38724a6dc42
x-frame-options: SAMEORIGIN
x-xss-protection: 1; mode=block
vary: Accept,Accept-Encoding
age: 371640
x-cache: Hit from cloudfront
via: 1.1 defdb7d9bab9d18be88a1e6f7db30215.cloudfront.net (CloudFront)
x-amz-cf-id: HG8uZKjrDaW6_St0-JwfAKGX91rHs0tYKVJNdHirL1Yr1UNiSeq0Hg==

Firefox sends */* as Accept header for a image resource, so I'm not sure if Firefox is actually ignoring "nosniff".
I know it will most probaly work in Chrome/Chromium, but can someone please share the results if using those browsers.

[Walter Dnes]

Looking at about:config, "image.http.accept" is string image/webp,image/jxr,image/png,image/*;q=0.8,*/*;q=0.5 It is bold font and labelled as "user set" rather than default. I don't remember setting it directly. Could this have been set somewhere in "Edit ==> Preferences"? Anyhow, changing the string value to */* in "about:config" makes the images display properly.

Hey, waitaminute!!! I just checked again. I manually set it to */* but when I close and reopen, its value changes to image/jxr,*/*. Coursera still displays OK.

EDIT...

I'm using 32-bit linux unstable.

[Moonchild]

It's not a solution to change the conneg header to "*/*". This is a cloudfront issue that cloudfront needs to address! Their "image proxy" needs to be fixed.

The conneg header is required to let websites know that we support both jpeg-xr and webp. If set to */*, these formats will not be served to us and generic fallbacks will be used, which makes our advanced image support moot.

[Abdorhman]

This */* solution works fine with Coursera! not sure though how it will affect other websites.
I saw someone asking about Chrome & Firefox, I just wanted to say that this issue doesn't occur on any of 'em.

[Moonchild]

It will affect other websites in that they will not send jpeg-xr or webp images even though the browser knows how to handle the format.

Chrome and Firefox will send */* by default. This is a problem once again when Firefox enables their own experimental webp support, if they want sites to actually use it.

It's also not a solution, it's a workaround for a broken image mangler of the CDN.

[adesh]

I contacted CloudFront and they say CDN does not determine MIME type but uses the one set by the uploader. But they also said that they'd look into this further.

CloudFront servers don't determine the MIME type for the objects they serve. When you upload an object to your origin, you should set the Content-Type header field for the object." Accordingly, it's possible that Coursera set the MIME type of this content to PNG when they uploaded content to their bucket.

Doing few tests, I even got a 404. So are there any invalid/non-standard values for Accept header?

curl -I -H "Accept: image/webp,image/png,image/*;q=0.8,*/*;q=0.5" -H 'Accept-Encoding: gzip, deflate' 'https://d3njjcbhbojbot.cloudfront.net/a ... =225&h=130'
HTTP/2 404
content-type: text/html
content-length: 778
cache-control: private, no-cache, no-store, must-revalidate, max-age=0
date: Tue, 05 Sep 2017 06:28:06 GMT
{{..}}

Since browsers as well as servers don't seem to follow the spec properly, it might just be better to disable content negotiation on the web, because the ones punished in all this are the ones who follow the rules.

[Moonchild]

CDN does not determine MIME type but uses the one set by the uploader.

That's wrong if they change the file type! if they convert a PNG to JPG by recompressing in their "optimization", they MUST change the type accordingly.

So are there any invalid/non-standard values for Accept header?

No, there aren't.
The conneg header only indicates capacities of the client. It states which types are supported -- the server is free to ignore it or respond accordingly. The client/browser is saying: "Just FYI: we support these MIME types.". If invalid or nonsense, the server will (should!) just ignore it.

[Abdorhman]

Moonchild, maybe you should create a new topic somewhere on this forum, explain how to "work around" this issue using the */*, and pin it, so others won't have to suffer with Coursera or Maybe put it in the "Known issues". you can explain that it's not Palemoon's fault if you like.

[Moonchild]

It's not our issue. Users don't have to work around it by crippling our image support this way.
It's also not a known issue -- we are doing exactly what the server tells us to do and the "workaround" is not a workaround for any other situation either -- all it does is kill our extended image support negotiation with servers.
Amazon simply needs to fix their problem with cloudfront. Or Coursera needs to stop telling cloudfront to "optimize images" because it's broken. Or both.

[Abdorhman]

I don't really understand everything you web "gures" say, but still, if you were a Coursera user you would probably like to know that there is a way to fix the problem.

[adesh]

There are several problems with that workaround, but I'll point out just one - it makes Pale Moon look "bad" because you are fixing something in the browser while actually it's CDN that is broken.

Here is a simple analogy to help you understand what is going on.
You are the browser and shopkeeper is the CDN.
*/* workaround - you do not state your preference:

1. You go to a coffee shop and say "Give me coffee, any flavour will do."
2. Shopkeeper says "Here is your Espresso" and gives you Espresso.
3. You take it and find that it indeed is what the shopkeeper said. Happy!

Pale Moon default - you state your preference:

1. You go to a coffee shop and say "Give me Cappuccino, but if you do not have that I'll take anything."
2. Shopkeeper says "Here is your Cappuccino" and but gives you Espresso instead.
3. You take it and find that it is not what the shopkeeper said. No images!

In real life, that is not a big issue because of human nature to accomodate but the same is a problem in software as it follows certain protocols and rules, and is restrictive by design for good reasons.

[Abdorhman]

I get it, but I still think it should be announced as an available option for those we count on Coursera for their Education like me. What do you think? Maybe you won't understand me until you put yourself in Coursera's users shoes (is that the right expression?).

[Moonchild]

no. it's nonsense. we can agree to disagree.

[Moonchild]

An update on this; because of a known issue with "save as" on image requests not sending the http img conneg header, I got a jpeg, but the cloud edge actually converts it to WebP for those connections, which is why the conneg header change works around the problem. Because of the mismatching content-type (and no sniffing by content routine for WebP in our code) it would fail to load the images.

"nosniff" is actually not applicable for images, as was pointed out to me, so that part of what i said can be ignored. The cloud edge should still provide the correct content type though, which is still an error on cloudfront's side.