Re: Atomic patches and network interruptions

Marius Kleidl <marius@transloadit.com> Tue, 27 February 2024 22:51 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=ietf.org@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 93B06C151088 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 27 Feb 2024 14:51:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.856
X-Spam-Level:
X-Spam-Status: No, score=-2.856 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=w3.org header.b="bHxxoaRj"; dkim=pass (2048-bit key) header.d=w3.org header.b="nNg0Gk0g"; dkim=pass (1024-bit key) header.d=transloadit.com header.b="XE4jGyfB"
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id envlN59CCx1q for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 27 Feb 2024 14:51:00 -0800 (PST)
Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADD57C14CF17 for <httpbisa-archive-bis2Juki@ietf.org>; Tue, 27 Feb 2024 14:51:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=w3.org; s=s1; h=Subject:Content-Type:Cc:To:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To; bh=i4eCYvCrAi9wsBC86FerV6p9PW93ZFelRKYCBmNL4G0=; b=bHxxoaRjfqkqBeu222obkoYAAl bb1YgfUxTCwPCtp21NgF78pmJp0fa2dWqjHtXKPqiq8g8PlzANsU727FPsXlX+Cn64RRmDHWcFx/X AHC1Pk+p2DK6UquiqRHx32xvAknoaseoDBbXpojoj3v5qDTUvC0pgPGIgwNexI0bAntcPMPlTOIcc M7Jq7ucdCWQ5/lYF4QDJw9vaGCe+oD6SOt0EetySZ+qpD6IPHAjfvd+i6ZWYJzlSQQ1HVtzOiOBCg DJTKwrorT9f3t1SZkaDql83UgyrhfKkXvgkTqxCib1J44rUAsdmBeP0ugABJ7vB+yePkdli39Ga5/ XqNxWZUw==;
Received: from lists by lyra.w3.org with local (Exim 4.94.2) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1rf6Gp-003oHm-6h for ietf-http-wg-dist@listhub.w3.org; Tue, 27 Feb 2024 22:49:55 +0000
Resent-Date: Tue, 27 Feb 2024 22:49:55 +0000
Resent-Message-Id: <E1rf6Gp-003oHm-6h@lyra.w3.org>
Received: from puck.w3.org ([34.196.82.207]) by lyra.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <marius@transloadit.com>) id 1rf6Gm-003oGf-M0 for ietf-http-wg@listhub.w3.org; Tue, 27 Feb 2024 22:49:52 +0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=w3.org; s=s1; h=Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To; bh=i4eCYvCrAi9wsBC86FerV6p9PW93ZFelRKYCBmNL4G0=; t=1709074192; x=1709938192; b=nNg0Gk0g55DUj+hH3XOczgeXT0y5Ap8hcusfQGVXf22UMTcXaSXmaI8go4M82t5pJRlDFcruaSI HwIhd/ZEYIlfFOcKmSdJvtYZs01j/ms5sFoHfhvjbzvJIzu1AQ3az6q2K0B1htoLkntGpZgMX2rwO tLPVwE1U/F/jmaVHIjFkfFaYSA7v3FOBll01/2LP4Wf1c9RzCA13LokbUa7xn7lF0oNgwBz2bjhDo QhZLuPyLWHbTpsgzIjCu8ACROEs0fTw47mYz7TM0DOVyVgM98uJDTR7F/1u9Kj/iwLnKSms1/4uHU N/XzYSLYo1c2DOBCWalhLUzIAPMlMqZWIttQ==;
Received-SPF: pass (puck.w3.org: domain of transloadit.com designates 2a00:1450:4864:20::42a as permitted sender) client-ip=2a00:1450:4864:20::42a; envelope-from=marius@transloadit.com; helo=mail-wr1-x42a.google.com;
Received: from mail-wr1-x42a.google.com ([2a00:1450:4864:20::42a]) by puck.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from <marius@transloadit.com>) id 1rf6Gl-002buK-3C for ietf-http-wg@w3.org; Tue, 27 Feb 2024 22:49:52 +0000
Received: by mail-wr1-x42a.google.com with SMTP id ffacd0b85a97d-33d32f74833so2652426f8f.3 for <ietf-http-wg@w3.org>; Tue, 27 Feb 2024 14:49:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=transloadit.com; s=google; t=1709074188; x=1709678988; darn=w3.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=i4eCYvCrAi9wsBC86FerV6p9PW93ZFelRKYCBmNL4G0=; b=XE4jGyfB0D/N3o2+pSWqZXFua+44l1P+WlleAdMTdmqHMiHgXmClf8QBrVn8kE3Ezh 7bPzlu3MVBtUl6SZqaKi7yTjkp+ne2VjXRgb5gvUNljgGSgLP4f6DIBOKfeiDZsWg+3C GDZcyPXgJpnLJjcR/IWuABcJt5em4j5ZMqANE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709074188; x=1709678988; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=i4eCYvCrAi9wsBC86FerV6p9PW93ZFelRKYCBmNL4G0=; b=vm2MzvtjfMXREELxblLeNcFkcTsfLzt1SGHt3Ffh44zaaaakNdQ5Fynt0FjN8PsKxD W5065CqfHV5sXkbuQip+uQ6ZeT063hIVGFDvQ7YX4f7WN/Ztf8kmvtu2FofF4LQe17ZF S3Yl0Wv3+z5I2XnaTI93OFs90XkIBM6kPntilIi4x89G+K32N0xrysWF7XMgIFVwesCl P67l+97sL6hbmi9Fv7s9DRyjTDx1c95YzUqnPAWIxQLSSPUS3CfuR2f5o+lXqDmvvlNb YGba6j3AT6H3ZhsmAx38FoirtiYFuDm7zLBSG7tutAsuJt4tHjdzENyH7P/a9Z3A7RJA SonA==
X-Gm-Message-State: AOJu0YzVCxRCNrXGaH7mdzPkmnBMdwlfkD3LcfIKJPY1HUwQm3W7+f1I PDdbKOqei0eqIc+leqfwEyk/zVp2DJ8mnLK/Lp4XZkTdCcbCbvPCoOVgrdWNxOHcAlfcBe4J4xC nDUqgxIp6x9LtAv6IYw5F+qAtI8bAMjv8t4u/sGC+fhw/VjPzpvLyRiFN
X-Google-Smtp-Source: AGHT+IFL+5Of4zzQMriS2HwSTDN9YNo6zIzXX4V1mdrZhyIbmjQ30cYS/3R0JE/3lvaB5RlLnu2PDD/c6eCzaEkDUb8=
X-Received: by 2002:a5d:4384:0:b0:33d:24af:9153 with SMTP id i4-20020a5d4384000000b0033d24af9153mr6779087wrq.20.1709074187728; Tue, 27 Feb 2024 14:49:47 -0800 (PST)
MIME-Version: 1.0
References: <CANY19NtcgJJhArwufG+bH0EDSy6cSw4hSaZn_J9AykJv_5pJVA@mail.gmail.com> <Zd0FbZzskpWX3bP0@xps13>
In-Reply-To: <Zd0FbZzskpWX3bP0@xps13>
From: Marius Kleidl <marius@transloadit.com>
Date: Tue, 27 Feb 2024 23:49:36 +0100
Message-ID: <CANY19NsOQBWO75LVycT+T1rbaLNWPjj1ugK5+uV9i3U9W8g_dA@mail.gmail.com>
To: Glenn Strauss <gs-lists-ietf-http-wg@gluelogic.com>
Cc: HTTP <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="000000000000dad0a2061264d757"
X-W3C-Hub-DKIM-Status: validation passed: (address=marius@transloadit.com domain=transloadit.com), signature is good
X-W3C-Hub-Spam-Status: No, score=-4.1
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, DMARC_PASS=-0.001, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: puck.w3.org 1rf6Gl-002buK-3C ceb53bf9aaf62cb92ca0ce842b314b12
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Atomic patches and network interruptions
Archived-At: <https://www.w3.org/mid/CANY19NsOQBWO75LVycT+T1rbaLNWPjj1ugK5+uV9i3U9W8g_dA@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/51847
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: <https://www.w3.org/email/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

