IReadable.read should document out-of-range errors #2461
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
3 Participants
Notifications
Due Date
No due date set.
Reference: tahoe-lafs/trac-2024-07-25#2461
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
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?
In interfaces.py, document error behaviour when
offset
and/orsize
are outside the bounds of the file.I think the behavior ought to be to return a short result, i.e. return as many bytes as do exist and fall within the requested range, and return the 0-length string if none do. That way clients can issue range read requests without knowing for sure whether the request will start past the end or cross the end, which can allow them to do fewer round trips, maybe, in some cases.
Replying to zooko:
That's a self-consistent design, but it is not the current design (which is for the web-API to truncate the request as necessary to satisfy HTTP semantics). No extra round trips are ever needed, because the file length is known at the time the web-API makes the
read
call. Also the design change you suggest is not needed to fix #2459, the bug that motivated this ticket. I am skeptical about doing anything more than necessary to fix that bug in a point release.I'll update it to express the current behavior: reject out-of-range reads, permit zero-length reads.
The webapi continues to allow arbitrary oversized
Range:
headers, sinceweb/filenode.py
clips these to the filesize before callingread()
. It's just internal callers who must meet the no-overrun requirement (and they can always read the whole file,offset=0 size=None
, without paying attention toget_size()
ahead of time).Fixed in [6252a72]
Reviewed, +1.