[tahoe-dev] darcs patch: Allow client-specified keys
Brian Warner
warner-tahoe at allmydata.com
Mon Feb 9 14:53:19 PST 2009
On Mon, 9 Feb 2009 15:19:08 -0700 (MST)
Shawn Willden <shawn-tahoe at willden.org> wrote:
> Mon Feb 9 15:15:20 MST 2009 Shawn Willden <shawn-tahoe at willden.org>
> * Allow client-specified keys
Cool! Some thoughts:
Take a look at the first comment in #320 for our current ideas about the
webapi syntax for user-specified keys. Basically key=CHK, or key=random, or
key=pp4fhu5o2eaft7zk7gmicmylpa (base32), or
key=ee190f82b19632aff99718534ed89679 (hexidecimal). But if you only felt like
implementing the base32 one, I'd be ok with that. It might also be a good
idea to consider a type indicator, like key=base32-pp4fhu5o2eaft7zk7gmicmylpa
so future extensions might be cleaner.
Passing the key through the Uploadable object is exactly right.
Your test_PUT_NEWFILEURL_specified_key uses base62, but your
test_POST_upload_specified_key uses base32. I'd prefer to use base32 for
everything: note that base62 is currently unused in the codebase (we added it
early in anticipation new+shorter ECDSA-based mutable file caps).
Please add a note to docs/frontends/webapi.txt (to the PUT and POST
sections that deal with new-file upload) to indicate the new
functionality.
Please add a test (to test_web) to ensure that PUT /uri (i.e. uploading an
unlinked file) also accepts the key= argument.
We need a test to confirm that upload actually uses the key you requested, by
asserting the returned filecap starts with URI:CHK:$MYKEY: .
test_upload.GoodServer is the place for that, copy test_data_large into a new
test_provided_key() and have it examine the returned URI.
We also need a test to confirm that a webapi request actually uses the key
you requested. The test_web suite is insufficient for this, because it fakes
the upload process, so add a routine to test_system.SystemTest._test_web,
around like 1170 (right after the first self.PUT/self.GET pair).
Confirm that the tests work by temporarily making your get_key_arg() function
always return None: that should cause the tests to fail.
thanks!
-Brian
#320 add streaming upload to HTTP interface:
http://allmydata.org/trac/tahoe/ticket/320
More information about the tahoe-dev
mailing list