#537 closed defect (fixed)

Web-API does not correctly handle partial Range header

Reported by: francois Owned by:
Priority: minor Milestone: 1.3.0
Component: code-frontend-web Version: 1.2.0
Keywords: Cc: francois@…
Launchpad Bug:


An HTTP request containing a partial range header raise the following exception even though it must be accepted according to RFC2616 section "14.35.1 Byte Ranges".

2008-11-18 14:45:23+0100 [HTTPChannel,4,] Unhandled Error
	Traceback (most recent call last):
	  File "/usr/lib/python2.5/site-packages/twisted/internet/defer.py", line 186, in addCallbacks
	  File "/usr/lib/python2.5/site-packages/twisted/internet/defer.py", line 328, in _runCallbacks
	    self.result = callback(self.result, *args, **kw)
	  File "/home/francois/dev/tahoe/support/lib/python2.5/site-packages/Nevow-0.9.31-py2.5.egg/nevow/appserver.py", line 188, in _cbFinishRender
	    return self.gotPageContext(pageContext)
	  File "/home/francois/dev/tahoe/support/lib/python2.5/site-packages/Nevow-0.9.31-py2.5.egg/nevow/appserver.py", line 163, in gotPageContext
	    pageContext.tag.renderHTTP, pageContext
	--- <exception caught here> ---
	  File "/usr/lib/python2.5/site-packages/twisted/internet/defer.py", line 106, in maybeDeferred
	    result = f(*args, **kw)
	  File "/home/francois/dev/tahoe/src/allmydata/web/filenode.py", line 381, in renderHTTP
	    (str(offset), str(offset+size-1), str(filesize)))
	exceptions.TypeError: unsupported operand type(s) for +: 'int' and 'NoneType'

This request was generated by mplayer accessing an avi file stored in tahoe.

GET /file/URI%3ACHK%3foo%3bar/@@named=/test.avi HTTP/1.0

Host: localhost:8123
User-Agent: MPlayer/2:1.0~rc2-0ubuntu17-francois0
Icy-MetaData: 1
Range: bytes=2048-
Connection: close

Attachments (1)

fix-http-range.patch (88.3 KB) - added by francois at 2008-11-18T14:00:05Z.
Fix this bug and add associated tests

Download all attachments as: .zip

Change History (8)

Changed at 2008-11-18T14:00:05Z by francois

Fix this bug and add associated tests

comment:1 Changed at 2008-11-18T17:52:11Z by zooko

Thank you, francois!

I will apply this patch and test it and commit it as soon as possible, but first I have to figure out why my machine (yukyuk hardy) fails the test_unicode_filename test with your previous contribution.

comment:2 Changed at 2008-12-06T05:08:17Z by warner

  • Milestone changed from undecided to 1.3.0
  • Resolution set to fixed
  • Status changed from new to closed

Applied, in db7ad6da128609d2. Excellent patch! Thanks!

comment:3 Changed at 2008-12-07T22:12:28Z by warner

oh, do you know if we must also handle something like "-1000", in which the start of the range is implicitly "0" or "1" or whatever the Range header uses?

Tahoe currently throws an exception if you do something like "curl -r-1000 FILEURL".

comment:4 Changed at 2008-12-08T09:57:14Z by francois

From my reading of RFC2616, the first-byte-pos is required. However, the recommended action in case of invalid Range header is to ignore the header altogether instead of raising an exception.

Excerpt from section "14.35.1 Byte Ranges":

If the last-byte-pos value is present, it MUST be greater than or
equal to the first-byte-pos in that byte-range-spec, or the byte-
range-spec is syntactically invalid. The recipient of a byte-range-
set that includes one or more syntactically invalid byte-range-spec
values MUST ignore the header field that includes that byte-range-

comment:5 follow-up: Changed at 2008-12-08T21:07:17Z by warner

Oh, joy, actually it looks like "-1000" means the *last* 1000 bytes of the file. From the last section of RFC2616.14.35.1:

Examples of byte-ranges-specifier values (assuming an entity-body of length 10000):

      - The first 500 bytes (byte offsets 0-499, inclusive):  bytes=0-

      - The second 500 bytes (byte offsets 500-999, inclusive):

      - The final 500 bytes (byte offsets 9500-9999, inclusive):

      - Or bytes=9500-

      - The first and last bytes only (bytes 0 and 9999):  bytes=0-0,-1

      - Several legal but not canonical specifications of the second 500
        bytes (byte offsets 500-999, inclusive):

Sigh. So, I think I'll just leave this the way it is until someone complains.

comment:6 in reply to: ↑ 5 Changed at 2008-12-09T11:20:14Z by francois

Replying to warner:

Oh, joy, actually it looks like "-1000" means the *last* 1000 bytes of the file. From the last section of RFC2616.14.35.1:

Oops, my bad, I read the RFC too quickly.

Sigh. So, I think I'll just leave this the way it is until someone complains.

Agreed, then will probably be the right time to add support for multiple range specifiers.

comment:7 Changed at 2010-04-23T23:50:23Z by jsgf

BTW, I managed to overlook this ticket and filed #989 to address this same concern. I also attached a patch which handles suffix byte ranges ("-1000").

Note: See TracTickets for help on using tickets.