milestone name containing spaces breaks milestone editing within roadmap view and admin module

[hazen@…]

Steps to reproduce:

1. From Trac instance homepage, click "Roadmap".
2. Click "Add new milestone".
3. Set field "Name of milestone:" to "More Coffee".
4. Click "Add milestone". Notice that we're still on the "New Milestone" page, and the "Name of milestone:" field now reads "More%20Coffee" (URL encoding).
5. Click "Roadmap". Notice that milestone "More Coffee" is present.
6. Click link for milestone "More Coffee". Notice that we're back at the "New Milestone" page, instead of editing the "More Coffee" milestone.

Expected behavior:

Milestones with phrasal names act the same as milestones whose names do not contain spaces. Otherwise, perhaps some intelligent conversion of phrasal names to camel case should occur.

[Remy Blank]

That seems to be a frontend issue. It's working fine here with both tracd and Apache / mod_wsgi. What web frontend do you use? Do you use a proxy?

It seems that something is URL-encoding that shouldn't.

[hazen@…]

Yes, this could be the problem; I'm using nginx to proxy https requests to trac via fastcgi. I'm not sure how to verify nginx is the culprit here. Is there anything with trac's logs I could search for to determine this?

[hazen <hazen@…>]

I've verified that trac is receiving URL encoded requests from nginx:

2010-11-03 12:38:31,266 Trac[main] DEBUG: Dispatching <Request "GET '/milestone/More%20Coffee'">

Should this really cause trac to misbehave as described above? I'm not sure I can alter nginx's URL encoding behavior without modifying its source. I'm using nginx v0.8.53.

[Christian Boos]

If you were proxying to trac via ajp, you could use the --unquote parameter (have a look at the tips in TracStandalone#Usingtracdbehindaproxy).

Otherwise, this report sounds a lot like #9034, which was solved by … migrating to lighttpd ;-)

If you want to stay with nginx, you could eventually go with the TracNginxRecipe and use tracd like described above.

What kind of script are you using right now? The standard trac.fcgi or something else? We might eventually add to the trac.fcgi something similar to tracd's --unquote.

[hazen@…]

cboos, thanks for pointing out #9034. That is indeed my setup. I moved from lighttpd to nginx because of ​this problem a while ago (proxy response buffering of large trac attachments was bringing the host to its knees), but perhaps that issue has been resolved.

I'm using the standard trac.fcgi generated by trac-admin <env> deploy, started via ​spawn-fcgi to listen to a unix socket.

[Remy Blank]

None of the developers are using nginx, so I'm afraid you're on your own. I'm keeping this ticket open, please report back if you manage to get your setup working.

[hvisser]

Just found that in Trac 0.12.2 you can set the TRAC_USE_FLUP environment var to true and fcgi_frontend.py will escape the url before passing it to Trac. That solved this issue for me. My setup is also nginx, and Trac through fastcgi.