Re: [ftpext] Question about draft-bryan-ftp-hash-07

Anthony Bryan <anthonybryan@gmail.com> Fri, 26 November 2010 08:29 UTC

Return-Path: <anthonybryan@gmail.com>
X-Original-To: ftpext@core3.amsl.com
Delivered-To: ftpext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEF5E3A6A7D for <ftpext@core3.amsl.com>; Fri, 26 Nov 2010 00:29:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.735
X-Spam-Level:
X-Spam-Status: No, score=-2.735 tagged_above=-999 required=5 tests=[AWL=-0.136, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1yDn6pQNAkf5 for <ftpext@core3.amsl.com>; Fri, 26 Nov 2010 00:29:25 -0800 (PST)
Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 2A8DF3A6A58 for <ftpext@ietf.org>; Fri, 26 Nov 2010 00:29:25 -0800 (PST)
Received: by ewy8 with SMTP id 8so877147ewy.31 for <ftpext@ietf.org>; Fri, 26 Nov 2010 00:30:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=aoCWtWGaR2vXl5vyxzQl9D/uQ7uGKHKLsmC2LxphKhs=; b=EnuCkKnNRy7S+OQrxc0qgv/g2UWbOPdRSU996X6D2MObEwgTtqICqED25CoccfmFw4 aZkwgjC3eEX+4FzhYItVCmM/Xo6pnzPQ5Fwah+O3f8aA5XxqIqzKwIPgfLkWVMVBV7in 3qi8/euxC3aTkzkiMV+5gRtkOss9MoS1Ksp8E=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=x7WSQ7KAUyuv3SYXoDCLgF/IUmEQo6nSHjFXFBQrNT+BSLwBh7mx9ZnqzdTg2KR7Jh x9TEawu6ML44H3LOY4BHcC9/Y3HZ43eUmu8ASsKJQnbg2pAjTkzQDBgoalMmTvpz4ceu 0Nbip7UXHh56psSD/w1FMgf4TtkkUPbCqm8yM=
MIME-Version: 1.0
Received: by 10.213.22.197 with SMTP id o5mr6051738ebb.89.1290760227383; Fri, 26 Nov 2010 00:30:27 -0800 (PST)
Received: by 10.213.28.2 with HTTP; Fri, 26 Nov 2010 00:30:27 -0800 (PST)
In-Reply-To: <41871DBEA4CB724B93AC2D8CAADADBF41463C770CF@mx.smartsoft.local>
References: <A5FC996C3C37DC4DA5076F1046B5674C3D2B58B3@TK5EX14MBXC127.redmond.corp.microsoft.com> <AANLkTikG8XVKQ7pLq+bcGhAk=UrJiS05vbkib7jQde_Y@mail.gmail.com> <AANLkTi=kP7j1Q4JmWSeG-qsuCwGdWoAAGbujbpCjOERE@mail.gmail.com> <41871DBEA4CB724B93AC2D8CAADADBF41463C770CF@mx.smartsoft.local>
Date: Fri, 26 Nov 2010 03:30:27 -0500
Message-ID: <AANLkTikS+exC6fe+oexLbbLMKmS5rbCeXR64f6AGVzpe@mail.gmail.com>
From: Anthony Bryan <anthonybryan@gmail.com>
To: Mat Berchtold <mb@smartftp.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: "ftpext@ietf.org" <ftpext@ietf.org>, Robert McMurray <robmcm@microsoft.com>, Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
Subject: Re: [ftpext] Question about draft-bryan-ftp-hash-07
X-BeenThere: ftpext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <ftpext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ftpext>, <mailto:ftpext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ftpext>
List-Post: <mailto:ftpext@ietf.org>
List-Help: <mailto:ftpext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ftpext>, <mailto:ftpext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Nov 2010 08:29:27 -0000

great, Mat, thanks a bunch! obviously there isn't a rush, but it will
be useful to have.

following that, (it was on apps-discuss but not mentioned here) we
have client (aria2) and server (FileZilla) implementations for
testing, albeit for the slightly different -02 draft.

aria2 client http://www.ietf.org/mail-archive/web/apps-discuss/current/msg01497.html
FileZilla server
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg01481.html

btw, if you have time Mat, can you reply to the partial file hash
thread (or here)?
I remember you felt strongly about including that feature.

On Fri, Nov 26, 2010 at 3:11 AM, Mat Berchtold <mb@smartftp.com> wrote:
>> the newest HASH draft uses a new code: 556.
> Good idea. I have updated the proftpd mod_digest module to use the same error code as well. I also plan to add support for the HASH command within the next couple of weeks.
>
> Mat
>
> -----Original Message-----
> From: Anthony Bryan [mailto:anthonybryan@gmail.com]
> Sent: Thursday, 04 November, 2010 01:29
> To: Robert McMurray; Mat Berchtold
> Cc: ftpext@ietf.org
> Subject: Re: [ftpext] Question about draft-bryan-ftp-hash-07
>
> On Thu, Sep 16, 2010 at 1:28 AM, Anthony Bryan <anthonybryan@gmail.com> wrote:
>> On Fri, Aug 20, 2010 at 6:01 PM, Robert McMurray <robmcm@microsoft.com> wrote:
>>> With that in mind, I've been thinking through implementation scenarios in the wake of the denial-of-service discussion that took place before IETF 78. More specifically, I've thinking about a scenario where the maximum file size could be configured at the server, so HASH commands could be prevented from stealing too many server resources when larger files are involved. This is purely a server implementation detail that has nothing to do with the draft with the exception of considering which reply code to return.
>>>
>>> Looking at section "3.4. HASH Command Errors" in the draft it would seem that none of the 5yz errors that are listed would apply, but returning a 504 reply might seem to make sense in this scenario. If so, would it be worthwhile to add a statement like the following to the draft?
>>>
>>>   The server-PI SHOULD reply with a 504 reply if the HASH command is
>>>   used on a file that cannot be processed for policy reasons. (For
>>>   example, the file size exceeds the server's hashing policy.)
>>>
>>> Or would a 4yz reply be better since this is a configurable option at the server? Perhaps a 452 reply?
>>
>> revisiting this, Mathias Berchtold is an implementer (ProFTPD module
>> mod_digest, http://www.smartftp.com/oss/proftpd/mod_digest.html ) of
>> the alternate non-standard commands (XCRC, XMD5, XSHA1, SHA256) that
>> HASH is trying to standardize.
>>
>> mod_digest uses 550 reply code for the case that Robert mentioned of a
>> file not being allowed to be hashed because of a policy.
>>
>> "The DigestMaxSize directive configures the maximum number of bytes a
>> single hash command is allowed to read from a file. If the number of
>> bytes to be read from the file is greater than the configured limit
>> the server will return an error. If no DigestMaxSize directive is
>> configured, then there is no limit. It is stronly recommended to set
>> an upper limit."
>>
>> R_550, "%s: Length (%zu) greater than " CONFIG_DIGEST_MAXSIZE " (%zu)
>> config value", cmd->arg, lLength, lMaxSize);
>>
>> Mathias, any suggestions as an implementer?
>>
>> we use 550 already for file not found.
>>
>>      550 Requested action not taken.
>>          File unavailable (e.g., file not found, no access).
>>
>> we don't seem to have a specific reply code that fits this case currently.
>> should we mint a new reply code (55z since it's permanent & deals with
>> file system) or use another existing code that isn't an exact fit?
>
> the newest HASH draft uses a new code: 556.
>
> http://tools.ietf.org/html/draft-bryan-ftp-hash
>
> comments? here's the new text.
>
>           The server-PI SHOULD reply with a 556 reply if the HASH command is
>           used on a file that cannot be processed for policy reasons.  (For
>           example, if the file size exceeds the server's hashing policy.)
>
> later:
>
>           Server operators might wish to allow the HASH command but restrict
>           its use to certain files, for example, if the file size exceeds the
>           server's hashing policy.  A client MUST be able to understand that
>           refusal to process HASH commands may be permanent (if indicated by a
>           556 response) and will not be honoured later.
>
> --
> (( Anthony Bryan ... Metalink [ http://www.metalinker.org ]
>   )) Easier, More Reliable, Self Healing Downloads
>



-- 
(( Anthony Bryan ... Metalink [ http://www.metalinker.org ]
  )) Easier, More Reliable, Self Healing Downloads