Support headers which may not be set

[snufkin]

On Acquia Cloud we use SSL termination on the LB layer, which adds a X-Forwarded-Proto, so an SSL enforcing rewrite rule would look like this [1]:

RewriteCond %{HTTPS} off
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Regardless of the protocol i use in the testing url, the RewriteCond for this header will never be met, so the above sample will always fail with the "This condition was not met." message.

I suspect this is because non-existing headers always trigger a fail, but for my use-case it would be really useful if it was supported.

[1] - https://docs.acquia.com/articles/redirecting-traffic-between-http-and-https-acquia-cloud

[andreascreten]

Thanks for your feedback.

We recently rebuilt our tester and somehow we lost the message that a certain test string is not supported. It should be back now.

It would be interesting to understand how you would like to see this option implemented. What do you think about a text field where you can type the value of %{HTTP:X-Forwarded-Proto}? Or do we need to make it smarter, for example allow you to choose between http and https?

[snufkin]

I think it would complicate things unnecessarily to limit the support to this header only. It would be quite cool to have a textarea into which I could put my header names and their values in a pre-defiend format, e.g. HTTP:X-forwarded-Proto http, separated by whitespace, or any special character really, which would not be present in the header.

This would give us a sufficient flexibility to define any header we want and prevent you from having to introduce unnecessary restrictions and tech debt.