Add MIME sniffing for images.

[SimonSapin]

The web has lots of broken legacy content served with incorrect MIME types in the HTTP Content-Type header. Web browsers "sniff" the actual type of images by looking at the first few bytes:

http://mimesniff.spec.whatwg.org/

WeasyPrint currently trusts the header for PNG and SVG, and gives everything to GDK-PixBuf which does some form of sniffing which might not be the same as in the WHATWG spec.

Re-implementing sniffing in WeasyPrint is probably overkill, but we could at least give GDK-PixBuf a try when explicit PNG or SVG decoding fails.

[alejoar]

Any chances of this being solved at some point?

I'm running into the #103 issue and I have A TON of images with wrong Content-Type in my server. This is obviously a problem with how we save images and I'll work on solving that asap, but fixing what's already in our server is going to be a major hassle.

Edit: As a suggestion, and ignoring how WeasyPrint works internally, maybe a 'quick' fix could be to raise an exception when this happens so I can treat it. As of today, no exception is raised at all and the PDF is still generated, but without the problematic images.

[liZe]

Current implementation:

1. If it's said to be a SVG, render the image with CairoSVG or abort.
2. If it's said to be a PNG, render the image with Cairo or abort.
3. If it's something else, render the image with GDK-Pixbuf or abort.

According to the sniffing "spec":

1. OK, as we have to rely on the given mimetype the for XML-based images.
2. Real problem. A JPEG/SVG/… image with a image/png mimetype is not rendered, but it actually should be.
3. Probably OK. It's the fallback, we let GDK-Pixbuf do the sniffing. It's close to what browsers do.

Without implementing the "spec", here's what I've done:

1. If it's said to be a SVG, render the image with CairoSVG or abort.
2. If it's said to be a PNG, render the image with Cairo, or with GDK-Pixbuf if it failed with Cairo, or abort.
3. If it's something else, render the image with GDK-Pixbuf or abort.

It's closer to what's done by browsers and should be OK for "the real life cases". Problems left:

• We rely on the GDK-Pixbuf's sniffing algorithm that may be different from the "spec".
• An SVG with the wrong Content-Type and extension is rendered by GDK-Pixbuf.
• A PNG with the wrong Content-Type and extension is rendered by GDK-Pixbuf.

@alejoar I suppose that your problem is non-PNG files served with a PNG Content-Type, because the other cases should already be rendered according to the sniffing "spec". Could you try with the fix to see if it fixes your problem?

As of today, no exception is raised at all and the PDF is still generated, but without the problematic images.

Yes, that's what browsers do too. Adding an option to raise an error when an image is not found is possible, but relying on the logs is probably easier and let the user filter the warnings that are important for him.

[SimonSapin]

I’ve thought before of adding a "strict mode" flag that makes any error fatal (including fetching and decoding images but also stylesheets) but never got around to it.

With web browsers there is typically a human looking at the screen, and if something goes wrong it’s better to show them as much as possible rather than just this:

They can hit the "Refresh" button to try again.

WeasyPrint however is more typically used in automated systems that may be unattended, where it’s better for errors not to pass silently, so that we can realize more easily they’re happening.

[alejoar]

@alejoar I suppose that your problem is non-PNG files served with a PNG Content-Type, because the other cases should already be rendered according to the sniffing "spec". Could you try with the fix to see if it fixes your problem?

@liZe this was exactly our situation. JPEG files served with PNG Content-Type. I ended up finding the error on our code and managed to solve it, and as for the images already in our server I wrote a simple script to go over all of them and fix the Content-Type. What I actually did is download each image and convert everything to JPEG, as there was a mix of JPEG and PNG (although everything served as PNG) and set proper Content-Type (we use Azure storage, which let me easily mess up the Content-Type months ago and not realize till now when I needed to automatically generate PDFs). Took about 16 hours for the script to finish, but wasn't as bad as I first thought.

Even though this fixed my problem, I really appreciate your effort so I just tried installing from your commit and tested your fix: Works flawlessly!

Here's the detail of my test just so you know:
This is the image: https://wt3002.blob.core.windows.net/static/uploads_dev/wrong_content_type (a JPEG with PNG Content-Type)

Test HTML:

<!DOCTYPE html>
<html>
<head lang="en">
    <meta charset="UTF-8">
    <title>Testing</title>
</head>
<body>
<img src="https://wt3002.blob.core.windows.net/static/uploads_dev/wrong_content_type">
</body>
</html>

Finally:
weasyprint ./weasytest.html ./weasytest.pdf

Results in the following PDF: https://wt3002.blob.core.windows.net/static/uploads_dev/weasytest.pdf

Just what was expected.

@SimonSapin the strict mode you propose is exactly what I thought of when I was thinking in potential solutions to the issue.

Thank you both for the help.

[liZe]

@alejoar 😄.