That's always a site server's decision, not Chrome's.
They detect Chrome browser and send WebP because Chrome supports it.
You can use an extension that changes UserAgent string for that site specifically or you can report the issue to their support email/whatever.

Able to reproduce the issue on reported chrome version 64.0.3282.140 and on the latest canary 66.0.3336.0 using Ubuntu 14.04 and Windows 10.
Note: The issue is not seen on Mac 10.13.1.
As the issue is seen from M60(60.0.3072.0) considering it as non-regression and marking it as Untriaged. Hence removing label Needs-Bisect.

Thnks!

The site is sending us a webp file, complete with the corresponding Content-Type header.  On the web, the Content-Type is what matters, not the file name, and the server is indeed sending us a valid webp file.  So I don't think there's a bug here, other than possibly not changing the extension when saving the file.

Not sure who owns the relevant code for that. asanka:  Don't suppose you know the owner for that stuff?

+dtrainor

This should ideally be marked as a duplicate of issue 318529 (not duping yet since it's a restricted issue).

Normally downloads will respect a server provided or implied extension. However, for "Save as", there has been a long standing request to preserve the browser's interpreted content-type while saving. I.e. when "Save as" or "Save image as" is invoked, give the file a name such that re-opening the file will cause Chrome to interpret the file in the same manner. That rule would, in this case, force the filename to have a '.webp' extension.

To me there are two issues here:

1. The browser displays a .jpg but saves it as a webp file.
2. The saved file is a webp file but incorrectly has the .jpg extension.

Ideally, I would want to download a jpg as a jpg and a webp as a webp. Don't intercept the jpg and covertly half-convert it to a broken webp when I want to save the file.

Re #7: Chrome isn't converting anything. The website in question detects that the client browser (Chrome) supports the more efficient WebP image format and sends the image as WebP. 

Browsers don't care about file extensions in URLs, but operating systems do.

Deleted: ImageOptimizer.png 9.8 KB

	ImageOptimizer.png 9.8 KB View Download

That may be true, but to the end user, all we see is that downloading the jpg on Chrome is broken, but not broken on FF/IE.

#9, sounds like you want Chrome to patch the site's problem. This approach was used by the old IE and the legacy Opera browser, and the approach discredited itself.

It seems to me that Chromium could look at the Content-Type of the response and replace the default filename/extension in the save dialog.  This might not be possible for all Content-Types, but might be doable for image/* types.  Right?

#10, it's not just motortrend. I've seen the same issue on telegraph.co.uk as well. Example: http://www.telegraph.co.uk/content/dam/Travel/2016/December/zaha-hadid-heydar-aliyev.jpg

So what if it's 2 or 20 or even 2000 or 2kk sites that chose to implement this behavior? It doesn't change the fact that it's a site bug/feature.

Re #12, as you can see in the screenshot in #8, this is a feature of Akamai's Image Manager product.

Re #11, yes, I think that's basically the proposal. Given the Content-Type of the response, we can use the existing MIME database on the client to override the file extension if the Content-Type specified a known image/* type.

RE #10, #13: Chrome is the user's agent, and we do build features to help accommodate users, regardless of the source of a given behavior.

#14, the request in this issue is to "keep the JPG format", and it's not possible for Chrome, because there is no JPG format sent by the site server, there's only WebP, which is what I tried to explain. If Chrome would change the file extension, it won't solve the problem reported in this issue. The real solution would be to add an image converter option i.e. an additional file format in the Save As dialog such as JPG, PNG, for example.

BTW, there are extensions and online converters.
For example, https://chrome.google.com/webstore/detail/save-image-as-jpeg-png-we/cagjgpolpdodlfifipjlgechhcljmchm

Re #14: Chrome isn't likely to transcode the image, no. But saving with the correct file extension (as noted in #6) is reasonable.

#16 yeah I had seen that extension. But I'm not too keen on installing an extension for such a basic function as saving an image file, with the permissions it requires.

+aboss@ for fyi.

I think fixing the file extension for save-as image types makes sense.  While the URL pointed at jpg, Chrome said it can happily receive a webp image and "Save As" should reflect what the server actually sent.

xingliu@ can you take a look?

One interesting point here is that when you do SaveImageAs, Chrome hands the URL over to the Download Manager. When the download manager issues its request, it does so without the Accept header indicating WebP support, so the server may well end up serving up a non-WebP file type when saving. 

The Akamai Image Manager scenario reported here isn't fixed by that behavior because they are not looking for WebP in the Accept header-- instead they look for Chrome in User-Agent header, and that header is unchanged in the download manager.

Chrome shouldn't change the extension that the site is given to the browser.
Also, Chrome shouldn't transcode any image (when saving or showing).

Chrome should only show the true that is given by the website (when saving or showing).

@22: For cases like this the server is deciding to give us content that doesn't line up with the original extension.  In that case the download experience would be broken for the user and the file would potentially be unable to be opened.

I agree we don't really want to transcode the image or change the actual content.  So changing the file extension seems like the best approach to me.

Chrome doesn't change the extension if the site provides a filename via a standard mechanism (i.e. a Content-Disposition header).

This issue only concerns filenames that are derived based on hints from the server response. The URL has historically been an unreliable indicator of file type. E.g. a .php script generating a JPEG stream.

Any update? The supposed owner xingliu@ never posted anything when assigned in Feb 2018.

No there hasn't been.  I can see if we have cycles this quarter to do it though.

@21: Does our net layer intercept these requests and responds from a local cache? 
 Do you know if that incorporates request headers when deciding whether or not to ignore the cache entry?

When generating file name from hints(without Content-Disposition), Chrome currently only replaces the extension based on mime type when the URL contains a query, this won't work for some download URLs. I'm thinking of removing this check.

See https://chromium.googlesource.com/chromium/src/+/73.0.3673.2/net/base/filename_util_internal.cc#149

Are there security concerns with inferring the correct extension?  Should we only correct to non-potentially dangerous file extensions?

If the actual content is executable and Content-Type header give us a non executable mime type, the file extension should be non executable and it's probably operating system's duty to not run the code in the file with non executable extension. Also it won't undermine security since if the URL contains "?" then the behavior is the same.

Also in DownloadTargetDeterminer we generate |virtual_path_| with net::GenerateFileName before safe browsing service check, which needs the URL and |virtual_path_| to see if something like .exe needs content scan. If the mime type is image/jpg and the actual content is executable, it won't trigger safe browsing content check in my understanding.

+vakh@ for safe browsing suggestion, we're not sure if the mime type is a good indicator of file extension for safe browsing.

Summary of this issue:

The download file name can be generated from URL and feed to safe browsing when there is no "Content-Disposition" header. The server may send "Content-Type" to inform the mime type of the file. We plan to replace the file extension based on the mime type.

Currently URL like: "www.example.com/malicious.bad" will generate a file name "malicious.bad" and safe browsing will check it. If we replace the extension with a given mime type, we may generate "malicious.jpg" and bypass some safe browsing check.

Also there are cases like blob URL that can't generate file extension, like "example.com?malicious_blob" will generate temporary file and always checked by safe browsing, but if we consider mime type, it probably can bypass safe browsing.

Another case is Chrome extension mime type, currently seems safe browsing will always check it, but if we use the mime type, the file extension will be crx and bypass safe browsing.

+SafeBrowsing

On the one hand, both the file extension in the URL and the Content-Type header are controlled by the server (who may be the adversary) so, in all likelihood, they can set either of those to a safe format as appropriate to try to bypass Safe Browsing checks.
On the other hand, I don't want this change of extension to become a hole in our protection.

The good news is that there is a safe middle ground: The safest change here would be to allow changing the file extension iff the original file extension (that is getting replaced) would have been considered safe by Safe Browsing [1].
In other words, if Safe Browsing would have classified the original extension to be safe, then there's no harm in losing that extension.

For instance, if ".jpg" will be renamed to ".webp", that's fine since ".jpg" was going to be safe too. This should cover the most common use-cases being described here without making it any riskier.

If, however, the file is being renamed from ".exe" to ".jpg", don't do the automatic renaming.

[1] API to check whether the file extension is safe: https://cs.chromium.org/chromium/src/chrome/common/safe_browsing/file_type_policies.cc?l=244&rcl=aaee335781975296a269a9324798e5a23b2cdc41

Thanks for the suggestion per #33, this is very helpful.