I think this will have the same issues as the commit that was reverted. If Sprockets want to support both Rack 2 and 3 then it will need to be able to handle both Case-Sensitive and downcase only headers.

I think this will have the same issues as the commit that was reverted. If Sprockets want to support both Rack 2 and 3 then it will need to be able to handle both Case-Sensitive and downcase only headers.

Rack 2 has case insensitive headers so the downcase headers should be should still be valid. The issue that caused the regression was a bug in rack that was resolved by rack/rack#1919. We may wish to lock rack to >= 2.2.4 (which I have added)- but I think that may be overly restrictive as I think it was only a performance regression in test (and maybe dev) - but not production. Not sure if this (either changing the case of headers that may be accessed elsewhere, or the restriction of rack versions) could be considered a breaking change.

Rack 2 has case insensitive headers so the downcase headers should be should still be valid. The issue that caused the regression was a bug in rack that was resolved by rack/rack#1919

Rack fixed one instance of the issue, but as long as Sprockets claims compatability with Rack 2 it needs to work with any other library that supports Rack 2. I believe the casing of the headers needs to be dependent on the version of Rack, since we can't assume other libraries will have already updated.

but as long as Sprockets claims compatability with Rack 2 it needs to work with any other library that supports Rack 2

I do not think that this is correct. Any library using Rack 2 could make any assumptions about the case of the header that it likes - so maybe sprockets is already incompatible with existing Rack 2 middleware. I think it is reasonable it argue that this could be considered a breaking change and that we need to bump the major version of sprockets - so that app maintainers would know to check for any incompatibilities - but it should still be able to support both Rack 2 and 3 using the lower case headers.

The decision to bump the major version is something that I will leave to the maintainers of the project and I will not presume what they would consider a breaking change.

Yeah, this patch is fine since sprockets will require the version of rack to the update to 2.2.4 which allow headers to be head with both cases.

Thanks everyone!

There's a user reported issue on Rack 2.2.6 that seems related to this, could someone take a look? rails/rails#47096