Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:116729 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 8323 invoked from network); 23 Dec 2021 15:36:03 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 23 Dec 2021 15:36:03 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 259731804AA for ; Thu, 23 Dec 2021 08:40:17 -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=-1.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,NICE_REPLY_A, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS8560 212.227.0.0/16 X-Spam-Virus: No X-Envelope-From: Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 ; Thu, 23 Dec 2021 08:40:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1640277614; bh=4TBf89W+nXRArvFedMnY0BtUf50fnbg3Kv+1N+YjUOs=; h=X-UI-Sender-Class:Date:Subject:To:Cc:References:From:In-Reply-To; b=JkQISBzVNTjlntBd6JQTm2uUAIcoAPDTakVPySHOwtnaWeaS0rldZjAEBXFsDBo4H XeERF8SnZdSv3Ees6Jnt5MQ8TmBqqOCG6t9j8uo7uYs1s6KVRzNjSHWp/w528EEiaP i+RXkWfgJ3SXFNvwm4mbcga57JzADbwh1b8DDVug= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.2.130] ([84.179.249.188]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MTzfG-1msDdv16t0-00R2wf; Thu, 23 Dec 2021 17:40:13 +0100 Message-ID: <898bfe0f-7af0-a03c-26aa-8f739ab27f2a@gmx.de> Date: Thu, 23 Dec 2021 17:40:12 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Content-Language: de-DE To: Hans Henrik Bergan Cc: PHP internals References: <5d2b1d8f-9b7a-558f-8750-cc97b3ad0589@gmx.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:+gXbIba38+LbJGcm0W2I9BIkFvmCx4AtVHs2tu04QrTDCg5aKCH aobeL1biZehJDPfsEnr7NpKOVCF5o7tbjOYlGBew0oJe0UUsqTEeQzVu3voXtt1Eb2oGA+5 2apePgj4gOWuMqCtS8rn16U2z4MvZRj0Lk9lR6a8Ex6HwWCF68UMUYwSod3fiGbDOhb1cHc gUiSL8nsw9YIDHnxYzpCQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:vg545yE9h6o=:9mUMVQ2Nlt3jmq5bUWrdXL X1tkr/aerNjTuRQGX5JVLJeHEibwNtwwAyQ3ogTXGa7WCQfToki0UZ1L3oMoRmVOFYvAYaG6G Mv7ezhnzbYY++9CSb9/zUd7z07/rgUBm4vnOAhozboNQx7Cld3EwQk/njqo3NZK8UijhAK7Rn OPj5Jy/Bsi373gU4ik155hVL8F2F0wUA2mimwDEEVB2WZiHM0yywr13H785fPrc6+FUFEmBSi rxIy6GGS+DpijuYQONXngn9XjiJUKZDiXks8F5PKGe7tRImrAUiot45krenmJ8M7bOtPq1+Sk 4V5QIefcAyAoym79YlF8uiLkXvCsdYnOvPoYFXwibXutSeQrBeuDKbs9sZkHT+sfd5H6rl+pT lmUaKrX7A8ZXvvKeD+0HS6vM7jspM5a70IThef0+NysLRv7H0N6JriKhg/ofkRH1r1A1cOGaW A7edNsXirVLy/oypfz5TfH+nOnibTKcMHifhlEYl/3/Qbhien4T/mfUiXM6oU0FufBvAO6995 jDBR7zwCJz8LnSgpdreSVJp9XAv+2XLyhGJjVM05B4CIsPDEdm4MFmR558gb6c7CiTpJ1EjcY VtR/f9cKpXYQYKs7Uqd3Nvy/zcYF9kbKztyKnRxaayjqPehPFh+9CwfbqrwaQkbIiRjyAdlqW 2dk0h2M8F6sHBHrU7uN0oLINHV0sW8Vb4fVfIzghl3JuyCpxanahWZM63lEs6E6evYJUzEpv/ Qw3pypdODFxYL8oLmIiZmcj8nDkSH+5nuCRZZd4SFyeppSpt8xzLWB6riv9O0prUmWWj+boVV SlhGopo2LRFk1QcJXtnJg+OQ2R6c9l/o+ySARkqt1iZn7XXyPw= Subject: Re: [PHP-DEV] header() allows arbitrary status codes From: cmbecker69@gmx.de ("Christoph M. Becker") On 23.12.2021 at 16:53, Hans Henrik Bergan wrote: > another thing, it wouldn't surprise me if someone at some point want to > emulate some IIS-specific codes in PHP, like > header("HTTP/1.1 401.3 Unauthorized due to ACL on resource."); > > it'd be a shame if PHP literally cannot send IIS-errorcodes I don't think that this works right now, and I'm not absolute convinced that we should add support for this. It seems to me that this violates RFC 7230, section 3.1.2[1]. After consideration, I agree, though, that it's better to not restrict the range to 100-599, and maybe we should allow for more or less than 3 digits, and just catch potential overflow. [1] Christoph > On Thu, 23 Dec 2021 at 16:40, Hans Henrik Bergan > wrote: > >> sometime in the future HTTP 6xx will be defined, and we'll have to add = a >> big warning to the header()/http_respons_code() pages like >> "Warning: HTTP 6.x.x is only supported in PHP >=3D x.x.x and PHP <=3D8.= 1.x", >> and library developers have to add fugly code like >> `if(PHP_VERSION_MAJOR >=3D X || (PHP_VERSION_MAJOR <=3D8 && PHP_VERSION= _MINOR >> <=3D 1){http_response_code(6xx);}else{ >> trigger_error("your php version cannot use http 6xx"); >> } >> >> i'd prefer if we didn't restrict the header ranges >> >> On Thu, 23 Dec 2021 at 13:47, Paul Dragoonis wrot= e: >> >>> On Thu, 23 Dec 2021, 00:06 David Gebler, wrote= : >>> >>>> On Tue, Dec 21, 2021 at 6:59 PM Christoph M. Becker >>>> wrote: >>>> >>>>> Hi all, >>>>> >>>>> a while ago it has been reported[1] that our header() function >>> actually >>>>> allows arbitrary status codes, which may even overflow. Of course, >>> that >>>>> makes no sense, since the status code is supposed to be a three digi= t >>>>> code. So this ticket has been followed up by a pull request[2], and >>>>> Jakub suggested to further restrict the status code to be in range >>> 100 - >>>>> 599. >>>>> >>>> >>>> Personally, I don't like restricting the status code to a number in t= he >>>> 100-599 range. As far as I know, RFC 7230 doesn't mandate anything >>> beyond >>>> the requirement of 3 digits and while 7231 may only specify semantics >>> for >>>> 1xx-5xx, that doesn't mean there isn't a legitimate use-case in custo= m >>> or >>>> internal applications for status codes outside the usual semantics. >>>> >>>> The overflow part is a legit bug which can and should be fixed, but I= 'd >>> at >>>> least question whether a user should be obliged to stick to conventio= nal >>>> HTTP semantics via the header() function, or even a strictly conforma= nt >>>> implementation of the standards defined 7320. Maybe this behaviour >>> could be >>>> default but overridable via a new, fourth optional parameter or >>> something, >>>> I don't know...but I can easily imagine someone having a legitimate >>> context >>>> in which they want to send status codes outside the usual range >>>> representing custom semantics. >>>> >>> >>> >>> I think its safe to say we should restrict the overflow parts. >>> >>> As for boundaries; I don't know who is or isn't using their own custom >>> status codes. It's unlikely, but entirely possible. As such, this is >>> considered a BC break. >>> >>> If we apply restrictions to a minor release, then upgrading will be ha= rder >>> for 8.2 if we include this in the next release. >>> >>> You could say 98% of people are using standard ranges for status codes= , >>> but >>> we do have to always take into account the 2% on our decisions. >>> >>> Thanks. >>> >>> >>> >>> >>>> >>>>> >>>>> Since this could break some pathological cases, I wanted to ask >>> whether >>>>> anybody objects to this change for the master branch (i.e. PHP 8.2). >>>>> >>>>> [1] >>>>> [2] >>>>> >>>>> Christoph >>>>> >>>>> -- >>>>> PHP Internals - PHP Runtime Development Mailing List >>>>> To unsubscribe, visit: https://www.php.net/unsub.php >>>>> >>>>> >>>> >>> >> >