> -----Original Message----- > From: [email protected] [mailto:[EMAIL PROTECTED] On > Behalf Of Christopher Lenz > Sent: Tuesday, September 02, 2008 1:52 AM > To: [email protected] > Subject: [Trac-dev] Re: Request match "precision" in match_request() > > > 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
I thought about adding this as a core system, but there are places where a trailing / is probably legal. The biggest one is attachment URLs, since / is a legal filename character on some OSes. Granted it isn't any major ones, so probably it would be fine to add this at the level of the URL dispatcher. --Noah --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
