Re: HTTP request validation guidelines for implementers
João Penteado <joao@penteado.me> Fri, 09 July 2021 20:54 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 E5AC53A2EA3 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 9 Jul 2021 13:54:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.75
X-Spam-Level:
X-Spam-Status: No, score=-7.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.248, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=penteado.me
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 ahAbxzrrEfKe for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 9 Jul 2021 13:54:30 -0700 (PDT)
Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (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 C72783A2EA2 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 9 Jul 2021 13:54:30 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1m1xTB-0006Dy-Lh for ietf-http-wg-dist@listhub.w3.org; Fri, 09 Jul 2021 20:51:33 +0000
Resent-Date: Fri, 09 Jul 2021 20:51:33 +0000
Resent-Message-Id: <E1m1xTB-0006Dy-Lh@lyra.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) by lyra.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <joao@penteado.me>) id 1m1xT6-0006DB-TJ for ietf-http-wg@listhub.w3.org; Fri, 09 Jul 2021 20:51:30 +0000
Received: from mail-4317.protonmail.ch ([185.70.43.17]) by mimas.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <joao@penteado.me>) id 1m1xSz-0004a8-IS for ietf-http-wg@w3.org; Fri, 09 Jul 2021 20:51:25 +0000
Date: Fri, 09 Jul 2021 20:51:07 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=penteado.me; s=protonmail3; t=1625863868; bh=NsQDwIcDdV4jKGWj6tKOVN8V3eJSZAANnL2VRdsMhSE=; h=Date:To:From:Reply-To:Subject:In-Reply-To:References:From; b=PkZknGa0NDwgfwTCa4U0wav7TDgRFg21xrDro4EOl5hVmYU2APROTlDW3P5CL3n0J GYiQZt26Y9RshDIKqClAq9z80plRppwJbeV4RtxAaLG764BYmKtG3D75/ANKAD34x5 Y1Qk/XD/8Krkp9lKF6nSwaUCeDDxW5PLSmserLGdKJOT9TF5CH175iAyOQP6Rv5Dzr okvcEE0sEt0OfVrigflXBFFFmD8kn0QzyGlYCuENcc1jLBcdl9/rHyniJ9X51zQd+Y QPtaZgkG2P2BT1Z4VRj7gppLhlu8VwFN6O37V5JikKG/ChyX9lnIaOtAYuJy7yp2v7 hsU22JdPSqZmA==
To: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
From: João Penteado <joao@penteado.me>
Reply-To: João Penteado <joao@penteado.me>
Message-ID: <JcgT_pAtxXz7JvoydG9WObp2cDvy82xKSIpXKHAk96T5Wjn1nVjfLySrVUpcOgCTiaSVE0abz2RaYB5ESzDXsjewhvghMfeZsBPXZ8KmTmU=@penteado.me>
In-Reply-To: <d0f5c770-4b43-b96f-28c0-318d0795e345@gmx.de>
References: <FG0pbGeOrYyTy9Qq7QgDZtZWHwKpohi9eXVW-dkD1lFwkFM3Sqx2T1Wjv8zDZmPusf1EZ0XtKE5XVaFa-DPrM09yy0hIogQjI_MUI6L4Jdk=@penteado.me> <de67ac60-b09b-3bec-e7b2-2bdbe94254ac@ztk-rp.eu> <emoCRk-FQF5chLVc_HHoxKtaU_OD2hjrWv1aA628SP0JvUtfsX3Z9Dymw1FdMnDMwYe4FU-dYq5jP3URnqKZVvUgQ-1t5zep9zztm-pMD3Y=@penteado.me> <d0f5c770-4b43-b96f-28c0-318d0795e345@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=185.70.43.17; envelope-from=joao@penteado.me; helo=mail-4317.protonmail.ch
X-W3C-Hub-DKIM-Status: validation passed: (address=joao@penteado.me domain=penteado.me), 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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1m1xSz-0004a8-IS 54a847e9517482333d95a16463297952
X-Original-To: ietf-http-wg@w3.org
Subject: Re: HTTP request validation guidelines for implementers
Archived-At: <https://www.w3.org/mid/JcgT_pAtxXz7JvoydG9WObp2cDvy82xKSIpXKHAk96T5Wjn1nVjfLySrVUpcOgCTiaSVE0abz2RaYB5ESzDXsjewhvghMfeZsBPXZ8KmTmU=@penteado.me>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/39005
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>
On Friday, July 9th, 2021 at 15:45, Julian Reschke <julian.reschke@gmx.de> wrote: > Am 09.07.2021 um 19:51 schrieb João Penteado: > > > ... > > > > 2. If the most servers out there adopt the same validation order, clients will > > > > gain additional information unavailable before. If, for instance, every server > > > > checks URI length before checking payload size, and I get a "413 Request Entity > > > > Too Large" error, I would know for sure that my URI length is fine and all the > > > > previous checks passed successfully. > > > > ... > > You lost me here. > > If a client sends both a too large URI and a too large request body, > > why does it matter in practice which one is reported first? At the end > > of the day, to fix the issue, both problems need to be resolved, no? > > Best regards, Julian You're correct, in pratice, the validation order doesn't matter as much as what is being validated, as the client would still have to address all issues in order to have its request accepted. Which is why I believe that reason no. 1 is a more relevant argument for having a well definied validation order. Despite this, with a well defined validation order additional information would be conveyed to the client, given HTTP's limitation of only returning one error code at a time, which might be helpful in debugging. If there's no consensus on the need of establishing such a validation check order, what we could do instead is focus first on establishing what SHOULD and what MUST be validated and then suggest on the spec some considerations implementers may want observe regarding validation order. Best regards, João Penteado
- HTTP request validation guidelines for implemente… João Penteado
- Re: HTTP request validation guidelines for implem… Rafal Pietrak
- Re: HTTP request validation guidelines for implem… Julian Reschke
- Re: HTTP request validation guidelines for implem… João Penteado
- Re: HTTP request validation guidelines for implem… Julian Reschke
- Re: HTTP request validation guidelines for implem… João Penteado
- Re: HTTP request validation guidelines for implem… Willy Tarreau