Re: [ftpext] File Transfer Protocol RANG Command for Byte Ranges

Richard Koenning <> Mon, 20 December 2010 15:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DCF5D3A6A14 for <>; Mon, 20 Dec 2010 07:35:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ATTS37l8u-Mx for <>; Mon, 20 Dec 2010 07:35:46 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 9264F3A66B4 for <>; Mon, 20 Dec 2010 07:35:46 -0800 (PST)
DomainKey-Signature: s=s1536a;; c=nofws; q=dns; h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV: Received:Message-ID:Date:From:Reply-To:Organization: User-Agent:X-Accept-Language:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type: Content-Transfer-Encoding; b=VBCcl/YOk4V+3l9H9zY/37Tj3IKVu9bCsSY+2HTt4JAdCH/dzyM375bE MxMfqHYXZkt0nwB0Kjk9isdAB9orECOYgS1fDe8pN9/gp8mG2CnR3BJAu dvBsqlCBc4NV5pH5n6cd1bYa11oijA2Bj7QTUmT0UDarTO/jTGCaE01vt HsF8xBSwlRvXuEuTdklh3ZFAoL0irWi/fUMEaeiNRUGUinBtEG46ogL1Z ClPQhA0VGYFTwM916rf/JACWVzZqQ;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=s1536b; t=1292859461; x=1324395461; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; z=Message-ID:=20<>|Date:=20 Mon,=2020=20Dec=202010=2016:37:37=20+0100|From:=20Richard =20Koenning=20<>|Reply-To:|MIME-Version:=201.0 |To:=20""=20<>|CC:=20Daniel =20Stenberg=20<>|Subject:=20Re:=20[ftpext] =20File=20Transfer=20Protocol=20RANG=20Command=20for=20By te=20Ranges|References:=20<alpine.DEB.2.00.1012200851550.>|In-Reply-To:=20<alpine.DEB.2.00.10122>|Content-Transfer-Encoding: =20quoted-printable; bh=LC/u1+NXupWmTovAHNs1GEBkepRQ0ltwXok22B5+aJE=; b=T6EugPsmlwPI7XFGr1ZcgAXNoCK1YtrdQ4mHbJV+iyWbGcTJsW5ylQ/e hdH8r41YMQG1uNSohhXeVjmLXC2dTiDokzVhuj5x0tcnrTBwaQhJ2o3N7 2PlWtLBICKgWjnRrEt2cdadJNFUqxH+YVMmIFLiEc9c8O7UYojUBrUGfe BgdOsPYa6q7azuvjfR8TCq8Sxdl3gmJ+VKmYTSylyjFqOmOQbYFmhkMzJ CfiY+IKN6yDWLA04l+PdGqShslr9T;
X-SBRSScore: None
X-IronPort-AV: E=Sophos;i="4.60,202,1291590000"; d="scan'208";a="63861852"
Received: from ([]) by with ESMTP; 20 Dec 2010 16:37:38 +0100
X-IronPort-AV: E=Sophos;i="4.60,202,1291590000"; d="scan'208";a="105821571"
Received: from (HELO []) ([]) by with ESMTP; 20 Dec 2010 16:37:38 +0100
Message-ID: <>
Date: Mon, 20 Dec 2010 16:37:37 +0100
From: Richard Koenning <>
Organization: Fujitsu Technology Solutions GmbH
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: de, de-nds, en, en-US, it
MIME-Version: 1.0
To: "" <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Cc: Daniel Stenberg <>
Subject: Re: [ftpext] File Transfer Protocol RANG Command for Byte Ranges
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 20 Dec 2010 15:35:48 -0000


Daniel Stenberg wrote:

> Based on our previous discussions in the "End byte of transfer in FTP" thread 
> on this list, we[1] have jotted down a draft for how a new "RANG" command for 
> FTP could work:
> As we see existing use-cases for this feature, we think it would be great to 
> get it supported using regular means instead of the "hacks" currently in use 
> in FTP clients.

iirc some FTP server implementations support the SIZE/REST commands only 
for TYPE I, because supporting it for TYPE A or E would require to read 
the file completely before giving an answer, which would make the server 
prone to DoS attacks. These implementations will probably confine the 
RANG command to TYPE I too.
The description of error code 551 gives me the impression that the RANG 
command is intended only for TYPE I, but from section 3 i got the 
impression that in principle all representation types shall be 
supported. If the latter is true, but implementations are allowed to 
support e.g. only TYPE I, in my opinion there should be an error code 
for indication of such a partial support besides the all-or-nothing 500/552.
Best regards,
Richard Könning
Dr. Richard W. Könning
Fujitsu Technology Solutions GmbH