Hello Glenn,

thank you for your comments!

> The server *application* handling the request could buffer and store the
  (partial) request body fragments, allowing for resumable uploads, and
  then apply the changes only once the entire patch document is received

That's an interesting idea. Would the client in such a scenario be able to
query the state of the buffered body fragments through a request? Or would
this not be easily possible because the fragments collection is not a
resource on its own and thus cannot be the target of a request?

Best regards
Marius Kleidl


On Mon, Feb 26, 2024 at 10:41 PM Glenn Strauss <
gs-lists-ietf-http-wg@gluelogic.com> wrote:

> On Mon, Feb 26, 2024 at 08:30:38PM +0100, Marius Kleidl wrote:
> > Dear working group,
> >
> > RFC 5789, which defines the PATCH method, places this requirement:
> >
> > The PATCH method requests that a set of changes described in the request
> > > entity be applied to the resource identified by the Request-URI. The
> set of
> > > changes is represented in a format called a "patch document"
> identified by
> > > a media type.
> > > [...]
> > > The server MUST apply the entire set of changes atomically and never
> > > provide (e.g., in response to a GET during this operation) a partially
> > > modified representation. If the entire patch document cannot be
> > > successfully applied, then the server MUST NOT apply any of the
> changes.
>
> This is very direct and very explicit.  "atomically" means exactly that.
>
> > > If the entire patch document cannot be
> > > successfully applied, then the server MUST NOT apply any of the
> changes.
>
> The server MUST NOT apply an incomplete patch document.  No exceptions.
>
> Among your options:
> The client can send smaller patch documents if changes are independent.
>   (recommended)
> The server *application* handling the request could buffer and store the
>   (partial) request body fragments, allowing for resumable uploads, and
>   then apply the changes only once the entire patch document is received
>
> > Or could this be allowed if the
> > corresponding media types explicitly allows applying partial content?
>
> More questionable: a PATCH format might be defined/extended with a new
>   media-type defining a format that consists of multiple patch documents
>   which may be applied independently.  The client would need some way(s)
>   to query/validate which patch documents were applied.  Again, per the
>   RFC, each patch document must be applied atomically; never partially.
>
> Cheers, Glenn
>