I reviewed some Rails implementation details and found they worked around the issue, but that it's pretty ugly:

https://github.com/rails/rails/blob/f95c0b7e96eb36bc3efc0c5beffbb9e84ea664e4/actionpack/lib/action_dispatch/http/headers.rb#L68-L71

which uses:

https://github.com/rails/rails/blob/f95c0b7e96eb36bc3efc0c5beffbb9e84ea664e4/actionpack/lib/action_dispatch/http/headers.rb#L121-L129

It makes sense to me and I think we should do it. Adopting h2 headers seems like the best path forward.

I personally like option 2. I like the idea of having the request object deal with the different env shapes for the user, but one thing that bothers me about that solution (and I believe is a problem with Rack in general) is that every middleware is then required to "cast" the env hash to a request object, then "cast" it back to a hash when it passes it on to the next middleware.

It would be really great if we could just pass a request object all the way down the stack, then each middleware doesn't need to cast. If we're going to dream big, maybe we should make the request object quack enough like a hash that it works for legacy middleware, but newer middleware can take advantage of the request object itself. I will open an issue for this with more detailed thoughts. But yes, I think this ticket is a good idea.

I'm against this and don't think the minor benefits are worth the backwards compatibility cost. Completely breaking backwards compatibility at this stage in rack's lifecycle makes is a very bad trade off, IMO. That goes for both h2 style env as well as replacing env with a request object.

If I had to choose between the two, I think it makes more sense to replace env with a request object as opposed to h2 style env, as they have the same backwards compatibility cost, but the benefits of a request object are larger. So if the eventual goal is a request object, then we should skip h2 style env and jump straight to that.

I've made a PR to try and address the first part of this, Rack::Request#*_headers are an interface for dealing with actual HTTP header names: #1880

On detailed review of the Rails code base, I noted some frustration here: https://github.com/rails/rails/blob/f95c0b7e96eb36bc3efc0c5beffbb9e84ea664e4/actionpack/lib/action_dispatch/http/headers.rb#L5-L23.

As discussed in the previous issue, #1841 (comment) and #1841 (comment) both reflected on this pain point and expressed a desire to have access to the underlying headers cc @ianks @nateberkopec

@jeremyevans is concerned about compatibility but I think we need to establish that their is a fair middle ground for evolution of Rack given that the contributors in these discussions practically speaking probably represent over 90% of all current real-world usage of Rack. Not all forward progress is going to be backward compatible and there is a desire for forward progress. In these cases, the best we can hope for, IMHO, is feature flags, middleware wrappers, etc.

I'm not personally interested in rolling this change into Rack 3.0 - I think later in the 3.x life or maybe even 4.x makes sense. That being said, I'd like to get a consensus on what this looks like going forward.

Unfortunately the current design leads people into code like this:

    # Returns the authorization header regardless of whether it was specified directly or through one of the
    # proxy alternatives.
    def authorization
      get_header("HTTP_AUTHORIZATION")   ||
      get_header("X-HTTP_AUTHORIZATION") ||
      get_header("X_HTTP_AUTHORIZATION") ||
      get_header("REDIRECT_X_HTTP_AUTHORIZATION")
    end

I'm still strongly against this proposal due to the backwards compatibility issues.

Okay, for now, let's close it and focus our energy on #1879