LAFS 301 Moved Permanently #958
Labels
No Label
0.2.0
0.3.0
0.4.0
0.5.0
0.5.1
0.6.0
0.6.1
0.7.0
0.8.0
0.9.0
1.0.0
1.1.0
1.10.0
1.10.1
1.10.2
1.10a2
1.11.0
1.12.0
1.12.1
1.13.0
1.14.0
1.15.0
1.15.1
1.2.0
1.3.0
1.4.1
1.5.0
1.6.0
1.6.1
1.7.0
1.7.1
1.7β
1.8.0
1.8.1
1.8.2
1.8.3
1.8β
1.9.0
1.9.0-s3branch
1.9.0a1
1.9.0a2
1.9.0b1
1.9.1
1.9.2
1.9.2a1
LeastAuthority.com automation
blocker
cannot reproduce
cloud-branch
code
code-dirnodes
code-encoding
code-frontend
code-frontend-cli
code-frontend-ftp-sftp
code-frontend-magic-folder
code-frontend-web
code-mutable
code-network
code-nodeadmin
code-peerselection
code-storage
contrib
critical
defect
dev-infrastructure
documentation
duplicate
enhancement
fixed
invalid
major
minor
n/a
normal
operational
packaging
somebody else's problem
supercritical
task
trivial
unknown
was already fixed
website
wontfix
worksforme
No Milestone
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Reference: tahoe-lafs/trac-2024-07-25#958
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Make it possible to mark a cap as moved-permanently, including possibly to a cap of a newer version.
Described in [//pipermail/tahoe-dev/2010-February/003910.html] as follows:
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.
Replying to davidsarah:
Note that this implementation would require a new webapi operation to set this field of the metadata. Whether we use a "tahoe" subkey is independent of the rest of the idea; adding a new operation for redirection obviously adds some complexity, but it may be desirable to ensure that this can't occur accidentally when using existing APIs.
Proposed CLI command:
Note that for HTTP clients, it's normally the client's responsibility to follow redirects. However the CLI commands (which are webapi clients) don't currently do so. Should we have the webapi server follow redirects in order to simplify webapi clients? It would have to follow redirects anyway in order to implement non-HTTP frontends (SFTP, FTP and SMB).
Replying to davidsarah:
Ah, no they wouldn't. A single storage server might have K distinct shares. To make the above statement true, we'd have to change download so that it always uses K servers (at some cost in availability).
Replying to davidsarah:
No, we can't, because that would defeat the point of using a redirect (as a machine-readable way to signal that the URL has been updated, and in the case of browsers, that the new URL should be shown in the address bar).
I think we'll just have to do it in both the webapi server and clients (since these other protocols have no way to express a redirect).
Replying to davidsarah:
They don't because source:src/allmydata/scripts/common_http.py uses
httplib
directly. But this is easy to fix, for example by usingurllib2
as described here.So we should open another ticket to make the CLI commands follow redirects (if we're correct that they don't).
The ticket to make the CLI commands follow redirects is #965.
Replying to davidsarah:
Maybe this backwards-incompatibility won't be necessary! I think there might be an extensible structure, the contents of which the storage servers will pass on to downloaders without needing to understand the contents themselves. In particular, I think maybe the UEB (someday to be renamed CEB when "URI" gets renamed "Capability" everywhere) can hold the new 301 redirection marker and the new cap that this cap has been redirected to.
Replying to [zooko]comment:10:
How would older servers know to refuse to update a share? Temporary redirect wouldn't require upgrading servers, but we can't see how to avoid that for permanent redirect (if it is to be usable for revocation).
Yes, that's a viable alternative design to putting the marker in the metadata, but it doesn't seem to solve the problem of older servers still accepting share updates.
We're out of time to do this for v1.7.0. I hope to do it for v1.8.0.
I'm interested in prioritizing this ticket because it is (IMHO) a major forward-compatibility feature. But, I haven't really looked at all of the other competing priorities for v1.8.0 and decided that I'm really going to spend my time on this one, so I'm putting it in the "soon" Milestone for now.
Hm, would it be okay to allow people to set an HTTP 301 to a different cap of a different type, such as a read-write cap instead of a read-only cap or a read-only cap instead of a read-write cap?
Our tradition of transitive attenuation of authority suggests that we should forbid this, which means that a client which is following an HTTP 301 redirect should remember whatever the attenuation of the original cap was (i.e. if it was read-only or ??? if it was a verify-only cap) and refuse to use the new cap with authority outside of that.
Replying to zooko:
Allowing redirection of a read-write cap to a read-only cap seems harmless and useful.
(More precisely: as long as we have API slots that can accept either a read-write cap or a read-only cap, we should accept rw-redirecting-to-ro in those slots. There's an argument for having more strictly typed APIs, for which read operations reject write caps, in order to catch inadvertent grants of excess authority; but that's orthogonal to redirection.)
+1 (for forbidding redirection of read-only caps to read-write caps).
This should also apply to verify-only caps in the contexts in which they can be used, e.g.
?t=info
, checker APIs, etc.