[tahoe-dev] webapi updates

Brian Warner warner at allmydata.com
Mon Aug 13 16:03:55 PDT 2007


> What do you think about redefining dirnode URI's to not contain the  
> "pb://" characters?  And likewise for other slashes in our URIs, so  
> that users of the URIs can treat them as opaque strings that don't  
> need to be examined or manipulated.

I think in the long run, dirnodes will be distributed, and we'll be 
identifying them with a StorageIndex rather than something which 
contains a furl (and therefore another layer of URI-like syntax). So 
eventually this problem will go away.

I also think that it ought to be perfectly legal to have slashes in the 
URL, but we had some bad experiences with what was probably an apache 
ReverseProxy configuration which mangled the slashes in a query 
argument. We might be mistaken about that (I don't think we put a lot of 
energy into characterizing the bug before bailing and just 
base32-encoding the whole thing).

So I'm tempted to agree and put some vague energy (post-0.5.0 certainly) 
into redefining our dirnode URIs, and I like the idea that we can 
promise that all of our URIs use a well-known limited set of characters 
that is chosen to reduce problems like this one.

But for this issue in particular, I'd also like to keep the FURL as an 
opaque string (with certain promises, like no spaces or the like), 
rather than defining our dirnode URIs in a way that's highly dependent 
upon the FURL syntax. If we decided tomorrow that our dirnode URIs could 
use an HTTP reference to point at the contents (say, is someone were 
using an apache server to provide read-only access to some large static 
directory structure, or something), then it'd be nice if the only thing 
that changed was the code that interprets the portion of the URI that 
tells it how to get to the dirnode server.

Dunno what direction that suggests, though.

cheers,
  -Brian


More information about the tahoe-dev mailing list