Editing of Milestones does not work while running under mod_python

[aashley@…]

Our system is setup with trac running under mod_python with it setup to be accessible as the root dir of a virtual host (​http://trac/ on our internal network).

When accessing trac through this URL none of the edits to a milestone are saved. Everything is silently discarded. I've setup a seperate access to our trac install using the CGI setup, this one can successfully edit a milestone.

[aashley@…]

Couldnt find it when searching before posting but it looks like this is a duplicate of #1142

[aashley@…]

Bit more information on my setup:

This is on Fedora Core 3 with latest updates and the trac RPMs from the DAG repository. No custom built stuff at all.

[Christopher Lenz]

Probably related to #1101.

[aashley@…]

Okay I've looked into it more and I think I've figured out the problem.

When running under mod_python with it setup to be the root of a virtual host var:cgi_location in the cs templates evaluates to an empty string. which means the action field for the form ends up as action="".

Now different browsers handle this differently. Specifically mozilla firefox attempts to post it to the current page's url.

192.168.1.252 - - [09/Feb/2005:11:53:08 +0800] "POST /milestone/3.0.10?action=edit HTTP/1.1" 200 9660 "​http://trac/milestone/3.0.10?action=edit" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20050117 Firefox/1.0"

However you're processing forms/urls it seems the url takes precedence and so the form submitted info is lost.

Comparing how the form works running as a cgi script I manually edited the milestone.cs to set the action field to / (action="/"). This gets the same behaviour of the cgi script, posting the form elements to the base script.

192.168.1.252 - - [09/Feb/2005:11:55:15 +0800] "POST / HTTP/1.1" 302 14 "​http://trac/milestone/3.0.10?action=edit" "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20050117 Firefox/1.0"

This caused firefox to post to / which got the changes to take.

Basically the fix for this problem is to make sure var:cgi_location is set to the base url for the script and not left blank. Unfortunatly I'm not very knowledgable with python code or I'd fix this myself.

Also to not this problem didnt occur with the text mode browser links, but them it does its handling of form submission and redirection unlike most other browsers.

[Christopher Lenz]

Checking whether this is still a problem after my recent refactorings…

[Christopher Lenz]

Yep, this has been fixed in [1256], and ported to stable in [1258]. Fix will be in the 0.8.1 release.