Re: Using conditional requests with 100 Continue

Austin William Wright <aaa@bzfx.net> Wed, 23 October 2019 00:38 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@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 1D40212022D for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 22 Oct 2019 17:38:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.75
X-Spam-Level:
X-Spam-Status: No, score=-2.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bzfx.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QNDGbJNMJv3Y for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 22 Oct 2019 17:38:36 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [IPv6:2603:400a:ffff:804:801e:34:0:38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA62512021C for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 22 Oct 2019 17:38:35 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1iN4dV-0004hI-Np for ietf-http-wg-dist@listhub.w3.org; Wed, 23 Oct 2019 00:36:25 +0000
Resent-Date: Wed, 23 Oct 2019 00:36:25 +0000
Resent-Message-Id: <E1iN4dV-0004hI-Np@frink.w3.org>
Received: from mimas.w3.org ([2603:400a:ffff:804:801e:34:0:4f]) by frink.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <aaa@bzfx.net>) id 1iN4dU-0004gX-Dk for ietf-http-wg@listhub.w3.org; Wed, 23 Oct 2019 00:36:24 +0000
Received: from mail-pf1-x430.google.com ([2607:f8b0:4864:20::430]) by mimas.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <aaa@bzfx.net>) id 1iN4dS-0007z2-5I for ietf-http-wg@w3.org; Wed, 23 Oct 2019 00:36:24 +0000
Received: by mail-pf1-x430.google.com with SMTP id b4so2808302pfr.12 for <ietf-http-wg@w3.org>; Tue, 22 Oct 2019 17:36:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bzfx.net; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=OM7GdB9Sy8d2JSkrtcVaV6mLof8JZvwgz9IhKr3B0D8=; b=KRD+RIFDQ51zaf5wC0y3GZe5ZgQJWtCC8cysYzqhIm1fbt2UuUigAlQuXcFWlylkzs 0D8nsSp09quzDoCOI9CNWVZgZADNlQsNYmyJAyZcV8kPLVhxpCTn6j8fhbQMaDzoQVLR nOHSYhX0oiCazJ4CxzQRMVVH3RisbICNCBtaE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=OM7GdB9Sy8d2JSkrtcVaV6mLof8JZvwgz9IhKr3B0D8=; b=RB+JSRzuQaHJOBRZOlhq5Ae6VUxbYMB+uyN/Gz2ro2YS/zj9rGH+2ZAVIgN8bSixfm 5xTFaEU4TQFS34sdaQ5o4YeOqRvl+qT+j9xrXA2Gm40da/9eIB2/5EsJJFD27Djstdnq RF+0kDC1HQmt81ds8LWOpYu6A5e4tqpHrr71Oit6Hx43ihEwV9W3cuOrRWavWVhXhzwn qIAV7GxI5Cxyv5ryp/HZpsVHhKgdnm6nMbdEp1Ls0friKPRpkHCtbVMwGnJDhEqWdaOc Ap3zax5OKZATL7zUWqI//loCCOXba5PRGLZjW4ejkGZsLjCXx+ipI9BKviIeC1uX/s0U qz5g==
X-Gm-Message-State: APjAAAX2N6OsNJovczXYWZmH+HqkscyKkxIKIuHdCOCpU20zDjOF6p8s CIc1pz9YiMgtTXdO0rWgBYiOrjfscfE=
X-Google-Smtp-Source: APXvYqxBuZDzv5xCzy6R0hpc4Go1mZ8NPyAOwMaQFVN4uF+26DyfEMMwjKLLHxV/Wm/4kVN/Oim5uA==
X-Received: by 2002:a17:90a:b285:: with SMTP id c5mr7941697pjr.123.1571790980025; Tue, 22 Oct 2019 17:36:20 -0700 (PDT)
Received: from [192.168.0.13] (71-223-64-67.phnx.qwest.net. [71.223.64.67]) by smtp.gmail.com with ESMTPSA id n15sm366128pfq.146.2019.10.22.17.36.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 22 Oct 2019 17:36:19 -0700 (PDT)
From: Austin William Wright <aaa@bzfx.net>
Message-Id: <67290D85-1515-4EF8-A246-587314BAF0C9@bzfx.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_B793F7DC-AA6E-4BA4-A94B-FDBBF1B56C0B"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3594.4.19\))
Date: Tue, 22 Oct 2019 17:36:18 -0700
In-Reply-To: <F0820CD0-82A7-464D-97C1-6EB0281FFE7F@gbiv.com>
Cc: ietf-http-wg@w3.org
To: "Roy T. Fielding" <fielding@gbiv.com>
References: <4D2F8EF3-8732-40DB-B316-0F278E1AEB8F@bzfx.net> <F0820CD0-82A7-464D-97C1-6EB0281FFE7F@gbiv.com>
X-Mailer: Apple Mail (2.3594.4.19)
Received-SPF: pass client-ip=2607:f8b0:4864:20::430; envelope-from=aaa@bzfx.net; helo=mail-pf1-x430.google.com
X-W3C-Hub-Spam-Status: No, score=-6.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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1iN4dS-0007z2-5I b2ee4ab3722425e4d70aedaa1219dd7b
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Using conditional requests with 100 Continue
Archived-At: <https://www.w3.org/mid/67290D85-1515-4EF8-A246-587314BAF0C9@bzfx.net>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37070
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/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

