#644 closed defect (duplicate)
Wrong URLs in db and omega cgi
| Reported by: | terencz | Owned by: | Olly Betts |
|---|---|---|---|
| Priority: | normal | Milestone: | 1.2.21 |
| Component: | Omega | Version: | 1.2.12 |
| Severity: | normal | Keywords: | |
| Cc: | Blocked By: | ||
| Blocking: | Operating System: | Linux |
Description
I upgraded from debian squeeze to wheezy and the URLs went wrong.
For example "Szerződések" is now shown as "Szerz%C5%91d%C3%A9sek" in database and the omega cgi web frontend.
Change History (5)
comment:3 by , 10 years ago
| Resolution: | → duplicate |
|---|---|
| Status: | new → closed |
Thanks for the clarification.
I think this is already covered by #550, so closing this as a duplicate.
Note:
See TracTickets
for help on using tickets.
Are you saying these URLs don't work, or just that they look ugly?
If the former, please can you provide us with some examples of document filenames which when indexed reproduce the problem.
If the latter, I think what you're seeing is the result of fixing a bug in that older version - we weren't encoding characters in URLs which should be encoded according to the relevant RFCs, which was causing problems in some cases.
There's now a $prettyurl omegascript command which undoes some of this encoding in cases where it doesn't actually seem to be required in practice with the commonly used webbrowsers - the aim is to produce a more human readable version of the URL which is still likely to work if cut and pasted (since some users will try that). Unfortunately, top-bit-set characters are a bit problematic, as we don't know necessarily know what encoding filenames have on the system, and inside $prettyurl we don't know what character set the page we're generating has. There's certainly scope for improvement here, and there's already ticket #550 open for this issue.