Bug #10789: X-forwarded-Proto required when using Reverse Proxy

• Status: Closed
• Assignee: -
• Target version: -
• ruby -v: ruby 2.0.0p353 (2013-11-22) [x86_64-linux]
• Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN, 2.2: UNKNOWN

[jbalcorn (Justin Alcorn)]

The Webrick library httpserver.rb makes use of the X-Forwarded-* HTTP headers when building link references for 307 responses. It also requires X-Forwarded-Proto, but this header is not added by default in Apache 2.2 mod_proxy (and possibly others). It defaults to port 80, which can result in 307 responses that redirect to URIs such as

https://host.example.com:80/url

in httprequest.rb:

@forwarded_port = (tmp || (@forwarded_proto == "https" ? 443 : 80)).to_i

ruby 2.0.0p353 (2013-11-22) [x86_64-linux] on Red Hat Enterprise Linux Server release 6.6 (Santiago)

Workaround is to put

RequestHeader set X-Forwarded-Proto "https"

int the Apache conf, but Webrick should Do The Right Thing (tm) Since the header is not present by default.

[jeremyevans0 (Jeremy Evans)]

• Status changed from Open to Feedback

I don't think this is a bug. If Apache doesn't pass the X-Forwarded-Proto header, and the X-Forwarded-Host header doesn't include the port, then how would Webrick know that the request was originally submitted via https? I'm not sure how Webrick would generate the https://host.example.com:80/url redirect if X-Forwarded-Proto was not submitted, as it should use http://host.example.com:80/url in that case.

What do you propose by "Do the Right Thing (tm)", and how do you propose to implement it?

[jeremyevans0 (Jeremy Evans)]

• Status changed from Feedback to Closed