From: Geoffrey T. <gta...@na...> - 2002-04-26 20:32:13
|
Terrel Shumway wrote: > > I agree completely that the way an app server like Webware > manages URI > > space should make no assumptions about filesystems. That's, in my > > view, the major Webware wart. > > I hadn't thought of it that way. But yes, that is exactly right. I'm happy to see more flexibility in Webware's URI handling as long as the current behavior remains the default behavior out of the box. More flexible URI handling is a bonus for content-management types of applications, but it doesn't help at all for the type of application I'm developing (and for many other apps too). - Geoff |
From: Geoffrey T. <gta...@na...> - 2002-04-29 13:28:55
|
Tavis Rudd wrote: > As an aside, the current WebKit URL-decoding process relies > on each URL chunk > being a valid Python module/package name: > > http://example.com/WK/thisIsValid/_SoIsThis/00ButThisIsNot/Servlet.py > > You can work around this with extraPathInfo, but then I > assume you can't drop > the extension: > > http://example.com/WK/Servlet.py/thisIsValid/_SoIsThis/00NowThisValid/ [works] > > http://example.com/WK/Servlet/thisIsValid/_SoIsThis/00NowThisValid/ [does this work??] Actually, I just tried it and it looks like ExtraPathInfo isn't working at all :-( Does anyone use it currently? I'm adding a bug report to SourceForge. That said, when it gets fixed, seems to me that it ought to allow the second example -- you should be able to leave off the extension. - Geoff |
From: Kendall C. <ke...@mo...> - 2002-04-26 20:43:59
|
>>>>> "geoffrey" == Geoffrey Talvola <gta...@na...> writes: geoffrey> Terrel Shumway wrote: >> > I agree completely that the way an app server like Webware >> manages URI >> > space should make no assumptions about filesystems. That's, in >> > my view, the major Webware wart. >> >> I hadn't thought of it that way. But yes, that is exactly right. geoffrey> I'm happy to see more flexibility in Webware's URI geoffrey> handling as long as the current behavior remains the geoffrey> default behavior out of the box. I suppose that's reasonable, if for least-surprise reasons, if no other, though least-surprise has a limited shelf life, IMO. geoffrey> More flexible URI handling is a bonus for geoffrey> content-management types of applications, but it doesn't geoffrey> help at all for the type of application I'm developing geoffrey> (and for many other apps too). I think it's almost entirely orthogonal to the *kind* of application one is building; that is, I just don't see any positive reason to make assumptions about filesystem entities in the code that resolves a URI into some resource on the server that is responsible for that URI. Amazon is a pretty good example; there's a rather complex Web app that runs the site, and I can't ever remember seeing a ?query-string URL; it appears to pass all arguments as hierarchical elements separated by "/". That doesn't strike me as application *type*-specific at all. In some cases, it's merely a matter of style, preference, and other considerations (like those in the W3C's URI style recommendations). Best, Kendall Clark |
From: Luke O. <lu...@ro...> - 2002-04-26 21:46:04
|
> Amazon is a pretty good example; there's a rather complex > Web app that > runs the site, and I can't ever remember seeing a > ?query-string URL; > it appears to pass all arguments as hierarchical elements > separated by > "/". We do things like this now, using Webware and mod_rewrite. Not that I'm particularily enamored with having to create page-specific regexps for mod_rewrite, but I think it will be specific and hard to generalize for webware to automatically handle. For instance, old-style URL for us: http://www.somewhere.com/products.psp?id=502 is viewed/linked for the real world: http://www.somewhere.com/products/502 and could just as easily be http://www.somewhere.com/products/view/502 as opposed to perhaps http://www.somewhere.com/products/502/order which could map to the real webware URL of http:://www.somewhere.com/order.psp?productid=502 The main reason we switched to this was actually for search engines, as they tend to ignore query strings, and our customers would prefer that every product gets hit. I imagine Amazon's reasons would be similar. I'm not sure at all how I would tell Webware to do this stuff. In my mind the purpose is to remove restraints of the underlying technical solution (what Webware pages do what processing), which mod_rewrite is perfectly suited for. Luke ===== ------------------ Reference Counting Garbage Collection: Look out philosophy majors, things really DO cease to exist when no one is looking at them! ------------------ __________________________________________________ Do You Yahoo!? Yahoo! Games - play chess, backgammon, pool and more http://games.yahoo.com/ |
From: <ir...@ms...> - 2002-04-26 21:56:13
|
On Fri, Apr 26, 2002 at 02:46:00PM -0700, Luke Opperman wrote: > http://www.somewhere.com/products.psp?id=502 Are you able to use mod_rewrite with query strings? I've got a (non-Webware) application that stupidly funnels articles through /article.php?article_id=1234 and I would like to redirect each article to a new URL /article/1234 or (in other cases) redirect a few articles while letting all the others pass thorugh. But whenever I try to use mod_rewrite, it strips the query string off the source URI, so I can't match according to query string. -- -Mike (Iron) Orr, ir...@ms... (if mail problems: ms...@oz...) http://iron.cx/ English * Esperanto * Russkiy * Deutsch * Espan~ol |
From: Luke O. <lu...@ro...> - 2002-04-26 22:29:33
|
Actually, I lied a bit. We're not using mod_rewrite for these, but a little C++ ISAPI filter for IIS using boost.org's Regex++. However, you can do query strings from mod_rewrite as well. Using RewriteCond for something like your example: RewriteCond %{QUERY_STRING} id=([^&;]*) RewriteRule (.*)articles\.psp $1articles/%1? [L] Or something close to that. Relevant parts: RewriteCond backreferences use %1,%2 etc as opposed to regular backreferences $1,$2. The trailing question mark on the RewriteRule tells it to remove the query string from the request (i suppose this would be optional..?) Now, for my purposes (where the incoming URL is already correct sans-querystring, and I actually want to reinsert a querystring for the servlets) it's very easy. If you include a ? in the substitution string, mod_rewrite's docs say it will automatically modify QUERY_STRING. RewriteRule (.*)articles/([0-9]+) $1articles?id=$2 [L] Again, not tested but it's close. Luke --- Mike Orr <ir...@ms...> wrote: > On Fri, Apr 26, 2002 at 02:46:00PM -0700, Luke Opperman > wrote: > > http://www.somewhere.com/products.psp?id=502 > > Are you able to use mod_rewrite with query strings? I've > got a > (non-Webware) application that stupidly funnels articles > through > /article.php?article_id=1234 > and I would like to redirect each article to a new URL > /article/1234 > or (in other cases) redirect a few articles while letting > all > the others pass thorugh. > > But whenever I try to use mod_rewrite, it strips the > query string > off the source URI, so I can't match according to query > string. ===== ------------------ Reference Counting Garbage Collection: Look out philosophy majors, things really DO cease to exist when no one is looking at them! ------------------ __________________________________________________ Do You Yahoo!? Yahoo! Games - play chess, backgammon, pool and more http://games.yahoo.com/ |
From: Kendall C. <ke...@mo...> - 2002-04-26 22:31:14
|
On Fri, Apr 26, 2002 at 03:00:48PM -0700, Mike Orr wrote: > On Fri, Apr 26, 2002 at 02:46:00PM -0700, Luke Opperman wrote: > > http://www.somewhere.com/products.psp?id=502 > > Are you able to use mod_rewrite with query strings? I've got a > (non-Webware) application that stupidly funnels articles > through > /article.php?article_id=1234 > and I would like to redirect each article to a new URL > /article/1234 > or (in other cases) redirect a few articles while letting all > the others pass thorugh. Hmm, here's the relevant parts of my mod_rewrite setup: RewriteRule ^/+articles/+$ / [PT,QSA] RewriteRule ^/+articles$ / [PT,QSA] RewriteRule ^/+articles/+([0-9]+)/+plain/? /articles/plain.py?id=$1 [PT,QSA] RewriteRule ^/+articles/+([0-9]+)/+email/? /articles/emtp.py?id=$1 [PT,QSA] RewriteRule ^/+articles/+([0-9]+)/? /articles/index.py?id=$1 [PT,QSA] So, if I understand you right, you want something like: RewriteRule ^/article.php?article_id=([0-9]+) /article/$1 [PT,QSA] and so on. Feel free to ask questions if that's not clear. Best, Kendall Clark |
From: Kendall C. <ke...@mo...> - 2002-04-26 22:24:46
|
On Fri, Apr 26, 2002 at 02:46:00PM -0700, Luke Opperman wrote: > > > Amazon is a pretty good example; there's a rather complex > > Web app that > > runs the site, and I can't ever remember seeing a > > ?query-string URL; > > it appears to pass all arguments as hierarchical elements > > separated by > > "/". > > We do things like this now, using Webware and mod_rewrite. > Not that I'm particularily enamored with having to create > page-specific regexps for mod_rewrite, but I think it will > be specific and hard to generalize for webware to > automatically handle. Why? Imagine a configuration file that did nothing but this: /URI-pattern /filesystem-pointer So, /products /foo/bar/webware/ProductServlet.py And ProductServlet.py gets "/502" as an argument and does the right thing with it. Seems pretty straightforward. Now, I don't suggest this is how the mapping should go, since it's simplistic and laborious, but there's no reason it couldn't go this way. There's no reason you can't define a simple XML format to model URI space (in fact, it's been done) and use explicit containment relations and XPath queries to map URI space to Webware source resources. > For instance, old-style URL for us: > > http://www.somewhere.com/products.psp?id=502 > > is viewed/linked for the real world: > > http://www.somewhere.com/products/502 > > and could just as easily be > > http://www.somewhere.com/products/view/502 > > as opposed to perhaps > > http://www.somewhere.com/products/502/order > > which could map to the real webware URL of > > http:://www.somewhere.com/order.psp?productid=502 > > The main reason we switched to this was actually for search > engines, as they tend to ignore query strings, and our > customers would prefer that every product gets hit. I > imagine Amazon's reasons would be similar. Sure, that's one very good reason, actually. > I'm not sure at all how I would tell Webware to do this > stuff. I think the point is that presently it's not particularly easy, if doable at all, In my mind the purpose is to remove restraints of > the underlying technical solution (what Webware pages do > what processing), which mod_rewrite is perfectly suited > for. I use mod_rewrite heavily, but it's not terribly ideal: 1) It's grotty black magic voodoo and I usually have to ritually slaughter many Perl hackers to get it to work, and that's messy 2) I want to do these mappings in something like Webware (or XPath), i.e., something that's expression-based; I don't like regex much at all 3) Though mod_rewrite is C code, I think there's more overhead doing it in Apache than in Python as part of the algorithm of mapping URIs to source resources, but that's more of a guess than a solid opinion. There are several web and app servers that offere total flexibility to do this mapping; I can't think of any reasons why in principle Webware can't do the same thing. Best, Kendall Clark |
From: Tavis R. <ta...@re...> - 2002-04-26 22:42:45
|
On April 26, 2002 03:22 pm, Kendall Clark wrote: > I use mod_rewrite heavily, but it's not terribly ideal: I agree. Pushing this stuff into WebKit allows much greater flexibility = and=20 integration. However, mod_rewrite rules and WebKit-based-URL-decoding ar= e=20 not mutually exclusive. Some uses of mod_rewrite, such as direct serving= of=20 static content, have no place in WebKit. > 1) It's grotty black magic voodoo and I usually have to ritually slaugh= ter > many Perl hackers to get it to work, and that's messy > > 2) I want to do these mappings in something like Webware (or XPath), i.= e., > something that's expression-based; I don't like regex much at all > > 3) Though mod_rewrite is C code, I think there's more overhead doing it= in > Apache than in Python as part of the algorithm of mapping URIs to sourc= e > resources, but that's more of a guess than a solid opinion. I'd guess the other way around! ----- As an aside, the current WebKit URL-decoding process relies on each URL c= hunk=20 being a valid Python module/package name: http://example.com/WK/thisIsValid/_SoIsThis/00ButThisIsNot/Servlet.py You can work around this with extraPathInfo, but then I assume you can't = drop=20 the extension: http://example.com/WK/Servlet.py/thisIsValid/_SoIsThis/00NowThisValid/ [w= orks] http://example.com/WK/Servlet/thisIsValid/_SoIsThis/00NowThisValid/ [does= this=20 work??] Tavis |
From: Luke O. <lu...@ro...> - 2002-04-26 22:44:36
|
--- Kendall Clark <ke...@mo...> wrote: > Imagine a configuration file that did nothing but this: > > /URI-pattern /filesystem-pointer > > So, > > /products /foo/bar/webware/ProductServlet.py > > And ProductServlet.py gets "/502" as an argument and does > the right thing > with it. Seems pretty straightforward. Agreed, easy to manually define mappings. But it's not automatic, I think my point was that tools already exist for this (mod_rewrite in particular), and if you're going to write a config file to map each one I don't see why that functionality needs to be part of WebWare. Presumably the motivation for it to be in Webware is that there is knowledge we don't have at mod_rewrite's time. perhaps you'd allow mappings based on Session info? Fair enough, if there's actually a justifiable use. Luke ===== ------------------ Reference Counting Garbage Collection: Look out philosophy majors, things really DO cease to exist when no one is looking at them! ------------------ __________________________________________________ Do You Yahoo!? Yahoo! Games - play chess, backgammon, pool and more http://games.yahoo.com/ |
From: Geoffrey T. <gta...@at...> - 2002-04-29 00:40:56
|
On Friday April 26, 2002 04:43 pm, Kendall Clark wrote: > >>>>> "geoffrey" == Geoffrey Talvola <gta...@na...> writes: > > geoffrey> Terrel Shumway wrote: > >> > I agree completely that the way an app server like Webware > >> > >> manages URI > >> > >> > space should make no assumptions about filesystems. That's, in > >> > my view, the major Webware wart. > >> > >> I hadn't thought of it that way. But yes, that is exactly right. > > geoffrey> I'm happy to see more flexibility in Webware's URI > geoffrey> handling as long as the current behavior remains the > geoffrey> default behavior out of the box. > > I suppose that's reasonable, if for least-surprise reasons, if no > other, though least-surprise has a limited shelf life, IMO. > > geoffrey> More flexible URI handling is a bonus for > geoffrey> content-management types of applications, but it doesn't > geoffrey> help at all for the type of application I'm developing > geoffrey> (and for many other apps too). > > I think it's almost entirely orthogonal to the *kind* of application > one is building; that is, I just don't see any positive reason to make > assumptions about filesystem entities in the code that resolves a URI > into some resource on the server that is responsible for that URI. For the sake of keeping things simple. Having a simple URI-servlet mapping helps with ease of understanding for the developers building the web application. > > Amazon is a pretty good example; there's a rather complex Web app that > runs the site, and I can't ever remember seeing a ?query-string URL; > it appears to pass all arguments as hierarchical elements separated by > "/". If I'm writing forms with action=get, I'm going to get ?=style query-string parameters regardless of whether I'd prefer a different format. I may as well use that format in other places where I'm constructing the URI too -- why make my job more difficult by having to handle a different parameter format? > > That doesn't strike me as application *type*-specific at all. In some > cases, it's merely a matter of style, preference, and other > considerations (like those in the W3C's URI style recommendations). > Point taken, but I'll still prefer to keep things simple, and for me that means sticking with the way Webware works now. - Geoff |