Re: [Opensim-dev] REST handlers use partial string matching
Thanks, that was a good catch! Melanie On 02/04/2014 08:07, Oren Hurvitz wrote: I changed BaseHttpServer to require handler paths to match a full path component. For example, these match: /assets and /assets/12345 But these don't match: /assets and /assets_exist -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/REST-handlers-use-partial-string-matching-tp7579119p7579140.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
Re: [Opensim-dev] REST handlers use partial string matching
I changed BaseHttpServer to require handler paths to match a full path component. For example, these match: /assets and /assets/12345 But these don't match: /assets and /assets_exist -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/REST-handlers-use-partial-string-matching-tp7579119p7579140.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
Re: [Opensim-dev] REST handlers use partial string matching
Yeah, it's an interesting problem. A quick google doesn't reveal any obvious solutions, though one StackOverflow thread [1] has an interesting approach of wrapping multiple requests in a 'batch' request. So I don't object to this, but I don't think that we should kid ourselves that we're writing pure REST interfaces. get_asset_exists is effectively an RPC call which POSTs a bunch of UUIDs and gets data back - it is not an HTTP verb operating on a resource. Also, it would be great if you could add this new call to [2]. I'm very slowly trying to document all the various interfaces, protocols and calls, so that it's possible for other projects to implement them, to get a better overview of interfaces in OpenSimulator, etc. [1] http://stackoverflow.com/questions/14636332/convention-for-combining-rest-requests-and-replies [2] http://opensimulator.org/wiki/AssetService On 01/04/14 20:49, Oren Hurvitz wrote: Re: why use POST instead of HEAD: because this lets me check the existence of many assets at once with a single HTTP request. The main use of the AssetsExist call is with HGAssetGatherer, which knows the full list of assets that it wants to send, so it's able to check all of them at once. -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/REST-handlers-use-partial-string-matching-tp7579119p7579127.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 . -- Justin Clark-Casey (justincc) OSVW Consulting http://justincc.org http://twitter.com/justincc ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] REST handlers use partial string matching
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
Re: [Opensim-dev] REST handlers use partial string matching
Hi Oren. I believe the expected way to retrieve metadata (and effectively an existence check) for a resource in REST would be to send a HEAD request [1] to the url, rather than to have a separate endpoint. I think changing the handling to exact matching is fine - I can't think why partial matching is done currently and I can't see how it makes sense in an HTTP context. As far as I know nothing makes use of partial matching. [1] http://books.google.co.uk/books?id=XUaErakHsoACpg=PA98lpg=PA98dq=restful+web+services+%22OPTIONS+method+lets%22source=blots=5jkmCnpNmysig=mXt_bcmXcZhoU6hFFm0L5j14IvEhl=ensa=Xei=Hf06U--1E7GM7Aad2YHwAwved=0CDMQ6AEwAA#v=onepageq=restful%20web%20services%20%22OPTIONS%20method%20lets%22f=false On 01/04/14 14: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 -- Justin Clark-Casey (justincc) OSVW Consulting http://justincc.org http://twitter.com/justincc ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] REST handlers use partial string matching
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 -- Justin Clark-Casey (justincc) OSVW Consulting http://justincc.org http://twitter.com/justincc ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] REST handlers use partial string matching
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
Re: [Opensim-dev] REST handlers use partial string matching
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
Re: [Opensim-dev] REST handlers use partial string matching
Ah okay, I see what you mean. Yes, the asset/ part matches the asset handler and then it is in charge of interpreting the subsequent 456392f6-c0b3-a346-6465-8218cbe7abe84592 section of the path. When you said 782911... below I thought that you were talking about UUID fragments as used by git to identify commits, where 782911 would normally be enough to identify an asset like 782911f6-c0b3-a346-6465-8218cbe7abe84592 so you could say something like GET http://myserver.com/asset/782911. But that was a misinterpretation. On 01/04/14 20:00, Melanie 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 . -- Justin Clark-Casey (justincc) OSVW Consulting http://justincc.org http://twitter.com/justincc ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] REST handlers use partial string matching
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
Re: [Opensim-dev] REST handlers use partial string matching
Re: why use POST instead of HEAD: because this lets me check the existence of many assets at once with a single HTTP request. The main use of the AssetsExist call is with HGAssetGatherer, which knows the full list of assets that it wants to send, so it's able to check all of them at once. -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/REST-handlers-use-partial-string-matching-tp7579119p7579127.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
Re: [Opensim-dev] REST handlers use partial string matching
Do you really save much with a single request vs a keep alive on the connection? HTTP connection overhead is likely much smaller than the database operations... do you have a feel for how much we'll save with the multiplexed call? --mic On Tue, Apr 1, 2014 at 12:49 PM, Oren Hurvitz or...@kitely.com wrote: Re: why use POST instead of HEAD: because this lets me check the existence of many assets at once with a single HTTP request. The main use of the AssetsExist call is with HGAssetGatherer, which knows the full list of assets that it wants to send, so it's able to check all of them at once. -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/REST-handlers-use-partial-string-matching-tp7579119p7579127.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
Re: [Opensim-dev] REST handlers use partial string matching
The proper method is to break up the local portion of the URL into words using / as the separator, then matching that list of words against similar lists created from the registered URLs, usually stored as a tree. There are two ways to match, shortest match and more specific. The algorithm used by apache is shortest match, meaning that as soon as a word list is fully matched against the request's words, it's considered a match and the handler is invoked. Everything past the matched portion becomes extra path info. Melanie On 01/04/2014 21:08, Mic Bowman 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
Re: [Opensim-dev] REST handlers use partial string matching
Not sure about this particular application but keeping a connection open can eliminate the need to instantiate a connection whenever a request is made; a process that can make several round trips to multiple endpoints. On Tue, Apr 1, 2014 at 12:52 PM, Mic Bowman cmick...@gmail.com wrote: Do you really save much with a single request vs a keep alive on the connection? HTTP connection overhead is likely much smaller than the database operations... do you have a feel for how much we'll save with the multiplexed call? --mic On Tue, Apr 1, 2014 at 12:49 PM, Oren Hurvitz or...@kitely.com wrote: Re: why use POST instead of HEAD: because this lets me check the existence of many assets at once with a single HTTP request. The main use of the AssetsExist call is with HGAssetGatherer, which knows the full list of assets that it wants to send, so it's able to check all of them at once. -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/REST-handlers-use-partial-string-matching-tp7579119p7579127.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
Re: [Opensim-dev] REST handlers use partial string matching
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
Re: [Opensim-dev] REST handlers use partial string matching
HEAD is meant to test if a request endpoint is implemented and to retrieve metadata like detailed capabilities/options/flags. Melanie On 01/04/2014 21:49, Oren Hurvitz wrote: Re: why use POST instead of HEAD: because this lets me check the existence of many assets at once with a single HTTP request. The main use of the AssetsExist call is with HGAssetGatherer, which knows the full list of assets that it wants to send, so it's able to check all of them at once. -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/REST-handlers-use-partial-string-matching-tp7579119p7579127.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
Re: [Opensim-dev] REST handlers use partial string matching
Because REST is cleaner and more modularized than RPC. Just compare the code and you will see that. Efficiency is achieved by designing the REST calls intelligently. The /asset/ endpoint for instance can benefit from keep-alive because it supports HEAD/GET?POST so multiple operations can reuse the connection. The exists query is orthogonal to that and should be another request endpoint. Melanie On 01/04/2014 21:56, Dahlia Trimble wrote: Not sure about this particular application but keeping a connection open can eliminate the need to instantiate a connection whenever a request is made; a process that can make several round trips to multiple endpoints. On Tue, Apr 1, 2014 at 12:52 PM, Mic Bowman cmick...@gmail.com wrote: Do you really save much with a single request vs a keep alive on the connection? HTTP connection overhead is likely much smaller than the database operations... do you have a feel for how much we'll save with the multiplexed call? --mic On Tue, Apr 1, 2014 at 12:49 PM, Oren Hurvitz or...@kitely.com wrote: Re: why use POST instead of HEAD: because this lets me check the existence of many assets at once with a single HTTP request. The main use of the AssetsExist call is with HGAssetGatherer, which knows the full list of assets that it wants to send, so it's able to check all of them at once. -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/REST-handlers-use-partial-string-matching-tp7579119p7579127.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
Re: [Opensim-dev] REST handlers use partial string matching
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
Re: [Opensim-dev] REST handlers use partial string matching
BTW, for assets, in particular, there is already a GET metadata method, which is the same endpoint of the data itself, just with one more path compoenent /metadata/, if I remember correctly. This should be enough to know if the asset exists. Doesn't address the issue of multiple UUIDs in one call vs one at a time. On 4/1/2014 1:02 PM, Melanie wrote: Because REST is cleaner and more modularized than RPC. Just compare the code and you will see that. Efficiency is achieved by designing the REST calls intelligently. The /asset/ endpoint for instance can benefit from keep-alive because it supports HEAD/GET?POST so multiple operations can reuse the connection. The exists query is orthogonal to that and should be another request endpoint. Melanie On 01/04/2014 21:56, Dahlia Trimble wrote: Not sure about this particular application but keeping a connection open can eliminate the need to instantiate a connection whenever a request is made; a process that can make several round trips to multiple endpoints. On Tue, Apr 1, 2014 at 12:52 PM, Mic Bowman cmick...@gmail.com wrote: Do you really save much with a single request vs a keep alive on the connection? HTTP connection overhead is likely much smaller than the database operations... do you have a feel for how much we'll save with the multiplexed call? --mic On Tue, Apr 1, 2014 at 12:49 PM, Oren Hurvitz or...@kitely.com wrote: Re: why use POST instead of HEAD: because this lets me check the existence of many assets at once with a single HTTP request. The main use of the AssetsExist call is with HGAssetGatherer, which knows the full list of assets that it wants to send, so it's able to check all of them at once. -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/REST-handlers-use-partial-string-matching-tp7579119p7579127.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
Re: [Opensim-dev] REST handlers use partial string matching
The AssetsExist API is implemented efficiently in all levels of the stack including the database, where a single query checks all the assets. So a single HTTP request will be vastly more efficient than multiple calls, even if KeepAlive works. And I never trust KeepAlive anyway because I've used proxies that didn't enable KeepAlive by default (mod_ajp_proxy). -- View this message in context: http://opensim-dev.2196679.n2.nabble.com/REST-handlers-use-partial-string-matching-tp7579119p7579137.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
