I'm not able to reproduce this. Looking at the code, we save the URL provided directly without modification, and we redirect to it directly when clicking Get Support without modification.
If you type the http:// version of your URL directly in the browser, does it try to redirect?

• Status:

  -	New
  +	NeedInfo

The Custom Support URL I'm trying to use works fine when typed straight into a browser. It is hosted on a separate server.
I dug into it a bit deeeper, and it seems the http->https issue is due to the fact that I run Review Board (from the Bitnami package) behind an NGINX reverse-proxy. If I run curl on the backend: curl -I -k http://localhost:11000/reviewboard/support/ it returns a 302 FOUND with the correct Custom Support URL I configured. But a similar command against the reverse proxy URL returns a 302 FOUND including the https scheme.
Although my NGINX is configured to 301-redirect http requests to https, since my custom support url is a on separate server not behind the reverse proxy, I didn't think it would be affected and assumed it was a ReviewBoard bug. Apparently NGINX is rewriting the 302 redirect that ReviewBoard returned. So it's not your fault and something I can fix in my NGINX configuration.
That said, if you made your Get Support option a plain 'ole link to the url I configured rather than a redirect, it would have avoided this problem completely.

It would have avoided the problem, but there's a couple of reasons we have it set up this way.
In a default setup, we redirect to our own support page, intended for use as a decent default for support. That page is keyed off of a couple of things, factoring in whether there's a support contract, and sending some data that helps us diagnose things when tickets are filed. Instead of computing that information (some of which requires DB lookups) on every page view, we do it as-needed, when the redirect URL is hit.
It's then much easier to just keep all links to the support page consistent, instead of having to look up whether to use the redirect URL or use a custom URL. There's no risk of future links missing one condition or another. It also leaves room for some future improvements we might want to make.
The final thing is that some pages are cached in the browser. For instance, the review request page. We have to include dynamic information when computing the ETags for any cacheable pages. Since the support URL can be changed (and is dynamic in the case of the default page, which is the 99% case), using the redirect is ultimately better than factoring that into cache information.

Thanks for the in-depth explanation! You have a very solid justification for why you use a redirect, including some reasons I hadn't considered. Keep things just the way you have it; I'll fix my NGINX config (I'm guessing a proxy_redirect directive is the cause). Consider this ticket closed; no change needed. Sorry for taking up your time.

Please don't be sorry :) Knowing the use case and the problem you hit is very valuable. Would you mind updating the ticket with the change you end up making (maybe a before/after)? That'll allow us to record this internally (working on some KB and support info content) in case others have the same problem.

Here's a pared-down sample nginx.conf showing my solution to several problems I encountered with reverse-proxying Review Board when NGINX is used to add https encryption. You are welcome to modify/distribute it. Ideally the Review Board code could be fixed so only the proxy_pass command and some headers are needed. If the need for the first proxy_redirect were eliminated, then the nested location block would not be needed either. Review Board (or the Apache config? I'm not sure since I use Bitnami's installer) ought to read the X-Forwarded-Proto header or similar to determine which scheme to use for its application URL redirects. I'm no expert on the right way to do this exactly, but some other apps I reverse-proxied (eg: Trac) did not require a proxy_redirect.
http {

  # logging and SSL settings not shown...
# Redirect http requests to https.

  server {

    listen 80;

    server_name example.com;

    return 301 https://example.com$request_uri;

  }
server {

    listen 443 ssl;

    server_name example.com;
# Some of these headers are probably only needed by other apps.
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Ssl on;
proxy_pass_header Server;

location /reviewboard {
  proxy_pass http://127.0.0.1:11000;

  # This is needed to keep the original scheme that the user requested (https), by rewriting redirect URLs.
  # Otherwise, when Review Board sends a redirect such as to add a slash at the end of a URL, it will send us from https to http.
  # eg: https://example.com/reviewboard/dashboard does a 302 redirect to http://example.com/reviewboard/dashboard/
  proxy_redirect http:// $scheme://;

  # Rewrite the path of the csrftoken cookie from / to /reviewboard/ and add the Secure and HttpOnly settings.
  proxy_cookie_path ~^/$ "/reviewboard/;Secure;HttpOnly";

  # Rewrite the rbsessionid cookie with the same path, but add the Secure setting. HttpOnly setting is already set correctly.
  proxy_cookie_path ~^/reviewboard/$ "/reviewboard/;Secure";

  # This block is the solution I came up with for the issue experienced in ticket #4475.
  # Don't rewrite http to https for the redirect to the Custom Support URL ('Support > Get Support' link).
  location /reviewboard/support/ {
    proxy_pass http://127.0.0.1:11000; # Must duplicate same as above because proxy_pass command is not inherited.
    proxy_redirect off;  # Revert to the default of not rewriting redirects.
  }
}

}

}