Remove the 'sslbase' parameter




10 years ago
2 years ago


(Reporter: Frédéric Buclin, Unassigned)








10 years ago
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://.

Comment 1

10 years ago
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.

Comment 2

10 years ago
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).

Comment 4

10 years ago
(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 
> IIRC).

  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.

Comment 5

10 years ago
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.

Comment 6

10 years ago
See also bug 329638.

Comment 7

9 years ago
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.

Comment 8

9 years ago
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.

Comment 9

9 years ago
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, 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)

Comment 10

9 years ago
See also bug 114344 about access to single instance with multiple URLs


2 years ago
Assignee: administration → bugzilla
Keywords: relnote


2 years ago
Assignee: bugzilla → administration
You need to log in before you can comment on or make changes to this bug.