Problem/Motivation

If a file extension is made up of several parts, concatenated by a dot, and the rightmost part has a MIME type mapped, ExtensionMimeTypeGuesser::guessMimeType() returns the MIME type of the rightmost part and not the more accurate MIME type of the full extension.

Steps to reproduce

1) Alter the MIME type map to have the 'z' extension map to the application/x-compress MIME type
2) Guess a file named 'foo.pcf.z'. You would expect the MIME type returned to be application/x-font, because 'pcf.z' extension maps to that MIME type. application/x-compress is returned instead, because 'z' extension maps to application/x-compress now, and the rightmost part is attempted first.

Proposed resolution

Change the logic to test from attempting extensions from the full one and looping by removing the leftmost part until a match is found.

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Issue fork drupal-3477346

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

mondrake created an issue. See original summary.

mondrake’s picture

Issue summary: View changes
mondrake’s picture

Title: ExtensionMimeTypeGuesser::guessMimeType return less accurate MIME type when file extensions have multiple parts » ExtensionMimeTypeGuesser::guessMimeType returns less accurate MIME type when file extensions have multiple parts
Status: Active » Needs review
smustgrave’s picture

Status: Needs review » Reviewed & tested by the community
Issue tags: +Needs Review Queue Initiative

Ran test-only feature

1) Drupal\KernelTests\Core\File\MimeTypeTest::testFileMimeTypeDetection
Failed asserting that two strings are identical.
--- Expected
+++ Actual
@@ @@
-'application/x-font'
+'application/x-compress'
/builds/issue/drupal-3477346/core/tests/Drupal/KernelTests/Core/File/MimeTypeTest.php:53

Issue summary appears complete and change makes sense to me

Don't see anything else holding it up.

larowlan’s picture

Status: Reviewed & tested by the community » Needs work

One minor comment about a slight loss of coverage. Fine to self RTBC

mondrake’s picture

Status: Needs work » Reviewed & tested by the community

Self-RTBC as granted in #6.

larowlan’s picture

Version: 11.x-dev » 10.3.x-dev
Status: Reviewed & tested by the community » Fixed

Committed a5b0f9c and pushed to 11.x. Thanks!

As this is a bug and there is little risk of disruption, backported to 11.0.x, 10.4.x and 10.3.x

Thanks!

  • larowlan committed c00a518e on 10.3.x
    Issue #3477346 by mondrake, smustgrave, larowlan:...

  • larowlan committed 659b8eae on 10.4.x
    Issue #3477346 by mondrake, smustgrave, larowlan:...

  • larowlan committed 99f96526 on 11.0.x
    Issue #3477346 by mondrake, smustgrave, larowlan:...

  • larowlan committed a5b0f9cc on 11.x
    Issue #3477346 by mondrake, smustgrave, larowlan:...

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

et.cetera’s picture

StatusFileSize
new851 bytes

This change introduced an issue if you have filenames which are equal to 0 (i.e. 0.jpg), because the while condition does not apply:

while (array_shift($file_parts)) {

I appended a patch for core version 10.3.10 to adjust this condition and fix the issue in my case.