I think the correct way to look at this is that any URI "..../handler/..." should be passed to the correct "handler" handler; which should then pass the rest of the path on to any sub-handlers as appropriate. You shouldn't be looking at the parts of a path element unless it is the leaf (follows the last slash). The URI began life as a directory tree, and you would not match part of the directory thinking it was a file. Any valid semantic URI parser will interpret elements of a URI strictly in context, and never assume anything about elements except within the context of the element to its immediate left.
It would be ok for /asset and /asset_test to be treated as a match, but never ok for /asset/ and /asset_test or /asset_test/ to match. One is matching a directory to a file, and the other is matching two different directories. On Tue, Apr 1, 2014 at 3:08 PM, Mic Bowman <cmick...@gmail.com> 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 <mela...@t-data.com> 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 >> >>> Opensim-dev@lists.berlios.de >> >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >>> >> >>> >> >> _______________________________________________ >> >> Opensim-dev mailing list >> >> Opensim-dev@lists.berlios.de >> >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >> >> > >> > >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev@lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -- No essence. No permanence. No perfection. Only action.
_______________________________________________ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev