Re: Resumable Uploads

Daniel Stenberg <daniel@haxx.se> Sat, 20 April 2013 21:21 UTC

Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A3CB21F8AE8 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 20 Apr 2013 14:21:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yWXwiufzbQDf for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 20 Apr 2013 14:21:41 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 4F2B421F86D3 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sat, 20 Apr 2013 14:21:41 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UTfDj-0007xV-6y for ietf-http-wg-dist@listhub.w3.org; Sat, 20 Apr 2013 21:21:19 +0000
Resent-Date: Sat, 20 Apr 2013 21:21:19 +0000
Resent-Message-Id: <E1UTfDj-0007xV-6y@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <daniel@haxx.se>) id 1UTfDg-0007wm-0u for ietf-http-wg@listhub.w3.org; Sat, 20 Apr 2013 21:21:16 +0000
Received: from giant.haxx.se ([80.67.6.50]) by maggie.w3.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <daniel@haxx.se>) id 1UTfDd-0007Gj-95 for ietf-http-wg@w3.org; Sat, 20 Apr 2013 21:21:15 +0000
Received: from giant.haxx.se (localhost.localdomain [127.0.0.1]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id r3KLKamH018494 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 20 Apr 2013 23:20:36 +0200
Received: from localhost (dast@localhost) by giant.haxx.se (8.14.4/8.14.4/Submit) with ESMTP id r3KLKZYU018490; Sat, 20 Apr 2013 23:20:35 +0200
X-Authentication-Warning: giant.haxx.se: dast owned process doing -bs
Date: Sat, 20 Apr 2013 23:20:35 +0200
From: Daniel Stenberg <daniel@haxx.se>
X-X-Sender: dast@giant.haxx.se
To: Yoav Nir <ynir@checkpoint.com>
cc: Felix Geisendörfer <felix@transloadit.com>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
In-Reply-To: <2FD45C0A-1A7C-483B-B8E4-5F300B3EDA66@checkpoint.com>
Message-ID: <alpine.DEB.2.00.1304202313390.20613@tvnag.unkk.fr>
References: <CADZbJ9dYFGyrceh03M3B0KdKto7160Dis_geh9um0BhVe1re0g@mail.gmail.com> <EA846138-6537-4709-AC44-149873716E29@mnot.net> <CADZbJ9f4wtaFQEsM_wQn-GaTz+fTKZNyfQk6hXG5OL=Lpkhpcw@mail.gmail.com> <2FD45C0A-1A7C-483B-B8E4-5F300B3EDA66@checkpoint.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
X-fromdanielhimself: yes
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format="flowed"; charset="US-ASCII"
Received-SPF: pass client-ip=80.67.6.50; envelope-from=daniel@haxx.se; helo=giant.haxx.se
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.766, RP_MATCHES_RCVD=-0.702, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1UTfDd-0007Gj-95 b2d28b4ab0172680789f8c8504f110d8
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Resumable Uploads
Archived-At: <http://www.w3.org/mid/alpine.DEB.2.00.1304202313390.20613@tvnag.unkk.fr>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17436
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

On Sat, 20 Apr 2013, Yoav Nir wrote:

> How does the server know when the whole thing has been uploaded?  Wouldn't 
> we need some kind of "total-length" header, perhaps in the initial PUT?
>
> Or are we assuming that the initial PUT is trying to upload everything, and 
> only failure leads to sending the PATCH?

The initial upload could still send "everything" that is everything for that 
particular operation at that time, and then you'd set the expected size of the 
body like always with Content-Length: (or use chunked-encoding or ...).

If you then want to append data to the remote resource, which very well could 
happen without a failure anywhere. Let's for example imagine the case where 
host A just wants to append data to a logfile on host B. It could then append 
a chunk of data every now and then.

I agree with Fredrik's statement that a simple PUT + offset header would be 
easiest for a client (and possibly server too), but I just previously quoted 
the reasoning in the spec as to why it currently doesn't think that is a good 
idea. It would be more productive if we would instead counter that argument or 
present an alternative way.

-- 

  / daniel.haxx.se