System.IO.Packaging should perform case-insensitive matching when determining part media types

[impact-merlinzerbe]

Description

I am trying to use System.IO.Packaging with a package that uses lowercase part names but all caps names for content type overrides.

This is my package:

.
├── [Content_Types].xml
└── part

The file part is an empty file.

This is the content of [Content_Types].xml:

<?xml version="1.0" encoding="UTF-8"?>
<Types xmlns="http://schemas.openxmlformats.org/package/2006/content-types">
    <Override PartName="/PART" ContentType="text/plain"></Override>
</Types>

I use the following C# program to access the part:

using System;
using System.IO;
using System.IO.Packaging;

string zipFilePath = "minimal.zip";

var package = Package.Open(zipFilePath, FileMode.Open, FileAccess.Read);
package.GetPart(new Uri("/part", UriKind.Relative));

Running this program throws the following exception:

$ dotnet run
Unhandled exception. System.InvalidOperationException: Specified part does not exist in the package.
   at System.IO.Packaging.Package.GetPart(Uri partUri)
   at Program.<Main>$(String[] args) in /Program.cs:line 8

The Zip package tries to determine the content type here:

runtime/src/libraries/System.IO.Packaging/src/System/IO/Packaging/ZipPackage.cs

Line 217 in 9e94b77

ContentType? contentType = _contentTypeHelper.GetContentType(validatedPartUri);

The ContentTypeHelper looks up the content type here:

runtime/src/libraries/System.IO.Packaging/src/System/IO/Packaging/ZipPackage.cs

Lines 848 to 868 in 9e94b77

	internal ContentType? GetContentType(PackUriHelper.ValidatedPartUri partUri)
	{
	//Step 1: Check if there is an override entry present corresponding to the
	//partUri provided. Override takes precedence over the default entries
	if (_overrideDictionary != null)
	{
	if (_overrideDictionary.TryGetValue(partUri, out ContentType? val))
	return val;
	}
	//Step 2: Check if there is a default entry corresponding to the
	//extension of the partUri provided.
	string extension = partUri.PartUriExtension;
	if (_defaultDictionary.TryGetValue(extension, out ContentType? value))
	return value;
	//Step 3: If we did not find an entry in the override and the default
	//dictionaries, this is an error condition
	return null;
	}

The lookup does not find a match because the part name "/part" and the content type override for "/PART" do not match.

However, the spec states that "The comparison shall be ASCII case-insensitive matching" (ECMA-376, 5th Edition 7.2.3.5).

Reproduction Steps

1. Create a new console project:

   dotnet new console -n demo
   

2. Overwrite Program.cs with the C# program above.

3. Create a zip file called minimal.zip with an empty file called part and a file [Content_Types].xml with the xml content above.

4. Run the program: dotnet run

Expected behavior

The program should finish without errors.

Actual behavior

$ dotnet run
Unhandled exception. System.InvalidOperationException: Specified part does not exist in the package.
   at System.IO.Packaging.Package.GetPart(Uri partUri)
   at Program.<Main>$(String[] args) in /Program.cs:line 8

Regression?

No response

Known Workarounds

No response

Configuration

.NET version: 9.0.103
OS: Linux 6.13.3
Architecture: x64

Other information

No response

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-io-compression
See info in area-owners.md if you want to be subscribed.

[ericstj]

I was able to reproduce. Here's an isolated repro: partName.zip

As shown in the repro -- it does not reproduce on .NETFramework.

It seems this is due to a difference in behavior of Uri.GetHashCode.

On .NETFramework, Uri.GetHashCode will return the same for Uri's only differing in case:
https://sharplab.io/#v2:EYLgHgbALANALiATgVwHYwCYgNQB8ACATAAwCwAUEQIwUX5UCcAFKgKYDuABAKqICWTAEQB6AA4BDRHEEwe/ANJ9UGAHQAlVgBtxcPgDdWAShUBxVnAAS4gM4ALAMIB7DKyaHDAbjqMWHOQJEABQBBNQAVGX9FZXUtHX0jU3MrOycXN08KIA

This is not true on .NET 9
https://sharplab.io/#v2:EYLgxg9gTgpgtADwGwBYA0AXEUCuA7NAExAGoAfAAQCYAGAWAChqBGRxi5gTgAo8YB3AAQBVKAEtuAIgD0ABwCGUDJLQjxAaTF5CAOgBKMADbyMYgG4wAlDoDiMDAAl5AZwAWAYQiEY3S5YDc7Fy8AmoSMgAKAIJ6ACoqYZra+kYm5la29k5unt6+AYxAA==

Here's the Uri codepath on .NETFramework:
https://referencesource.microsoft.com/#System/net/System/URI.cs,1631

And here's the change that broke this in .NET 5 #32713 @MihaZupan

Indeed I can go back to .NETCore 3.1 and it does not reproduce this error.

The System.IO.Packaging.PackUriHelper.ValidatedPartUri was relying on this, because it didn't override GetHashCode and only implemented IEquatable.

[MihaZupan]

Interesting. In general a derived type that has a more relaxed notion of equality must override GetHashCode, we should fix that in PackUriHelper.

It's unfortunate that this type is suppressing CA1067, not sure I understand the intention behind that.

runtime/src/libraries/System.IO.Packaging/src/System/IO/Packaging/PackUriHelper.cs

Lines 634 to 636 in 1eadeff

	#pragma warning disable CA1067 // Override Equals because it implements IEquatable<T>; not overriding to avoid possible regressions in code that's working
	internal sealed class ValidatedPartUri : Uri, IComparable<ValidatedPartUri>, IEquatable<ValidatedPartUri>
	#pragma warning restore CA1067

That suggestion would get you to override Equals(object), which would then get you to override GetHashCode.

[ericstj]

Yeah, pretty sure this code is just doing that because it's what was done in desktop where it was ported from https://referencesource.microsoft.com/#WindowsBase/Base/System/IO/Packaging/PackUriHelper.cs,1046
We've avoided churning this much.

I agree with @stephentoub when enabling CA1067 to avoid regressions from behavior changes. It could be intentional that this internal type only wanted to control comparison behavior and not actual equality. We aren't the original authors (WPF was).

Also agree that the right thing to do would be to fix this type, and validate we won't break anything when doing so by auditing every place it exposes this actual object or may rely on it's equality. Could be better to just provide a comparer to the dictionary.