On 01.09.2008, at 01:35, Remy Blank wrote: > While working on #4878 (Weird URL handling of additional characters > on the end), which asks that requests to e.g. "/timeline/bogus" > either return a 404 or a permanent redirect to "/timeline", I've > been looking at match patterns in match_request(). This has raised a > few questions for which I would like to get some feedback: > > * Currently, many request handlers match very liberally. For > example, any request that matches "/admin.*" will be handled by the > admin module, including "/adminlskjdfkljsd". Is this intentional? If > not, shouldn't this be fixed?
Not intentional AFAIK, should be fixed. > * Many handlers allow a trailing /, for example "/newticket" and "/ > newticket/". What is the reason for this? Noah has mentioned this > being a convenience for people entering URLs that don't know what > they are doing. Are there any other reasons? The problem here is that if you don't allow a trailing slash, you should at least automatically redirect from e.g. /foo/ to /foo (most of the web does this the other way around, but hey). So if we get more strict here, we need to add some kinda of slash- stripping redirector thing. > * The "matching precision" is very variable between handlers. Some > handlers match only precise URLs (e.g. "/tickets/([0-9]+)$"), others > are more graceful (e.g. "/report(?:/([0-9]+))?", which will show the > list of available reports for "/report/bogus"). > > Is there a rule for how precise a match_request() should be? I see > two possibilities: > > * Be strict in what a handler accepts. This has the advantage of > giving a more precise answer for malformed URLs (usually a "No > handler matched request to ..."). But it is less forgiving for user- > entered URLs, and might therefore have usability issues. If this > option should be followed, then a trailing / should probably not be > accepted. > > * Be forgiving, and return a reasonable result for any URL matching > at least the handler's root component. For example, in the case of > the timeline, show the timeline for any request matching "/ > timeline/.*". The advantage is that users are less likely to be > shown an error message. But this is technically less correct. > > Opinions? Which rule should I follow? I very much prefer strict. The rule should be not to expose the same resource/representation under multiple different URIs. So even if there are valid convenience features such as allowing both /foo/ and / foo, one needs to redirect (as in 301) to the other. One issue here is that changes in this space may break URIs out there on the web (bookmarks, search indices, links etc). That's something we need to be very careful about: we're not just "breaking" the Trac site, but the sites of all the Trac users out there. :P Cheers, Chris -- Christopher Lenz cmlenz at gmx.de http://www.cmlenz.net/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en -~----------~----~----~----~------~----~------~--~---
