FileMiddleware will provide correct mime type for non lowercase file extensions

[mredig]

I added a test for FileMiddleware to test handling file extensions that aren't homogeneous lowercase and it failed.

I then updated FileMiddlware to normalize as lowercase the file extensions it extracts from filenames (to match the existing convention on MediaType) prior to passing them to MediaType.getMediaType(forExtension:).

The test passes now.

[mredig]

Is it worth adding a custom ExpressibleByDictionaryLiteral type for this dictionary use case? That way we can represent it in, what I believe, would be a clearer API surface. ref

I have the beginnings of this specific idea right here:

extension MediaType {
    public struct WellknownExtensions: RawRepresentable, Sendable, ExpressibleByDictionaryLiteral {
        public private(set) var rawValue: [FileExtension: MediaType]

        public init(rawValue: [MediaType.FileExtension : MediaType]) {
            self.rawValue = rawValue
        }

        public init(dictionaryLiteral elements: (FileExtension, MediaType)...) {
            self.init(rawValue: elements.reduce(into: .init(), {
                $0[$1.0] = $1.1
            }))
        }
    }
}

but it occurred to me that between the changes I already made by adding FileExtension and making it case-insensitive equatable, ExpressibleByStringLiteral and then naturally being able to use the existing interface with a dictionary literal argument, I can't think of any value this would bring.

I personally think that using a type safe wrapper for file extensions is also a cleaner interface for case insensitive comparison rather than something like WellknownExtensions.compare("jpg", "JPG")

Should I continue forward with this, or do you agree what I already have is better?

[mredig]

Re - the api breaking changes...

I wasn't aware that the last PR had been released yet, so I wasn't concerning myself with thinking about that, but I can make sure there are String args complementing the FileExtension ones, if we want to proceed with this.

[adam-fowler]

@mredig ah that was my bad.

[mredig]

I am considering this currently as unapproved since I made significant changes since the approval, however unless you guys see any shortcomings, I am considering it complete and ready for real PR approval.

I just want to make sure that there's not a limbo of me waiting for you while you are waiting for something from me :)

[mredig]

(the test failures are from certificates that expired hours prior to the tests running - in the Tests/HummingbirdHTTP2Tests/Certificates.swift file.)

[adam-fowler]

Couple of minor things, but in general looks good. I'm not sure it is necessary to include all the extensions as static members of MediaType.FileExtension but I'm not opposed either.

Note #665 includes updated certificates, so tests should work once that is merged

[adam-fowler]

thanks Michael