W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2022

Re: Draft for Resumable Uploads

From: Julian Reschke <julian.reschke@gmx.de>
Date: Tue, 5 Apr 2022 09:38:15 +0200
Message-ID: <4c1aabee-bc23-6d19-2e5d-8fdf3b3532ad@gmx.de>
To: Eric J Bowman <mellowmutt@zoho.com>
Cc: Guoye Zhang <guoye_zhang@apple.com>, ietf-http-wg <ietf-http-wg@w3.org>
Am 05.04.2022 um 08:28 schrieb Eric J Bowman:
> ---- On Mon, 04 Apr 2022 23:09:32 -0700 *Julian Reschke
> <julian.reschke@gmx.de>* wrote ----
>
>     Am 05.04.2022 um 08:05 schrieb Eric J Bowman:
>      > >
>      > > First, how does it uniquely identify a resumable upload?
>      > >
>      >
>      > A 206 response to a non-range request uniquely, unambiguously, and
>      > elegantly identifies an incomplete resource. Identifying a
>     resource as
>      > both incomplete *and* completeable, introduces tight coupling at the
>      > protocol layer.
>      > ...
>
>     It's an interesting idea; but we would need to modify the core specs
>     for
>     that (right now it's only defined for responses to range requests).
>
>     Best regards, Julian
>
>     -------------------------------------
>
>     Exploring the undefined aspects of HTTP to flesh out the core specs,
>     is preferable to me over adding to or even extending HTTP. Y'all
>     never told me *not* to respond 206 on a non-range request.
>     Implementations just don't care about 206 being undefined for this;
>     they just "fall back to 200". As they should. Nothing breaks.
>
>     -Eric

Hm, no.

If the client gets a 206 for incomplete content and falls back to 2xx
handling, it will assume the content is indeed complete.

Or am I missing something here?

Best regards, Julian
Received on Tuesday, 5 April 2022 07:38:44 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:44:07 UTC