Opened #261: https://github.com/httpwg/http-core/issues/261 <https://github.com/httpwg/http-core/issues/261>

Thanks Roy!

Austin.

> On Oct 22, 2019, at 17:25, Roy T. Fielding <fielding@gbiv.com>; wrote:
> 
>> On Oct 21, 2019, at 3:41 PM, Austin Wright <aaa@bzfx.net <mailto:aaa@bzfx.net>> wrote:
>> 
>> Hello,
>> 
>> I’m reading through RFC 7231 and RFC 7232 to implement an HTTP server that supports a PUT method on a resource, with 100 Continue and 412 Precondition Failed responses; and I am wondering why 412 must be tested last, after all other errors.
>> 
>> The uploaded document must conform to certain media type and validation requirements, perhaps responding with an error like 400 (Bad Request) or 422 (Unprocessable Entity) if the upload is not well-formed. Suppose I issue a request with:
>> 
>> Expect: 100-continue
>> If-Match: “etag”
>> 
>> In this case, it seems to me the server should issue a 412 Precondition Failed if the resource has been changed, and that I shouldn’t have to upload the entire document just to find out that it has been changed. Yet, RFC 7232 HTTP Conditional Requests says:
>> 
>> > A server MUST ignore all received preconditions if its response to the same request without those conditions would have been a status code other than a 2xx (Successful) or 412 (Precondition Failed). In other words, redirects and failures take precedence over the evaluation of preconditions in conditional requests.
>> 
>> This suggests that I must validate the document in its entirety if I’m going to return a status like 422, before testing the precondition, even if the upload is very long.
>> 
>> (1) Is there a particular reason that the precondition test must be tested after all other 4xx (even 5xx) errors?
> 
> The simple answer is that 422 did not exist at the time the requirement was written.
> The more complex answer is that the requirement should be restated to talk only about
> errors that are discovered before the body is processed.
> 
> If you can, please add an issue for that to "https://github.com/httpwg/http-core/issues <https://github.com/httpwg/http-core/issues>"
> (if not, let me know and I will add one).
> 
>> Now, I imagine this requirement might have the effect of reducing some race conditions, but even then it would not completely eliminate race conditions, without a way of locking the database/filesystem record for writing.
>> 
>> (2) Are there clients in the wild that would be broken if the precondition test happened earlier? i.e. are there any clients that would incorrectly assume the upload is well-formed if they received a 412 error instead of a 400, 415, and/or 422?
>> 
>> (3) For 100-continue and performance purposes, can this limitation be relaxed so it’s the last thing tested before errors relating to the request entity-body?
> 
> Yes.
> 
> ....Roy
>