- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Tue, 5 Apr 2022 09:38:15 +0200
- 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