[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