Opened 15 years ago
Last modified 9 years ago
#8328 new enhancement
Repeat SCRIPT_NAME fixup using SCRIPT_URL after environment selection
Reported by: | Owned by: | ||
---|---|---|---|
Priority: | normal | Milestone: | next-major-releases |
Component: | web frontend | Version: | 0.11-stable |
Severity: | normal | Keywords: | |
Cc: | Branch: | ||
Release Notes: | |||
API Changes: | |||
Internal Changes: |
Description (last modified by )
Ticket #2299 introduced a very useful feature to guess the SCRIPT_NAME from the SCRIPT_URL. However, this works less than optimal in some scenarios using an env_parent_dir.
Example: suppose you want to serve multiple project home pages using multiple virtual hosts from apache, and suppose further that, in order to save memory e.g. on a virtual server, you want to serve all Trac requests from a single FastCGI process. You can configure the process to serve from a parent of all trac environments, and add a line like this to the individual vhosts:
ScriptAlias /trac/ /path/to/trac.fcgi/my.environment.name/
This works well enough, except for the links. The link detection checks that the SCRIPT_URL (e.g. /trac/wiki/PageName
) ends with the PATH_INFO (e.g. /my.environment.name/wiki/PageName
) - which is not the case. Subsequently, the first part of the PATH_INFO is used to choose the environment, and moved from PATH_INFO to SCRIPT_NAME, causing a wrong script name of /trac/my.environment.name
.
This can easily be solved by doing the same fixup after the environment has been chosen. In that case, PATH_INFO only contains /wiki/PageName
which allows correct detection of /trac
as the SCRIPT_NAME for that environment, not all environments.
In order to produce correct link in the listing of all available projects (in setups providing access to this list, not in a vhost like the one above), the fixup before should probably be kept in place as well, or be moved to send_project_index. Because it has to be executed from two places, it might make sense to factor it into a separate function.
A patch for this is easy. If you want me to write one, I'll do so. For now, I've simply moved the whole block dealing with script_url to after the env_path selection, as I don't need the project listing. So the concept is proven.
Attachments (3)
Change History (15)
by , 15 years ago
Attachment: | LateScriptNameFixup.patch added |
---|
follow-up: 2 comment:1 by , 15 years ago
Milestone: | → next-major-0.1X |
---|
comment:2 by , 15 years ago
Replying to cboos:
This looks like a quite useful change, but I fail to see all the implications
What makes you think there are more implications than you can see? Seriously, I'm not 100% sure I've considered all possibilities, but still pretty sure that the thing is at least as safe as the current version.
and as I can't really test that,
If you want me to create an apache config for a test setup and send it to you (or rather attach it here), let me know.
I'll move it to a further release.
That would probably be 0.13, right? As I've patched my own copy, I personally am in no hurry to see this committed, so I can wait a year. Of course it would be even better if there were a branch for the next stable release, so that features like this can be committed to trunk and receive testing there without affecting 0.12.
comment:3 by , 15 years ago
While you are at it, you might consider using REQUEST_URI
as a fallback in cases where SCRIPT_URL
is undefined. It seems SCRIPT_URL
is defined only if the mod_rewrite engine is enabled, whether that particular request was rewritten or not. With a ScriptAlias
as described above, but without rewrite engine, SCRIPT_URL
is not available, and REQUEST_URI
is the second best bet.
by , 15 years ago
Attachment: | RequestUri.patch added |
---|
Fall back to REQUEST_URI if SCRIPT_URL is unset
by , 15 years ago
Attachment: | RequestUri.2.patch added |
---|
Fall back to REQUEST_URI if SCRIPT_URL is unset
comment:4 by , 15 years ago
I'll take back my patches about REQUEST_URI
, as that won't work properly in the presence of url quoting. Back to my initial patch, which should be much safer.
comment:5 by , 14 years ago
Keywords: | verify added |
---|
comment:6 by , 14 years ago
Description: | modified (diff) |
---|---|
Keywords: | verify removed |
Milestone: | next-major-0.1X → 0.13 |
Owner: | set to |
I admit I had a hard time getting my head around this… Let me try to summarize.
The current situation, in case of TRAC_ENV_PARENT_DIR scenario, we have something like that:
ScriptAlias /trac/ /var/path/on/fs/to/script.fcgi
Now if we receive a request like: /trac/my.trac.env/wiki/WikiStart
, Apache sets the variables like this:
REQUEST_URI /trac/my.trac.env/wiki/WikiStart SCRIPT_URL /trac/my.trac.env/wiki/WikiStart PATH_INFO /my.trac.env/wiki/WikiStart -------------------------------------------- SCRIPT_NAME /trac
We actually want to reconstruct SCRIPT_NAME from SCRIPT_URL (as we can't trust the current value of SCRIPT_NAME which might have been subject to rewriting), and for that we take the difference between SCRIPT_URL and PATH_INFO. The first segment in PATH_INFO will give us the name of the Trac environment, the rest will be the req.path_info
.
Now in your situation, you want to have a direct access to the environment via a virtual host, and to that end you "augment" the file path in the ScriptAlias
directive with an arbitrary name, like that:
ScriptAlias /trac/ /var/path/on/fs/to/script.fcgi/my.trac.env/
According to what you said, Apache will somehow detect that /var/path/on/fs/to/script.fcgi/my.trac.env/
doesn't exist on the file system, and will prepend /my.trac.env
to the PATH_INFO:
REQUEST_URI /trac/wiki/WikiStart SCRIPT_URL /trac/wiki/WikiStart PATH_INFO /my.trac.env/wiki/WikiStart
I haven't verified this by myself, but I tried something similar with mod_wsgi, and I indeed see the same:
WSGIScriptAlias /trac /packages/trac/virtualenv-0.13/bin/trac.wsgi/my.trac.env/ REQUEST_URI /trac/wiki/WikiStart SCRIPT_URL /trac/wiki/WikiStart PATH_INFO /my.trac.env/wiki/WikiStart
comment:9 by , 12 years ago
Milestone: | next-stable-1.0.x → next-dev-1.1.x |
---|
Oh no, not this one… This ticket is an old friend of mine, as I already spent too much time on it. I need to really finish it someday ;-)
Moving enhancements to dev.
comment:10 by , 11 years ago
I'm facing the same issue. I host multiple trac under the same WSGIScriptAlias location /bts.
Unfortunately I have traces of request to '/trac_repo/chrome/common/…' instead of '/bts/trac_repo/chrome/common/…'.
It worked with 0.12 and mod_python but fails with 1.0.1 with wsgi.
The variables are like this :
REQUEST_URI /bts/it-repo/chrome/common/trac_logo_mini.png SCRIPT_NAME /bts SCRIPT_FILENAME /var/www/trac/cgi-bin/trac.wsgi PATH_INFO /trac_repo/chrome/common/trac_logo_mini.png PATH_TRANSLATED /var/www/it-repo/chrome/common/trac_logo_mini.png
Declaration is made with WSGIScriptAlias /bts /var/www/trac/cgi-bin/trac.wsgi
with trac.wsgi modified to force TRAC_ENV_PARENT_DIR.
Can't you plan it to a 1.0 patch ?
comment:11 by , 10 years ago
Milestone: | next-dev-1.1.x → next-major-releases |
---|
Retargetting tickets to narrow focus for milestone:1.2. Please move the ticket back to milestone:next-dev-1.1.x if you intend to resolve it by milestone:1.2.
comment:12 by , 9 years ago
Owner: | removed |
---|
This looks like a quite useful change, but I fail to see all the implications and as I can't really test that, I'll move it to a further release.