cURL / Mailing Lists / curl-library / Single Mail


Re: Ranged downloads on file:// URLs

From: Daniel Egger <>
Date: Tue, 8 Jan 2008 20:39:13 +0100

On 08.01.2008, at 15:44, Daniel Stenberg wrote:

>> Yes, but the (curl) range syntax is so obscure to me that I haven't
>> thought about the special cases carefully.

> The "-[number]" case isn't that special imho.

It is.

> How else would you specify the last N bytes of a file?

Dunno, not at all maybe? I surely never missed such a feature,
but maybe that's because I'm special...

> And IIRC, that's how HTTP ranges work and is why we support this
> style in the first place...

Nope, to cite rfc2616:

14.16 Content-Range

    The Content-Range entity-header is sent with a partial entity-body
    specify where in the full entity-body the partial body should be
    applied. Range units are defined in section 3.12.

        Content-Range = "Content-Range" ":" content-range-spec

        content-range-spec = byte-content-range-spec
        byte-content-range-spec = bytes-unit SP
                                  byte-range-resp-spec "/"
                                  ( instance-length | "*" )

        byte-range-resp-spec = (first-byte-pos "-" last-byte-pos)
                                       | "*"
        instance-length = 1*DIGIT

    The header SHOULD indicate the total length of the full entity-body,
    unless this length is unknown or difficult to determine. The
    "*" character means that the instance-length is unknown at the time
    when the response was generated.

    Unlike byte-ranges-specifier values (see section 14.35.1), a byte-
    range-resp-spec MUST only specify one range, and MUST contain
    absolute byte positions for both the first and last byte of the

    A byte-content-range-spec with a byte-range-resp-spec whose last-
    byte-pos value is less than its first-byte-pos value, or whose
    instance-length value is less than or equal to its last-byte-pos
    value, is invalid. The recipient of an invalid byte-content-range-
    spec MUST ignore it and any content transferred along with it.

Only fully specified ranged with absolute positions are allowed. curls'
-Y syntax would be relative from the end. Also the Z- notation is not
valid HTTP, but from my reading Z-99999999999 would be valid to get the
rest of an unknown size file, so Z- might be regarded as a shortcut for

Received on 2008-01-08