Hey thank for repeating what I said... when using a web server to serve the static files you should get rid of Cascade and staticURLParser. But the underlying question remains, how do you distinguish between static files and urls for which we defined dynamic controller actions ?
One (bad) idea, is to first check if there is a static file matching the URL and serve it if it exists, otherwise try to find a dynamic controller action mapped to the URL. This behavior is the default for pylons and rails I believe. But like I said it has two main disadvantages : 1. You have to do a file lookup (e.g. system fstat() call) to determine if the static file exists before routing it to a controller. This is wasteful. 2. If a file exists with the same name as a URL defined in the route mapping for a dynamic controller action, then this file will be served instead of invoking the controller action. This can lead to bugs if you create a such a file by mistake. The above problems also happen in the case of using a web server that performs the static file existence check before proxying the request to pylons. Instead, it's MUCH better to separate the namespace by choosing different prefixes for static files and dynamic content. For example, all URLs for static files can start with /static, and/or all URLs for dynamic actions should start with /dynamic. There are TONS of fools on rails blogs/forums discussing what kind of apache directives to use to test for files existence to decide wether to serve the file or proxy the request etc. They don't understand that this whole problem could be solved with using URLs with different prefixes. Hope this clarifies my point On Dec 27, 4:59 pm, "Mike Orr" <[email protected]> wrote: > On Sat, Dec 27, 2008 at 1:26 PM, Tycon <[email protected]> wrote: > > > I use /static for all my static file, except maybe robots and favicon > > which cant be moved. > > As for StaticURLParser, using that as the first choice in the Cascade > > is wasteful cause > > it means pylons will do a file lookup for every request (bad > > performance) in addition to the > > fact that filenames may hijack pylons controller mapped routes (bad > > design calling for bugs). > > > You can (and should) get rid of StaticURLParser and the Cascade if > > your web server is serving > > the static files (with a /static url prefix), or at least move > > StaticURLParser to the second choice > > in the Cascade when accessing the app directly from Paster http server > > (without a separate web server). > > My, he's opinionated. In a high-traffic situation you'd have Apache > or your favorite webserver serve the static URLs before the > application sees them, and then you can get rid of StaticURLParser and > Cascade entirely. > > I'm not sure whether moving StaticURLParser after the Pylons > application would be better or worse. My instinct is that it would be > worse because a typical dynamic page has several static components. > > As for a filename "hijacking" a mapped route, I'm not sure what you > mean. If you mean that with identical URLs, the static one is chosen, > that's the programmer's problem; he should arrange the URLs so they > don't overlap (and think about putting static files under a few > well-known directories while he's at it). > > -- > Mike Orr <[email protected]> --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" 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/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
