[tahoe-dev] [tahoe-lafs] #958: LAFS 301 Moved Permanently
tahoe-lafs
trac at allmydata.org
Fri Feb 19 23:20:03 PST 2010
#958: LAFS 301 Moved Permanently
------------------------------------------------------------------------------------+
Reporter: zooko | Owner:
Type: enhancement | Status: new
Priority: major | Milestone: eventually
Component: code-mutable | Version: 1.6.0
Keywords: forward-compatibility backward-compatibility integrity newcaps newurls | Launchpad_bug:
------------------------------------------------------------------------------------+
Changes (by davidsarah):
* keywords: forward-compatibility integrity newcaps newurls => forward-
compatibility backward-compatibility
integrity newcaps newurls
* milestone: undecided => eventually
Comment:
As a backward-compatibility hack to allow users of older webapi servers to
be able to access the target of the redirection, we can store it as a
directory, with one of its children specifying that it is a redirection
link (for example, by using a "redirection: true" entry in the "tahoe"
metadata).
This would cause newer servers to return a 301 Moved Permanently response
(maintaining any subsequent URL path elements). Users of older servers
would see this just as a child of the directory, and could follow it
manually. The other children could be used to maintain the validity of
existing links -- for instance an URL ending in /wiki.html would end up
pointing to a petrified version of that file.
This wouldn't work if the original URI is to an immutable file or
directory. However, if it is to a mutable directory (which is probably the
common case, and is true for Zooko's blog URL for example), then it would
be possible to direct it to a new mutable or immutable directory.
--
Ticket URL: <http://allmydata.org/trac/tahoe/ticket/958#comment:2>
tahoe-lafs <http://allmydata.org>
secure decentralized file storage grid
More information about the tahoe-dev
mailing list