tahoe-lafs/trac-2024-07-25

improve HTTP/1.1 byterange handling #989

New issue

Closed

opened 2010-03-10 03:37:57 +00:00 by davidsarah · 8 comments

davidsarah commented

2010-03-10 03:37:57 +00:00

Owner

The attached patch by Jeremy Fitzhardinge improves byterange handling as follows.

Fix parsing of a Range: header to support:

multiple ranges (parsed, but not returned)
suffix byte ranges ("-2139")
correct handling of incorrectly formatted range headers (correct behaviour is to ignore the header and return the full file)
return appropriate error for ranges outside the file

Multiple ranges are parsed, but only the first range is returned. Returning multiple ranges requires using the multipart/byterange content type.

The attached patch by Jeremy Fitzhardinge improves byterange handling as follows. Fix parsing of a Range: header to support: - multiple ranges (parsed, but not returned) - suffix byte ranges ("-2139") - correct handling of incorrectly formatted range headers (correct behaviour is to ignore the header and return the full file) - return appropriate error for ranges outside the file Multiple ranges are parsed, but only the first range is returned. Returning multiple ranges requires using the multipart/byterange content type.

tahoe-lafs added the

labels 2010-03-10 03:37:57 +00:00

tahoe-lafs added this to the 1.7.0 milestone 2010-03-10 03:37:57 +00:00

davidsarah commented

2010-03-10 03:39:55 +00:00

Author

Owner

Attachment improve-http_1_1-byterange-handling.dpatch.txt (10362 bytes) added

Improve HTTP/1.1 byterange handling

**Attachment** improve-http_1_1-byterange-handling.dpatch.txt (10362 bytes) added Improve HTTP/1.1 byterange handling

improve-http_1_1-byterange-handling.dpatch.txt

10 KiB

zooko commented

2010-05-08 20:11:39 +00:00

Author

Owner

return appropriate error for ranges outside the file
Is it disallowed by the standard to go ahead and return results in a case like this? For example, if the user requests bytes 99 through 1000 and the file is only 200 bytes long, can we return bytes 99 through 200?

* return appropriate error for ranges outside the file Is it disallowed by the standard to go ahead and return results in a case like this? For example, if the user requests bytes 99 through 1000 and the file is only 200 bytes long, can we return bytes 99 through 200?

davidsarah commented

2010-05-08 23:03:22 +00:00

Author

Owner

Replying to zooko:

return appropriate error for ranges outside the file
Is it disallowed by the standard to go ahead and return results in a case like this? For example, if the user requests bytes 99 through 1000 and the file is only 200 bytes long, can we return bytes 99 through 200?

RFC 2616 section 10.4.17:

   A server SHOULD return a response with this status code if a request
   included a Range request-header field (section 14.35), and none of
   the range-specifier values in this field overlap the current extent
   of the selected resource, and the request did not include an If-Range
   request-header field. (For byte-ranges, this means that the first-
   byte-pos of all of the byte-range-spec values were greater than the
   current length of the selected resource.)

In other words, yes, we should return bytes 99 through 200 in your example. We should only respond with a 416 error if all byte requested ranges start after the end of the resource.

Replying to [zooko](/tahoe-lafs/trac-2024-07-25/issues/989#issuecomment-117833): > * return appropriate error for ranges outside the file > Is it disallowed by the standard to go ahead and return results in a case like this? For example, if the user requests bytes 99 through 1000 and the file is only 200 bytes long, can we return bytes 99 through 200? [RFC 2616 section 10.4.17](http://tools.ietf.org/html/rfc2616#section-10.4.17): ``` A server SHOULD return a response with this status code if a request included a Range request-header field (section 14.35), and none of the range-specifier values in this field overlap the current extent of the selected resource, and the request did not include an If-Range request-header field. (For byte-ranges, this means that the first- byte-pos of all of the byte-range-spec values were greater than the current length of the selected resource.) ``` In other words, yes, we should return bytes 99 through 200 in your example. We should only respond with a 416 error if all byte requested ranges start after the end of the resource.

davidsarah commented

2010-05-08 23:06:32 +00:00

Author

Owner

Replying to [davidsarah]comment:2:

In other words, yes, we should return bytes 99 through 200 in your example. We should only respond with a 416 error if all byte requested ranges start after the end of the resource.

It looks to me as though the current patch gets this right.

Replying to [davidsarah]comment:2: > In other words, yes, we should return bytes 99 through 200 in your example. We should only respond with a 416 error if all byte requested ranges start after the end of the resource. It looks to me as though the current patch gets this right.

davidsarah commented

2010-05-09 01:02:02 +00:00

Author

Owner

The default set of whitespace characters stripped by .strip() is undocumented, so use an explicit argument at web/filenode.py line 145, i.e. .strip(' \t') assuming header lines have already been unfolded.

Otherwise looks good. Jeremy: Do you intend this to be applied for 1.7, or are you going to implement multipart/byterange?

The default set of whitespace characters stripped by `.strip()` is undocumented, so [use an explicit argument](http://docs.python.org/library/stdtypes.html#str.strip) at web/filenode.py line 145, i.e. `.strip(' \t')` assuming header lines have already been unfolded. Otherwise looks good. Jeremy: Do you intend this to be applied for 1.7, or are you going to implement multipart/byterange?

davidsarah commented

2010-06-03 04:21:22 +00:00

Author

Owner

Assuming that this should be applied for 1.7.

davidsarah commented

2010-06-08 04:59:33 +00:00

Author

Owner

Applied in changeset:63b28d707b12202f and changeset:a67e745b26130e78. However, I forgot to address comment:117836. Jeremy, is it correct to only strip space and tab?

Applied in changeset:63b28d707b12202f and changeset:a67e745b26130e78. However, I forgot to address [comment:117836](/tahoe-lafs/trac-2024-07-25/issues/989#issuecomment-117836). Jeremy, is it correct to only strip space and tab?

zooko commented

2010-06-18 04:55:44 +00:00

Author

Owner

Okay, I'm still waiting for jsgf to answer the question, but the patch is in and the release is going out, so marking this as fixed.

tahoe-lafs added the

fixed

label 2010-06-18 04:55:44 +00:00

zooko closed this issue

2010-06-18 04:55:44 +00:00