Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:116774 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 95657 invoked from network); 3 Jan 2022 14:35:05 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 3 Jan 2022 14:35:05 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 750A91804E3 for ; Mon, 3 Jan 2022 07:42:04 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-ua1-f44.google.com (mail-ua1-f44.google.com [209.85.222.44]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Mon, 3 Jan 2022 07:42:01 -0800 (PST) Received: by mail-ua1-f44.google.com with SMTP id v14so40741838uau.2 for ; Mon, 03 Jan 2022 07:42:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=of4cEiu0HjAcqOGD89bFUnkeXVKBXrmxGBxilFgyt+g=; b=EdcZlPk6R5ETVP6C4P5wptwi/azqAYgjt+K1Vo4LA/hMy+p2jFPjdoHOA/scbxPIML PPPXI3J1Q7GbIA9qtGgx+8/SzRSAiVxmxCdfmSiuB4oZ+X3PSxfZnC9a4JwpAWfOIDxn KLk74J3RPg5AorOPby4Ln8HOww7W45COOcTzEMiiPVVAm7KZgjVhiwxwyNZiSjWCCf3o gjxApNdFVWDSUUCpuds4UiKelNcMELnaugPVy4PpKojTFkbDjLlBQj20nzc0qDA9n/Dc 6XvrziVhoNBrIYPwl8e/Tlquaryg93pNdu8pJGpKDrREjfi8d07amTV5w3R7lppzqKlV iwcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=of4cEiu0HjAcqOGD89bFUnkeXVKBXrmxGBxilFgyt+g=; b=N/HZd1VdugZlHnkGQ9yl1VwiDbpPiVEHM54kFbUjl3zd6TdnAZodwdiZ24Y0LGlwWK 2lOD5X/c20RmPMVbQiocRxC3RpvZgUGPF8c8Fs8gq6LMOqnxwOATaPNvs7qn1fvJ5Se0 7hByulvSiltBQ5SDT9eYtSB6+MgTCZumVm/yCZjQCRnLLUI1AzODsgTjPySPj8JaxIXD 04gk+ncAoPRcsy2i7pJxyCGYwB0fOw9Zxgiutn3VmujnymHylHbcaI7R9w2z7H4oD4KF IM9M99B3eUInQGZ635lZIPjp+ulBOqcqn8MGqvooaIL1626lINtd82Usgw6wDVFvG+Bb G5sg== X-Gm-Message-State: AOAM5312gnYRqBPshQtNvb/LA6nr5jHSBUHYh20Ued2AzafMV8ZT71c6 ZiDVYpuv1nXpZVawb8wIFIml3QbK8QQXhyvA20I= X-Google-Smtp-Source: ABdhPJxWN35hjy72LDyJ8KNUxVIOsrTRbaIcbj01C+PgvzR2ut1PncZSCoNKIgjQdPjfZ6TxA0X6lgG+1w7x0TnsKVY= X-Received: by 2002:a67:bb01:: with SMTP id m1mr14582005vsn.48.1641224520247; Mon, 03 Jan 2022 07:42:00 -0800 (PST) MIME-Version: 1.0 References: <1640910093.890171965@f721.i.mail.ru> <1641095231.967164658@f750.i.mail.ru> <2DC31ED4-8C27-4ADF-9946-8369C6E0A42F@gmail.com> In-Reply-To: <2DC31ED4-8C27-4ADF-9946-8369C6E0A42F@gmail.com> Date: Mon, 3 Jan 2022 10:41:48 -0500 Message-ID: To: Rowan Tommins Cc: internals Content-Type: multipart/alternative; boundary="00000000000086adb005d4af5c02" Subject: Re: [PHP-DEV] RFC: Stop to automatically cast numeric-string to int when using them as array-key From: chasepeeler@gmail.com (Chase Peeler) --00000000000086adb005d4af5c02 Content-Type: text/plain; charset="UTF-8" On Sun, Jan 2, 2022 at 7:05 AM Rowan Tommins wrote: > On 2 January 2022 03:47:11 GMT, Kirill Nesmeyanov wrote: > > > >I just gave an example of what at the moment can cause an exception in > any application that is based on the PSR. It is enough to send the header > "0: Farewell to the server". In some cases (for example, as is the case > with RoadRunner) - this can cause a physical stop and restart of the server. > > Any library where a crafted HTTP request can cause a server shutdown has a > bug which needs addressing right now - possibly more than one, actually, as > it implies error handling is leaking across request boundaries. A change to > the language applied in the next major version would fix this some time > around 2025, once people start adopting it. A workaround in the library > itself can be applied within weeks. > > I already gave a simple solution that such libraries can apply right now, > with very little chance of negative impact: sanitise headers more > aggressively than the HTTP standard requires, as Apache httpd does, in this > case discarding any header containing only digits. This is likely to be > about three lines of code inside a loop preprocessing raw headers: > > if ( ctype_digit($rawHeaderName) ) { > trigger_error("Numeric HTTP header '$rawHeaderName' has been > discarded.", E_USER_WARNING); > continue; > } > > If I was the maintainer of such a library, I might consider even stricter > validation, considering what seems like an accidentally broad definition in > the HTTP spec, and the possibility of an application receiving even more > exotic characters if processing raw TCP traffic. > > > The idea of an array_keys variant or option that forces everything back to > string seems like it might be useful (and easy to polyfill for old > versions). Changing such a fundamental language behaviour in the hope that > it will fix more code than it breaks is just not worth it. > > But "001" casted to 1 will then get casted back to "1" not "001". > Regards, > > -- > Rowan Tommins > [IMSoP] > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > > -- Chase Peeler chasepeeler@gmail.com --00000000000086adb005d4af5c02--