setCharset function does not preserve case of original Content-Type

[xzyingxiashubro]

Environment information

Version: express 5.0.0-beta.3

Platform: Linux

Node.js version: 18.x

Any other relevant information: N/A

What steps will reproduce the bug?

1. Import the utils module from Express
2. Call the setCharset function with an uppercase Content-Type and a charset
3. Observe that the returned string converts the Content-Type to lowercase

const utils = require('express/lib/utils');

// Call setCharset with uppercase Content-Type
const contentType = 'TEXT/PLAIN';
const charset = 'UTF-8';
const result = utils.setCharset(contentType, charset);

console.log(result); 
// Actual: 'text/plain; charset=UTF-8'
// Expected: 'TEXT/PLAIN; charset=UTF-8'

What is the expected behavior?

The function should preserve the original case of the Content-Type while adding the charset parameter. For example, when TEXT/PLAIN is provided as input, the output should be TEXT/PLAIN; charset=UTF-8.

What happens instead?

The function converts the Content-Type to lowercase, so TEXT/PLAIN becomes text/plain; charset=UTF-8 in the output.

Source of the issue

The issue is in the setCharset function in lib/utils.js.
The function uses contentType.parse() which normalizes the type to lowercase, and then contentType.format() which outputs the type in lowercase, resulting in the loss of the original case information.

[SantiagoCecena]

Hi @xzyingxiashubro,

You're right that Content-Type headers are often converted to lowercase. This behavior is generally considered a good practice for several reasons:

---

Why lowercase is common and preferred

• HTTP/2 Requirement: In HTTP/2, header field names must be converted to lowercase before transmission. While HTTP/1.1 headers are case-insensitive, HTTP/2 explicitly mandates lowercase for consistency and efficient header compression (HPACK).
• Interoperability: Although HTTP/1.1 specifies headers as case-insensitive, many tools, proxies, and servers normalize them to lowercase internally. Using lowercase helps ensure broader compatibility and avoids potential (though non-compliant) edge cases with some older or less robust implementations.
• Consistency: Normalizing to lowercase provides a consistent way to handle and access headers programmatically within an application.

---

So, while Content-Type and content-type are functionally the same in HTTP/1.1, the conversion to lowercase is usually a deliberate choice to align with modern best practices and HTTP/2 requirements.

I hope this clarifies why you're seeing that change!