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