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
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:
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
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
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
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.
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
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
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
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
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.
--
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
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
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
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
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
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
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
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
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
20 matches
Mail list logo
