IssueTracker

Great! Thanks a lot, I'll look for the live updates soon!

I am not familiar with this particular API and what might have changed between API 34 and API 35. pbirk@, can you provide some guidance here?

Hi,

Thank you for the report.

The implementation was indeed changed in API version 35 in order to parse filename* directives from the Content-Disposition header.

As part of this change, the method also changed how it handles situations where there is a difference between the extension of the filename found in the Content-Disposition header string, and the extension suggested by the mimeType parameter. In previous versions of Android, the method would replace the extension, whereas in 35, it should append the extension suggested by the mimeType parameter.

It seems that there are actually 2 separate but overlapping bugs here:

1. We should not append an extension for application/octet-stream
2. We seem to be replacing rather than appending the replacement extension

You can solve the problem in the short term by passing null instead of "application/octet-stream" as the mimeType parameter. That will disable any suggestion of extension and use the filename from the header.

If all you want is to parse the Content-Disposition header and get a filename, then you can also use URLUtilCompat.getFilenameFromContentDisposition From the androidx.webkit library.

Hi,

I have looked further into this.

While there is a bug here, it has to do with the fact that the new behaviour is not enabled. I have filed a separate bug to address that problem.

The reason that you are actually seeing a change in API 35 is that a mime-type mapping for the .apkg extension was added, namely application/vnd.anki. This results in the function realising that the apkg extension doesn't match the mime type that you have provided, in which case it will prefer the mime type extension. So the function is working as documented here.

I suggest one of the following options to fix the issue:

• Use the correct mime-type for the file extension: application/vnd.anki.
• Use null for the mime type if you don't want the method to suggest an extension based on mime-type and always use the filename.
• Use URLUtilCompat.getFilenameFromContentDisposition From the androidx.webkit library to parse the Content-Disposition header value without trying to guess a filename from the URL or mime type.

We should not append an extension for application/octet-stream

The above problem stated in #5 is wide-reaching. Google apk downloaded as bin for example

• Servers aren't required to serve apk files with a URL containing the .apk extension
• apk should be application/vnd.android.package-archive, but since API 30, guessFileName rejects the .apk extension served with application/octet-stream and replaces it with .bin
• Many Android download managers are expecting guessFileName to make a reasonable guess using contentDisposition

From the URLUtil.guessFileName documentation:

File extension, if not defined, is added based on the mimetype. ... If the suggested file type extension doesn't match the passed mimeType, the method will append the appropriate extension instead of replacing the current extension.

The suggested file type extension does match application/octet-stream: it's a generic MIME type and should match all binary data. It doesn't just match .bin, and should act similarly to null.

The "octet-stream" subtype is used to indicate that a body contains arbitrary binary data. ... RFC 1341 also defined the use of a "NAME" parameter which gave a suggested file name to be used if the data were to be written to a file. This has been deprecated in anticipation of a separate Content-Disposition header field, to be defined in a subsequent RFC.

-- https://www.iana.org/assignments/media-types/application/octet-stream

Code for context:

https://cs.android.com/android/_/android/platform/frameworks/base/+/4d222959d96baa0366466d0910e0cd7e1f930191:core/java/android/webkit/URLUtil.java;l=420-431;bpv=1;bpt=0;drc=2f178d862bd8d8e17e4c9777ee4bd023c75aac4b

See also: MimeTypeMap.remapGenericMimeType, which does the right thing

https://cs.android.com/android/_/android/platform/frameworks/base/+/8edd837b790fcd098331a4972b38beb5e26f0135:core/java/android/webkit/MimeTypeMap.java;l=131

Thank you for feedback, reopening.

The MimeTypeMap.remapGenericMimeType is not part of the public Android API. That said, I accept your argument that we shouldn't do any remapping for application/octet-stream specifically.

Project: platform/frameworks/support
Branch: androidx-main
Author: Peter Birk Pakkenberg <pbirk@google.com>
Link:      https://android-review.googlesource.com/3419021

Change mimetype handling of guessFileName

Change mimetype handling of guessFileName 
 
If the derived file name already contains a filename, it is likely to be 
more correct than the MimeType suggested extension. 
 
Bug: 382864232 
Test: Updated URLUtilCompatTest 
RelNote: """Change behavior of `URLUtilCompat.guessFileName` to only use 
    the `mimeType` parameter to suggest an extension for filenames 
    derived from the URL parameter.""" 
Change-Id: I53ecd6d664efe5747a4451171617a2d33cfb59eb