Edgewall Software
Modify

Opened 15 years ago

Last modified 9 years ago

#8328 new enhancement

Repeat SCRIPT_NAME fixup using SCRIPT_URL after environment selection

Reported by: Martin.vGagern@… 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 Christian Boos)

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)

LateScriptNameFixup.patch (1.8 KB ) - added by Martin.vGagern@… 15 years ago.
RequestUri.patch (563 bytes ) - added by Martin.vGagern@… 14 years ago.
Fall back to REQUEST_URI if SCRIPT_URL is unset
RequestUri.2.patch (615 bytes ) - added by Martin.vGagern@… 14 years ago.
Fall back to REQUEST_URI if SCRIPT_URL is unset

Download all attachments as: .zip

Change History (15)

by Martin.vGagern@…, 15 years ago

Attachment: LateScriptNameFixup.patch added

comment:1 by Christian Boos, 14 years ago

Milestone: next-major-0.1X

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.

in reply to:  1 comment:2 by Martin.vGagern@…, 14 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 Martin.vGagern@…, 14 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 Martin.vGagern@…, 14 years ago

Attachment: RequestUri.patch added

Fall back to REQUEST_URI if SCRIPT_URL is unset

by Martin.vGagern@…, 14 years ago

Attachment: RequestUri.2.patch added

Fall back to REQUEST_URI if SCRIPT_URL is unset

comment:4 by Martin.vGagern@…, 14 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 Christian Boos, 14 years ago

Keywords: verify added

comment:6 by Christian Boos, 13 years ago

Description: modified (diff)
Keywords: verify removed
Milestone: next-major-0.1X0.13
Owner: set to Christian Boos

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:7 by Martin.vGagern@…, 13 years ago

Yes, your summary is accurate.

comment:8 by Remy Blank, 12 years ago

Milestone: 1.01.0-triage

Preparing for 1.0.

comment:9 by Christian Boos, 12 years ago

Milestone: next-stable-1.0.xnext-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 anonymous, 10 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 Ryan J Ollos, 9 years ago

Milestone: next-dev-1.1.xnext-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 Ryan J Ollos, 9 years ago

Owner: Christian Boos removed

Modify Ticket

Change Properties
Set your email in Preferences
Action
as new The ticket will remain with no owner.
The ticket will be disowned.
as The resolution will be set. Next status will be 'closed'.
The owner will be changed from (none) to anonymous. Next status will be 'assigned'.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.