[tahoe-dev] wanted in webapi: a way to download a file only if it is a file
Brian Warner
warner at allmydata.com
Thu Aug 9 19:58:27 PDT 2007
> Still, this is non-obvious and I think the webapi would be improved
> by providing a way to express "Just get me the file." without saying
> "Get me the file or else some human-readable web page if it turns out
> it isn't a file.".
Yeah. It's a question of what seems most obviously correct, and it
depends upon how much time you spend hanging around apache, I guess. I
think we can agree that a GET of a file should just return its contents.
I think there's also a strong argument that a GET of a directory should
give you a way to examine and/or manipulate that directory. I think I'm
invoking Zipf's Law here: the shortest command should be the most
frequent one, in this case it's a question of what URL the human types
into their browser and what they expect that URL to do. So GET of a file
gets the file, GET of a directory shows the directory in a
browser-useful (ie HTML for humans) way.
But I quite agree that the nondeterministic behavior of GET on a node of
unknown type is a big problem for a program that's trying to behave
correctly. Channeling Tyler for a moment, (and Tyler, forgive me if I'm
misrepresenting your design aesthetic here), I can imagine an argument
that a GET of a directory should return a special XML representation of
that directory, marked by the Content-Type being something like
x-application/allmydata-tahoe-dirnode-xml or something, and have it be
delivered with an XSLT stylesheet that transforms the machine-meaningful
directory contents into a human-manipulable HTML page. This approach
would basically merge the GET(dirnode?t=json) with the GET(dirnode)
(i.e. t=html) and make a single URL useful for both purposes. The
program would do a GET of the URL, then examine the Content-Type to
determine whether it should save the data to a file or if it should
interpret it as a directory (and then either indicate an error to the
user or perhaps to a recursive download if that weren't too surprising,
say perhaps because the user had passed in a "-r" flag).
However, this sounds a bit crazy to me, partially because I don't know
enough XSLT to even attempt to implement it. So I'd be happy with an
indicator that the program could use to point out that it is only going
to be happy with a file. GET(url?t=file) would signal an error if the
url actually pointed to a dirnode. If the url refers to a file, then
GET(url?t=file) would behave exactly the same as GET(url).
(thinking about further, it might be the case that the HTTP header that
says which content-types you are willing to accept might be relevant
here, except that then you'd want the file-fetch to say that it would
accept everything *except* the magic directory type, and I don't know if
the syntax allows for that sort of thing).
cheers,
-Brian
>
> Regards,
>
> Zooko
>
> _______________________________________________
> tahoe-dev mailing list
> tahoe-dev at allmydata.org
> http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
More information about the tahoe-dev
mailing list