<div dir="ltr">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.<div>
<br></div><div>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.</div>
<div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Apr 1, 2014 at 3:08 PM, Mic Bowman <span dir="ltr"><<a href="mailto:cmickeyb@gmail.com" target="_blank">cmickeyb@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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?<div>

<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Apr 1, 2014 at 12:00 PM, Melanie <span dir="ltr"><<a href="mailto:melanie@t-data.com" target="_blank">melanie@t-data.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It is required because it's the basis of "extra path info". It's not<br>
part of REST, but rather part of HTTP.<br>
<br>
Requesting<br>
<br>
/asset/456392f6-c0b3-a346-6465-8218cbe7abe84592<br>
<br>
which is not a registered URL, will invoke<br>
<br>
/asset/<br>
<br>
which is. The ID passed as part of the URL is then given to that<br>
handler as the extra path info. You have the same thing in apache.<br>
<br>
Basically, any URL longer than and starting with a registered URL<br>
will invoke that registered URL with extra path info.<br>
The fallacy in our server is that the matching isn't by path parts,<br>
but character-wise.<br>
<br>
Melanie<br>
<br>
On 01/04/2014 20:03, Justin Clark-Casey wrote:<br>
> In what context is such partial matching required?  It is not a requirement of REST, as far as I know.<br>
><br>
> On 01/04/14 18:55, Melanie wrote:<br>
>> The REST URLs need to use partial matching, however, current<br>
>> semantics are broken.<br>
>><br>
>> Without partial matching, URLS like /assets/782911..... would not<br>
>> work. the issue here is that it should match whole URL parts, not<br>
>> partial URL parts. Matching partial words as it does now seems like<br>
>> someone was cutting corners, it's not by design.<br>
>><br>
>> /assets/ should match /assets/9887234...... but not /assets_exist.<br>
>> The slash is the differentiator and partial compares of URL string<br>
>> prefixes should be done by full-string matches of slash/delimited<br>
>> parts, not prefix matching of the entire URL.<br>
>><br>
>> Melanie<br>
>><br>
>> On 01/04/2014 15:00, Oren Hurvitz wrote:<br>
>>> I tried to add a REST handler at the endpoint "/assets_exist". It turns out<br>
>>> that I can't do that, because REST handlers are searched using partial<br>
>>> string matches, so servers that don't implement the new handler will<br>
>>> mistakenly choose the "/assets" endpoint instead.<br>
>>><br>
>>> For now, I solved the problem by using a different endpoint:<br>
>>> "/get_assets_exist".<br>
>>><br>
>>> For the future, I think that this should be changed so that only full string<br>
>>> matches work. Otherwise each time a new handler is added it will have to<br>
>>> find an endpoint name that isn't a prefix of any current endpoint -- a<br>
>>> difficult and error-prone task. Before I do that, does anyone know of<br>
>>> endpoints that rely on the current behavior (partial string matches)?<br>
>>><br>
>>><br>
>>><br>
>>> --<br>
>>> View this message in context: <a href="http://opensim-dev.2196679.n2.nabble.com/REST-handlers-use-partial-string-matching-tp7579119.html" target="_blank">http://opensim-dev.2196679.n2.nabble.com/REST-handlers-use-partial-string-matching-tp7579119.html</a><br>


>>> Sent from the opensim-dev mailing list archive at Nabble.com.<br>
>>> _______________________________________________<br>
>>> Opensim-dev mailing list<br>
>>> <a href="mailto:Opensim-dev@lists.berlios.de" target="_blank">Opensim-dev@lists.berlios.de</a><br>
>>> <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
>>><br>
>>><br>
>> _______________________________________________<br>
>> Opensim-dev mailing list<br>
>> <a href="mailto:Opensim-dev@lists.berlios.de" target="_blank">Opensim-dev@lists.berlios.de</a><br>
>> <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
>><br>
><br>
><br>
_______________________________________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@lists.berlios.de" target="_blank">Opensim-dev@lists.berlios.de</a><br>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
</blockquote></div><br></div>
<br>_______________________________________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br></blockquote></div><br><br clear="all"><div><br></div>-- <br>No essence.  No permanence.  No perfection.  Only action.
</div>