Changes between Initial Version and Version 1 of Ticket #2461, comment 3


Ignore:
Timestamp:
2015-07-25T00:30:43Z (9 years ago)
Author:
daira
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #2461, comment 3

    initial v1  
    22> 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.
    33
    4 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). 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.
     4That'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.