Per our discussions at our last 2 Bugzilla meetings, this param should go away. It should be based on 'urlbase' but prepending https:// instead of http://.
Disagree. At this time we are using Bugzilla via two different addresses - one http://intranet and another https://internet.
Will agree if Bugzilla will have an option to work by relative paths and will not try to create pages which links to exact protocol/server name.
I agree, this system is flawed in at least two ways:
A) It doesn't work for installations on no standard ports: bug #358588
B) Prepending the urlbase or sslbase breaks tunnelled connections.
I don't see why there's any need to prepend any base whatsoever, the system should be concerned about this and simply use relative addressing.
Tunneled connections are already broken in the current versions of Bugzilla unless you drop your hostname into your hosts file or something. The login form submits to a URL with the urlbase prepended if I recall correctly (to combat some problem we had with a cross-site form submission IIRC).
(In reply to comment #3)
> The login form submits to a URL with the urlbase prepended if I recall
> correctly (to combat some problem we had with a cross-site form submission
Yes, but I'm pretty sure that was not a good solution, as it's caused us FAR more trouble than it's solved. I suspect there's another much better solution.
For all other commenters: The real purpose of sslbase and urlbase isn't to create absolute URLs in Bugzilla's interface. The most important purpose is for use in emails.
Having both urlbase and sslbase isn't a good solution anyway. I think sslbase was only introduced to let you have a secure connection when you are logged in while at the same time let anonymous connections use the unsecure protocol, in case they don't support SSL. If we allow any URL to a given Bugzilla installation, which one should be used in emails? And what do we do with your cookies everytime you use another URL? Here too this is confusing as your UI (e.g. columns to display in buglists) may depend on your cookies being used.
See also bug 329638.
Now thinking about this a bit more, does it still make sense to keep the sslbase and ssl parameters? Why not removing them and have a single urlbase parameter, which can be either a http:// or a https:// URL?
I explained in comment 5 why we have both parameters, but I suppose cases where SSL is not supported in 2009 are very rare.
I think we should just have one parameter, yeah. If people want to hack things up for different ports, we could either add a parameter for ssl_port later, or they can just hack things (or just use ssl: always) which shouldn't be too hard if we centralize the urlbase logic as much as possible.
Bugzillas may (and did in past, see bug 329638 comment 4) have several valid HTTP addresses. Cookies are no problem until every user uses single address to access Bugzilla.
I suspect we may continue to use 'urlbase' everywhere, but no longer as a constant, but calculate it per query, based on:
1. URL used to access Bugzilla (from CGI.pm, shouldn't be a problem in HTTP 1.1 world). If user already came using this address -- it works for him, and we need not to think why :-)
2. 'ssl' parameter: 'never' means left as is, others may cause rewrite to https (but not back to http).
For emails we don't have CGI data, and still need two params -- or single Param('urlbase') and rewrite (bug 329638 comment 9)
See also bug 114344 about access to single instance with multiple URLs