Closed Bug 1615844 Opened 5 years ago Closed 7 months ago

Cannot prevent Firefox from telling sites to serve WebP images

Categories

(Core :: Networking: HTTP, defect, P3)

73 Branch
defect

Tracking

()

RESOLVED DUPLICATE of bug 1711622

People

(Reporter: moltres.facesits.justin.coolidge, Unassigned, NeedInfo)

References

()

Details

(Whiteboard: [necko-triaged])

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:73.0) Gecko/20100101 Firefox/73.0

Steps to reproduce:

Try to download this JPG: https://res.cloudinary.com/lmn/image/upload/e_sharpen:100/f_auto,fl_lossy,q_auto/v1/gameskinnyc/l/a/s/last-guardian-banner-15jun15-q76w-91802.jpg

It downloads as .webp instead
type in about:config
set Set image.webp.enabled to false.
Set image.http.accept to /.
Close and reopen Firefox

Actual results:

Despite image.webp.enabled is set to false, and image.http.accept is set to /.

Firefox still downloads ALL images as webp

Expected results:

Not only should Firefox NOT revert my changes to those setting after it updated,
Firefox should download that image as jpg because image.webp.enabled is set to false.

(In reply to Moltres Rider from comment #0)

Try to download this JPG

It works fine if you right-click and choose Save Link As… or if you save the image from the Page Info window, Media tab.
(Note: this seems to be the image source)

Set image.webp.enabled to false.

That just controls whether the browser will display such images. The server will still try to serve you such files based on the Accept header; it's just that you'll get a download prompt because Firefox won't show the image.

Set image.http.accept to /.

If I'm not mistaken, that's for inline images. If you'll look at the Browser Console, you'll see request header for the standalone image is Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 so the server gives you a WebP image. This change was introduced in bug 1544231. I'm not sure if there's a preference to control that header.

Has STR: --- → yes
Component: Untriaged → Networking: HTTP
Product: Firefox → Core
Summary: Firefox ignores about:config settings → Cannot prevent Firefox from telling sites to serve WebP images
See Also: → 1614646
See Also: 16146461544231

(fixed the bad bug linking)

So, there is no preference to change the Accept header. It's hard to have an Accept header for navigational requests that would satisfy all possible scenarios. If the site sees WebP as a better option and we announce that we support it, the site can serve it.

Would providing a new preference to alter the Accept header for nav requests, or linking the image.webp.enabled existing preference to affect the Accept header value be enough to fix this bug?

(In reply to Gingerbread Man from comment #1)

Set image.webp.enabled to false.

That just controls whether the browser will display such images. The server will still try to serve you such files based on the Accept header; it's just that you'll get a download prompt because Firefox won't show the image.

If Firefox won't show webp images, it should not offer image/webp in the Accept header. I concur with Honza.

Would providing a new preference to alter the Accept header for nav requests, or linking the image.webp.enabled existing preference to affect the Accept header value be enough to fix this bug?

Flags: needinfo?(moltres.facesits.justin.coolidge)

Upon closer inspection, this looks like a case of user agent sniffing:
I used Header Editor to remove ,image/webp from the Accept header, but still got served a WebP (Browser Console shows that the header value was indeed modified).
When changing the User-Agent header to IE11's, I got served a WDP image. When changing it to a blank value, I got served a JPG.

(In reply to Honza Bambas (:mayhemer) from comment #2)

linking the image.webp.enabled existing preference to affect the Accept header value

(In reply to Masatoshi Kimura [:emk] from comment #3)

If Firefox won't show webp images, it should not offer image/webp in the Accept header. I concur with Honza.

This still seems sensible, though it wouldn't affect this particular server.

(In reply to Gingerbread Man from comment #5)

Upon closer inspection, this looks like a case of user agent sniffing:
I used Header Editor to remove ,image/webp from the Accept header, but still got served a WebP (Browser Console shows that the header value was indeed modified).
When changing the User-Agent header to IE11's, I got served a WDP image. When changing it to a blank value, I got served a JPG.

You also said Save Link As and Page Info > Media worked. And indeed changing the Accept header to */* worked for me.
(By the way, you can edit the request header using the built-in Network Monitor.)

(In reply to Masatoshi Kimura [:emk] from comment #6)

You also said Save Link As and Page Info > Media worked. And indeed changing the Accept header to */* worked for me.

I see your point. Both of those send Accept: */* (with the default user agent string, of course). I tested it separately by modifying the header and just loading the link and Page Info did show the image was a JPG. But would */* be the value of the Accept header with image.webp.enabled = false if that preference gets tied to it?

(By the way, you can edit the request header using the built-in Network Monitor.)

In a brand new profile, I still get a WebP if I use the Network Monitor with the cache disabled to edit and resend with ,image/webp removed from the Accept header.

(In reply to Gingerbread Man from comment #5)

When changing the User-Agent header… to a blank value, I got served a JPG.

Nevermind this part. I guess it was a fluke. I did test several times before, but now an empty user agent string reliably results in WebP. No extensions enabled, set via general.useragent.override, and double-checked via about:support and the Browser Console that it's working.

(In reply to Andy Grover [:grover] from comment #4)

Would providing a new preference to alter the Accept header for nav requests, or linking the image.webp.enabled existing preference to affect the Accept header value be enough to fix this bug?

I think this is all we can do, but doing this doesn't fix the problem in this bug.
Note that the server only sends JPG content with Accept: */*. Removing image/webp is not enough.

Severity: normal → S4
Priority: -- → P3
Whiteboard: [necko-triaged]

FYI, Chrome behaves the exact same way here.

When setting the image.http.accept pref to image/png,image/svg+xml,image/*;q=0.8,*/*;q=0.5 the image loads as a jpg.
We'll probably be changing the default accept for images to be spec compatible in bug 1711622

Status: UNCONFIRMED → RESOLVED
Closed: 7 months ago
Duplicate of bug: 1711622
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.