Mark Straver Reporter
	Description • 8 years ago

Currently, image.http.accept is used as a "special case" header to send different accepted mime types for images (with the addition of image/webp and other formats not guaranteed to be supported by all browsers, this becomes useful once more after bug 1249474).

Servers will be using conditional content responses based on this header.

This all works perfectly fine, except for the situation where a user wants to use "Save image as" -- in that case, the default header is sent and not the image header.

Firefox should send the header as specified in image.http.accept for "Save image as" to make it possible for the user to save the image as-presented in the page, and not in some other format.

	Mark Straver Reporter
	Comment 1 • 8 years ago

> Component: Networking: HTTP → ImageLib

Are you sure this is the right component? I wouldn't think the actual imagelib component for display of images would have anything to do with what requests are sent over HTTP in the headers (I based my initial component selection on similar bug components)...

	Timothy Nikkel (:tnikkel)
	Comment 2 • 8 years ago

(In reply to Mark Straver from comment #1)
> > Component: Networking: HTTP → ImageLib
> 
> Are you sure this is the right component? I wouldn't think the actual
> imagelib component for display of images would have anything to do with what
> requests are sent over HTTP in the headers (I based my initial component
> selection on similar bug components)...

It doesn't look like any imagelib code is called when we "save image as". No imgLoader::LoadImage* function is called when we do "save image as". It looks like the code responsible might live in toolkit/content/contentAreaUtils.js, specifically internalSave, and saveImageURL. They might hand off the job of creating the network request to someone else, I'm not sure. I'm going to move this to toolkit for now, if anyone has a better idea please feel free to move it again.

	Mark Straver Reporter
	Comment 3 • 6 years ago

Revisiting this since it's been a good while and it's still a problem whenever visiting websites that use content negotiation for images...

I looked at the code involved, and :tnikkel is correct in where this lives.
saveImageURL calls internalSave, which passes it to internalPersist to perform the actual download.
This is where it gets interesting, because internalPersist passes it off to C++ from there on with persist.savePrivacyAwareURI() -- which offers the option to pass extra headers to the request. Extra headers isn't used in internalPersist at the moment and it sets it to null. If that call can be changed to actually pass the image "Accept:" header, that might do the trick IIUC? It may need an extra flag passed down so internalPersist knows that the calling site was actually saveImageURL and not another function, and should pass the image "Accept:" header then...

The only question is what nsWebBrowserPersist::SaveURIInternal (called from nsWebBrowserPersist::SavePrivacyAwareURI) does with an offered "Accept:" header, since a default Accept: would likely already be defined and I don't think you can or should merge them in that case.