I said Semantic, not syntactic. :) I agree, but syntactically we should be doing no semantic thinking at all until we get to the handler for file.php (Python), who would do the semantic parsing and might feel like doing some pattern matching on the elements to the right. That is, we shouldn't even be looking at the last element during syntactic analysis. It's probably a mistake to even parse the string to the right of file.php, other than to find its end, but almost all parsers I've ever seen don't know when to stop.
On Tue, Apr 1, 2014 at 3:59 PM, Melanie <mela...@t-data.com> wrote: > 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 <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 > >> > > > > > > > > > > > > _______________________________________________ > > 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
