#6649 closed defect (worksforme)
can not use parameter in URL
Reported by: | anonymous | Owned by: | Jonas Borgström |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | general | Version: | 0.11b1 |
Severity: | normal | Keywords: | |
Cc: | Branch: | ||
Release Notes: | |||
API Changes: | |||
Internal Changes: |
Description
http://localhost/trac/personal/newticket%3Fcc%3Daa
is the same as
http://localhost/trac/personal/newticket?cc=aa
But use "/newticket%3Fcc%3Daa" to open ticket. System may diplay error information as following.
No handler matched request to /newticket?cc=aa
Attachments (0)
Change History (5)
comment:1 by , 17 years ago
follow-up: 3 comment:2 by , 17 years ago
Resolution: | → worksforme |
---|---|
Status: | new → closed |
I don't see the problem here. Those two URLs are not the same. It's possible that your web browser decodes the first URL, such that it looks the same as the second URL. But they're not the same, and they are not treated the same by either your web browser or by the web server.
comment:3 by , 17 years ago
Resolution: | worksforme |
---|---|
Status: | closed → reopened |
Replying to hyuga <hyugaricdeau@gmail.com>:
I don't see the problem here. Those two URLs are not the same. It's possible that your web browser decodes the first URL, such that it looks the same as the second URL. But they're not the same, and they are not treated the same by either your web browser or by the web server.
If so, how can I add normal URL in templates/site.html?
I add url as following.
<a href="${href('/newticket?cc=aa')}">test</a>
Trac will display the url as
comment:4 by , 17 years ago
Resolution: | → worksforme |
---|---|
Status: | reopened → closed |
Try:
<a href="${href('newticket',cc='aa')}">test</a> <!-- or --> <a href="${href.newticket(cc='aa')}">test</a>
It will add each normal argument or dot-notation accessor item as an item in the path (join them with '/'), and any keyword argument will be a query parameter.
Afaik "?" and "=" are reserved characters for URLs and must only be encoded when they're used as data. So I guess this is intended behaviour.
See: http://www.rfc-editor.org/rfc/rfc1738.txt