Middleware to handle vendor forwarded proto

[tomharvey]

@mpalmer sorry to raise this separately and lose your already valuable feedback, but I'd like to own the code that I've contributed.

This is to solve the issue raised in rack/rack#2080

When routing from cloudfront -> ALB -> puma (on ECS) we want to use the existing cloudfront header to inform rack of the protocol in use.

But, we also want to keep this implementation vendor agnostic.

More context can be seen in the feedback leading to this code in rack/rack#2089

Is it best to squash my commits before any merge?

And, I assume I should add to the README?

[tomharvey]

@mpalmer i think this is a great suggestion to further broaden the functionality. I’ll work on that this evening. And the resulting name change.

A generic Foo-Forwarded-* -> Forwarded transmogrifier would probably be the platonic ideal -- I just didn't want to let the enemy be the perfect of the "well, I guess it's better than nothing" 😀 . I can't find any existing support for (eg) CloudFront-Viewer-Address anywhere in Rack, so presumably most people in this situation would want that header translated as well, at the very least.

[tomharvey]

@mpalmer I've reworked this so it can be used to handle the transformation of any header name. And, so it can be used multiple times.

Is this in line with your suggestion?

I've also tried to rename it given all those changes.

The tests still include X-Forwarded-Proto specific cases, but also the more generic ones.

[tomharvey]

@ioquatix would love that review when you've got time.

[mpalmer]

Lookin' good, I've just got a few observations and typos that need fixing.

[mpalmer]

It's probably worth describing how existing values in the "target" header will be impacted, since HTTP headers are multi-valued.

[tomharvey]

Unless I misunderstand RFC 2616 the multiple values would come into this stage of middleware as {'Whatever-You-Want': "value1, value2"}.

I've also seen https://github.com/rack/rack/blob/ed25abcde2a64a937efa1e59f1a0bb53d7ccecb8/test/spec_files.rb#L213C10-L213C20 where the multiple values are being passed into HTTP_RANGE.

Is this the kind of multi-value you're talking about?

[tomharvey]

If so, the change in the "Foo" header to contain "foo, bar" as the value should cover things.

[mpalmer]

Sorry, I wasn't clear that I was referring to the situation where (for whatever reason) there was already a value in (per the example) Whatever-You-Want. The current code overwrites the existing value, and that's a reasonable behaviour, but it's worth clearly stating that in the docs, and having the tests ensure no regressions in that behaviour.

[mpalmer]

Apologies for the delay in re-review. I've commented in the main issue to clarify what I meant on that previous review comment.