The proper method is to break up the local portion of the URL into words using "/" as the separator, then matching that list of words against similar lists created from the registered URLs, usually stored as a tree. There are two ways to match, "shortest match" and "more specific". The algorithm used by apache is "shortest match", meaning that as soon as a word list is fully matched against the request's words, it's considered a match and the handler is invoked. Everything past the matched portion becomes extra path info.
Melanie On 01/04/2014 21:08, Mic Bowman wrote: > so what you're saying is just make sure the '/' is part of the match? to > terminate the match? i think the problem is that /asset matches /asset_test > which is not what is expected. so all registered partial matches should > include the trailing '/' to disambiguate... or am i missing the point? > > > > On Tue, Apr 1, 2014 at 12:00 PM, Melanie <[email protected]> wrote: > >> It is required because it's the basis of "extra path info". It's not >> part of REST, but rather part of HTTP. >> >> Requesting >> >> /asset/456392f6-c0b3-a346-6465-8218cbe7abe84592 >> >> which is not a registered URL, will invoke >> >> /asset/ >> >> which is. The ID passed as part of the URL is then given to that >> handler as the extra path info. You have the same thing in apache. >> >> Basically, any URL longer than and starting with a registered URL >> will invoke that registered URL with extra path info. >> The fallacy in our server is that the matching isn't by path parts, >> but character-wise. >> >> Melanie >> >> On 01/04/2014 20:03, Justin Clark-Casey wrote: >> > In what context is such partial matching required? It is not a >> requirement of REST, as far as I know. >> > >> > On 01/04/14 18:55, Melanie wrote: >> >> The REST URLs need to use partial matching, however, current >> >> semantics are broken. >> >> >> >> Without partial matching, URLS like /assets/782911..... would not >> >> work. the issue here is that it should match whole URL parts, not >> >> partial URL parts. Matching partial words as it does now seems like >> >> someone was cutting corners, it's not by design. >> >> >> >> /assets/ should match /assets/9887234...... but not /assets_exist. >> >> The slash is the differentiator and partial compares of URL string >> >> prefixes should be done by full-string matches of slash/delimited >> >> parts, not prefix matching of the entire URL. >> >> >> >> Melanie >> >> >> >> On 01/04/2014 15:00, Oren Hurvitz wrote: >> >>> I tried to add a REST handler at the endpoint "/assets_exist". It >> turns out >> >>> that I can't do that, because REST handlers are searched using partial >> >>> string matches, so servers that don't implement the new handler will >> >>> mistakenly choose the "/assets" endpoint instead. >> >>> >> >>> For now, I solved the problem by using a different endpoint: >> >>> "/get_assets_exist". >> >>> >> >>> For the future, I think that this should be changed so that only full >> string >> >>> matches work. Otherwise each time a new handler is added it will have >> to >> >>> find an endpoint name that isn't a prefix of any current endpoint -- a >> >>> difficult and error-prone task. Before I do that, does anyone know of >> >>> endpoints that rely on the current behavior (partial string matches)? >> >>> >> >>> >> >>> >> >>> -- >> >>> View this message in context: >> http://opensim-dev.2196679.n2.nabble.com/REST-handlers-use-partial-string-matching-tp7579119.html >> >>> Sent from the opensim-dev mailing list archive at Nabble.com. >> >>> _______________________________________________ >> >>> Opensim-dev mailing list >> >>> [email protected] >> >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >>> >> >>> >> >> _______________________________________________ >> >> Opensim-dev mailing list >> >> [email protected] >> >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >> >> > >> > >> _______________________________________________ >> Opensim-dev mailing list >> [email protected] >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > > > > _______________________________________________ > Opensim-dev mailing list > [email protected] > https://lists.berlios.de/mailman/listinfo/opensim-dev _______________________________________________ Opensim-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev
