sorry for the belated answer, i've been quite busy lately. > mod_wsgi > Paste server, [...] server [...] of CherryPy
thanks for the pointers. last time i installed mod_python i had to tweak some sources related to WSGI to get it working. i haven't tried mod_wsgi yet, but that would tie me to apache as well. apart from that, it looks like the successor of mod_python to me, so i definitely want to check it out. i want to keep my app's requirements small and not force users to have to setup apache (where that is an option, i'm fine with it). > If the rule is defined with a trailing slash the rule matcher will only > allow one trailing slash. Remove the trailing slash and it eats > everything. This is a side-effect of the strict trailing slash processing > and is here to stay. ok, with strict_slashes on and a rule without trailing slash i get the intended result. >I don't think that's a bug and I don't feel like I want to have a "fix" >for that in Werkzeug. The routing system is already more complex than it >has to be. definitely not one to fix things that are not needed---i have been writing under the assumption such a change would make things *simpler*, not more *complicated*. funny tho that strict_slashes on makes url interpretation *less* strict in this regard, but maybe that's just me. either way, i'll manage to get that working, so pls. don't waste time on it, no hard feelings. (my use case is users that type urls directly into their address bars, e.g. `example.com/foo bar` and `example.com/foo/bar`, whatever, take you to a search results page... basically bypassing `q=foo+bar` syntax. granted that "multiple trailing slashes are [not] useful at all" in 99% of all cases, i must deal with users sending such requests in some way. yes, this is an edge case.) while testing i stumbled over a problematic point that i have encountered (and fixed) before, and one that developers might be interested in: at least firefox2 has a habit of sending out urls that are encoded in latin-1 (or latin-9?) where that is possible (i.e. where all characters are encodable as latin-1), and only use utf-8 where necessary (details are likely os- and locale-dependent; ie6 has a setting "send all urls in utf-8" that probably addresses this issue). if you know nothing about your users and their preferred locale, url decoding is hard since no encoding information is given in requests, leaving you with lots of options. to see this at work, try to access `x.com/ä` and `x.com/ä同` (yes, x.com is owned by paypal). if your ffx2 setup resembles mine, the address bar will show `http://x.com/%E4` in the first and `http:// x.com/%C3%A4%E5%90%8C` in the latter case (and, interestingly, the site is able to correctly render the first, but not the second request). in a previous project i managed to get around this issue by first trying to decode values using utf-8 and fall back on latin-1 (or whatever) on failure. my own current setup (werkzeug+wsgiref) does not correctly handle latin-1 urls. a simple view method that spits out request details simply omits any text following a latin-1 encoded umlaut. i'll fix that when i have decided on a wsgi server (i monkey-patched paste.util.multidict.UnicodeMultiDict._decode_value back then, but it doesn't look like werkzeug.utils.MultiDict is the right place this time around). some people might have been a tad upset about some of my wordings, and i apologize if i came across in haughty or harsh ways. that was unintentional. i like werkzeug a lot, and coming from pylons, i can't really tell what i am missing for all the (e.g. architectural) freedom i've gained. i'm much happier with this lighter solution. cheers & ~flow --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pocoo-libs" 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/pocoo-libs?hl=en -~----------~----~----~----~------~----~------~--~---
