[Opensim-dev] REST handlers use partial string matching

[Melanie]

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 <cmickeyb at 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 <melanie at 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 at lists.berlios.de
>>> >>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>> >>>
>>> >>>
>>> >> _______________________________________________
>>> >> Opensim-dev mailing list
>>> >> Opensim-dev at lists.berlios.de
>>> >> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>> >>
>>> >
>>> >
>>> _______________________________________________
>>> Opensim-dev mailing list
>>> Opensim-dev at lists.berlios.de
>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>>
>>
>>
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>
> 
> 
> 
> 
> 
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev