On base_url case...
Emmanuel Blot
I was wondering whether we could improve the base_url option in trac.ini.
It has becomed a (almost?) mandatory setting, but trac-admin never
sets it and trac never reports an error (not even a warning in the log
message) when it is not defined.
When this parameter is not defined, some weird issues can occur and it
can be tricky to find that the root cause comes from a missing or
invalid base_url value.
I'm not sure to understand *when* this setting is actually needed, or
as another way to say it, on which kind of environments it is
mandatory or optional.
I'm not sure to understand how it is related to other similar settings
such as the TracUriRoot option in mod_python configuration.
Anyway, would it make sense to add some sanity checks to validate that
at least one option that defines the base URL is set; the best option
would be to have a single option to define the base URL, whichever the
way Trac is run (tracd, mod_python, CGI, etc.).
As a subsidiary question, what is the best way to retrieve the base
URL in a plugin (in Trac 0.11)?
Thanks,
Manu
Christian Aust
Am 03.03.2007 um 16:04 schrieb Emmanuel Blot:
> Anyway, would it make sense to add some sanity checks to validate that
> at least one option that defines the base URL is set; the best option
> would be to have a single option to define the base URL, whichever the
> way Trac is run (tracd, mod_python, CGI, etc.).
True. I've had some issues regarding my GoogleSitemapPlugin and the
use of different base urls, i.e. when people accessed the admin part
of trac using https (but other pages are accessible without SSL) or
when trac was accessed via a reverse proxy.
http://trac-hacks.org/ticket/917
http://trac-hacks.org/ticket/919
http://trac-hacks.org/ticket/1009
> As a subsidiary question, what is the best way to retrieve the base
> URL in a plugin (in Trac 0.11)?
Some days ago, Noah told me to use req.href() or req.abs_href() for
this, but constructing the base URL from the current request is not
always the best solution. Regards,
- Christian
Emmanuel Blot
"base url", python uri root and the like should be simplified before
0.11 is delivered.
The documentation may need to be updated so that
the base URL appears to be the single, unique location (base_url in
trac.ini). No more "UriRoot" option in Apache, for instance.
Moreover, I'm not a big fan to hard code the base url in the trac.ini
file. At least, the "server" part of the URL.
The rationale is that it prevents Trac from being served from several
server names, for example an installation with http://localhost,
http://a.b.c.c and http://server need to use three different Trac
engine to server the same environment, which is a bit overkill. This,
in turn, force the use of syslog for the error logger, if all the
messages are to be sent to the same file whatever the server name used
to access Trac.
I understand though that Trac needs to know its own URL, for example
when a notification is triggered from a hook script, Trac needs to
know the URL and it can't get it from a web request.
However, would it be possible to split the base_url option into the
server part (which is required for the notification) and the base path
part (which cannot be guessed right from the client requests, if I my
understanding is correct) ?
Is the "server" part of base_url required for anything else than the
notification subsystem ?
Thanks,
Manu
--
Manu
Noah Kantrowitz
time to implement it. The procedure to isolating req.base_path should be
1. Look for a WSGI variable trac.base_url (possibly from SetEnv
TRAC_BASE_URL or PythonOption TracBaseUrl).
2. Look at base_url in trac.ini.
3. Guess from the request (not an option always).
I think this covers all the use cases quite cleanly, and would greatly
simplify the deployment of Trac on DreamHost-style shared servers.
--Noah
Christian Boos
Yes, it's also required for redirects.
Trac can't always guess the right protocol to be used, e.g. when running
behind a proxy (#2253, #3207) or when using openssl (#3208, #comment:5 -
workaround described in TracModPython#HTTPSissues)
There are numerous duplicate tickets for this (#5454, #4532, #3207,
#2697) but http://trac.edgewall.org/ticket/2553 is the reference.
With http://trac.edgewall.org/changeset/5642, base_url is now used to
override the URL reconstruction, though that's also not OK in all cases,
as mentioned in the changeset, which hints at #5064.
Hence my proposal for two distinct settings in
http://trac.edgewall.org/ticket/5064#comment:2, which can be summarized
like this:
- *either* use base_url when you want to force the usage of an URL over
URL reconstruction from the request
- *or* use default_url when you only want to give a default URL for
situations when you don't have a requests at hand (e.g. e-mail
notifications). URL reconstruction will be done for redirects.
Of course, if base_url is set, default_url doesn't need to be.
If none is set, then URL reconstruction is used for redirects and (that
was not in the proposal above) we could eventually set default_url from
the request on first use, the way we did it for base_url before r4086.
See also:
- http://trac.edgewall.org/changeset/3298
- http://trac.edgewall.org/changeset/4086
In addition (I've just read Noah's mail) I agree that the base_url
setting should preferably be done from a wsgi environment parameter, as
its main usage is for redirects. On the other hand, default_url fits
better in trac.ini - it shouldn't need to depend on the request.
-- Christian