Next: Implementation issues
Up: Publius
Previous: Delete
Update
Our system provides a mechanism for Alice to update something
that she previously published. We use the same password mechanism
that is used to delete content. Thus, Alice can change any web page
that she published, but nobody else can. The idea
is to enable Alice to change content without changing the URL, because
others may have linked to the original site. After the update, anyone
retrieving the original URL receives the new content.
In addition to file, share, and password,
there is a file called update on the servers in the namei
directory. Initially, if Alice has not updated the content, the
file does not exist. When Bob retrieves the URL, if the update file
is missing, everything proceeds as described in Section 3.3.
To update the content, Alice specifies a file name containing the new
content, the original URL, the original password PW and a new password.
The update program first publishes the new content by simply calling publish
with the file name and the new password. Once the new content is published,
the original URL is used to find the n servers that host the
Publius content. Each of these servers receives a message from Alice (a call
to a CGI script) containing the original password stored on that server (recall
that this is
), the old namei, and the new URL.
Each server then places the new URL in the update file and
deletes the contents in the old file.
When Bob retrieves Publius content, if the update file exists,
the servers return the update URL instead of the contents. Bob receives
the update URL from k servers and compares them, if they are all equal,
he then retrieves the new URL instead. Of course, Bob is not aware of
what the retrieve program is doing behind the scenes. From his point of
view, he makes a request and receives the web page. If the k URLs do
not match, Bob (his proxy) then tries the other n-k servers until he either gets
k that are the same, or gives up. In Section 5 we discuss
other ways this could be implemented and several tradeoffs that arise.
Although the update mechanism is very convenient it leaves Publius
content vulnerable to a redirection attack. In this attack several
malicious server administrators collaborate to insert an update file
in order to redirect requests for the Publius content.
A mechanism exists within Publius to
prevent such an attack. During the publicaton process the publisher has the
option of declaring a Publius URL as nonupdateable. When a Publius client
attempts to retrieve Publius content from a nonupdateable URL all update URLs
are ignored. See Section 4.1 for more information about nonupdateable
URLs.
Next: Implementation issues
Up: Publius
Previous: Delete
Avi Rubin
2000-06-13