staticweb drop SSL when redirecting if behind SSL-offload LB
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Object Storage (swift) |
Confirmed
|
Medium
|
Unassigned |
Bug Description
When redirecting, if behind a load balancer doing SSL offload, staticweb does not maintain the https for the new location.
haproxy listening to 80 and 443 on SAIO:
frontend swift
bind 127.0.0.1:80
use_backend swift
frontend swift_ssl
bind 127.0.0.1:443 ssl crt /etc/haproxy/
use_backend swift
backend swift
server swift-proxy 127.0.0.1:8080
web is a container with staticweb enabled.
Good:
$ curl -I http://
HTTP/1.1 301 Moved Permanently
Content-Type: text/html; charset=UTF-8
Location: http://
Bad (Location header is http instead of https):
$ curl -kI https:/
HTTP/1.1 301 Moved Permanently
Content-Type: text/html; charset=UTF-8
Location: http://
Setting url_base does not fix the issue, it just invert it.
With url_base = https:
Good:
$ curl -kI https:/
HTTP/1.1 301 Moved Permanently
Content-Type: text/html; charset=UTF-8
Location: https:/
Bad (should be http in Location header):
$ curl -I http://
HTTP/1.1 301 Moved Permanently
Content-Type: text/html; charset=UTF-8
Location: https:/
Staticweb must use by default the protocol of the incoming request. Only if specified by operator, the protocol should be overwritten. To detect the protocol of the incoming request, the standard way is to use the Forwarded header. Support for the "de-facto" standard X-Forwarded-Proto would be nice too.
See:
https:/
https:/
description: | updated |
Yup; despite several patches [1][2][3] related to this general problem, we still haven't gotten it right. Part of the trouble is that we're trying to accommodate both protocol-aware terminators (which would add the Forward/ X-Forwarded- Proto headers) as well as protocol-agnostic ones (which can't). And we *certainly* haven't been thinking about this problem from a bi-modal-access perspective.
I wonder whether we should
- get static web out of scheme/host manipulation entirely,
- have swob *always* look at Forwarded, and
- have some middleware (maybe even gatekeeper?) populate Forwarded when it isn't present, based on a config-driven override (if set) and falling back to the current guesswork...
[1] https:/ /github. com/openstack/ swift/commit/ 188f834e0ae305d f36438c9a9ad1e2 a4b6e98098 /github. com/openstack/ swift/commit/ 47ee1d7e1754714 83b9885eafc4514 a7281c35e9 /github. com/openstack/ swift/commit/ f62df7b80c08386 2c11cbef678f75c c09bb89e8f
[2] https:/
[3] https:/