Well, with URLs, it's not known which part (word) of the url local part is a directory and which is a file/script.
http://www.example.com/dir/file.php/extra/info is legal. At the time of parsing, it is not intrinsically knowable that file.php is a script. Therefore, you can't look at just the last element, but need to match wordwise left to right. Melanie On 01/04/2014 21:47, Jim Williams wrote: > 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 <[email protected]> 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 _______________________________________________ Opensim-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev
