I haven't been in the various specs for several weeks. See https://www.rfc-editor.org/rfc/rfc9110.html#name-content-length. The spec also refers to Transfer-Encoding, etc.

The Rack spec specifies that header field names/keys should be lower case, but that isn't referring to the HTTP syntax, it's referring to what the app returns.

Also, most browsers' 'dev tools' show capitalized header field names...

Right, my understanding is either casing is valid in HTTP/1.1 spec, and the Rack spec doesn't actually say anything about how the server should respond.

However, I believe the current behavior is confusing (at least for me, and the user that opened an issue on Rails) because only certain headers have their casing changed. With a Rack 2 version of the App in config.ru above, both headers will be mixed case in the app and the Puma response will have all mixed case headers. With the Rack 3 version, all headers in the app will be downcased, but only some of the headers in the Puma response will be downcased.

This confusion seems especially important as apps will be migrating to Rack 3 and trying to determine whether all of their libraries/middleware are behaving as expected. While using Rack::Lint is probably the best way for them to know for sure, I predict libraries will see issues raised because users will be looking at the actual response and seeing unexpected casing.

Also, most browsers' 'dev tools' show capitalized header field names...

Firefox shows me the exact casing, but I do recognize I'm not part of the Chrome majority.

This can't happen to that many headers, right? Only those Puma are responsible for. I think we can see all of them in https://github.com/puma/puma/blob/7a1237b4215e86020ed8cb3080c2958d850877c7/lib/puma/const.rb

I get the point you're making... but wouldn't it be equally confusing if you started to see lowercase headers mixed in when you still on Rack 2 but a newer Puma? (If this was adjusted) (at least for some time, until the whole world is on Rack 3)

Is it a breaking change for Puma to change to downcased headers?

It is possible to make it user configurable?

Investigation's welcomed.

Puma's contract is to produce legal, valid HTTP responses. Since header field names are case insensitive, it isn't a breaking change for us to do anything regarding the casing of a header field name.

Because this is cosmetic (or, at least, a dev UX issue) and not an issue with Puma doing the right/wrong thing, I don't want to introduce new configs here.

So should we change all headers to lowercase or do nothing in Puma?

While working on the test framework, some of the work involved removing the use of net/http. Its header API converts all header keys to lowercase.

So, the API has one method that returns the response headers as an array of lines (unconverted), and another method that returns the headers as a hash, with keys converted to lowercase.

Messy subject. I checked dev tools with Chrome, Edge, & FireFox, and I recall that all had capitalized header keys.

Or, not sure what to do...

So should we change all headers to lowercase or do nothing in Puma?

I think yes, we should use lowercase.

From rack/rack#1592

HTTP/2 makes it clear that headers should be lower-case (https://datatracker.ietf.org/doc/html/rfc7540#section-8.1.2):

Just as in HTTP/1.x, header field names are strings of ASCII characters that are compared
in a case-insensitive fashion. However, header field names MUST be converted to lowercase
prior to their encoding in HTTP/2. A request or response containing uppercase header field
names MUST be treated as malformed (Section 8.1.2.6).

If think we should change them all to lower case. But, doing so may break any CI looking at header fields. So, it should either be a minor or a major version change.

Also, see https://httpwg.org/specs/rfc9113.html#HttpHeaders

If we go lowercase, these should change too

. But, doing so may break any CI looking at header fields.

That's their problem IMO. Both are valid HTTP 1.1. If you're relying on Puma to return specific casing in a header, you're relying on behavior we never specified.

Action item here: Puma should return lowercase headers fields in all circumstances.

If we go lowercase, these should change too

(unrelated to this issue which is more about puma -> client header casing)

Those should definitely be downcased for Rack 3 compliance since UrlMap is in the Rack layer. The current casing would be incompatible if any Rack 3 middleware were to be above it in the stack.

I was working on this and updated headers in const.rb and urlmap.rb.

I have a doubt regarding CI pipelines. For example, in this line, it only sends a request. Should this also be changed to lowercase, or do I just need to update the response with corrected case.

In most test cases, Content-Type is used in uppercase when a request is sent. Since Rack::Lint does not allow uppercase headers, should this Content-Type be updated to lowercase?

I don't think we need to update our tests. That's not the change we're talking about here.

(We could change the tests too, for consistency, but it should be done in a separate PR for easier review)

I don't think we need to update our tests. That's not the change we're talking about here.

Ok, consistency of test cases part can be covered in separate issue.

But when we update the headers in puma to be returned always in lowercase(in const.rb file) . we need to update our tests as well. otherwise pipelines will fail.

Sure, such changes we need to do

(Apparently gotta be careful how you reference public issues from private repos when you're maintainer)