Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116728
MIME-Version: 1.0
References: <5d2b1d8f-9b7a-558f-8750-cc97b3ad0589@gmx.de> <CA+p1FaaAb4Oa2tX8tgnnSERobwBa0MTU42QoJ4v6x-i3JB2yyA@mail.gmail.com>
 <CAKxcST_Xv4QFFh4VfDE9oD9C1gi8r+UQWwRbXoxiXMMA3C-YJw@mail.gmail.com> <CAJmy8YFLfwWdPcuC3svguc1XQV781jjZBS9=YHFOSN=bO2uTwA@mail.gmail.com>
In-Reply-To: <CAJmy8YFLfwWdPcuC3svguc1XQV781jjZBS9=YHFOSN=bO2uTwA@mail.gmail.com>
Date: Thu, 23 Dec 2021 16:53:43 +0100
Message-ID: <CAJmy8YGMZfw8P6jP2KXcHSqj3xMtaW5aOaJ_=Ri5B-FYZsD86g@mail.gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000005a177b05d3d240a6"
Subject: Re: [PHP-DEV] header() allows arbitrary status codes
From: divinity76@gmail.com (Hans Henrik Bergan)

--0000000000005a177b05d3d240a6
Content-Type: text/plain; charset="UTF-8"

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

On Thu, 23 Dec 2021 at 16:40, Hans Henrik Bergan <divinity76@gmail.com>
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 >= x.x.x and PHP <=8.1.x",
> and library developers have to add fugly code like
> `if(PHP_VERSION_MAJOR >= X || (PHP_VERSION_MAJOR <=8 && PHP_VERSION_MINOR
> <= 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 <dragoonis@gmail.com> wrote:
>
>> On Thu, 23 Dec 2021, 00:06 David Gebler, <davidgebler@gmail.com> wrote:
>>
>> > On Tue, Dec 21, 2021 at 6:59 PM Christoph M. Becker <cmbecker69@gmx.de>
>> > 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 digit
>> > > 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 the
>> > 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 custom
>> 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 conventional
>> > HTTP semantics via the header() function, or even a strictly conformant
>> > 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 harder
>> 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] <https://bugs.php.net/bug.php?id=81645>
>> > > [2] <https://github.com/php/php-src/pull/7676>
>> > >
>> > > Christoph
>> > >
>> > > --
>> > > PHP Internals - PHP Runtime Development Mailing List
>> > > To unsubscribe, visit: https://www.php.net/unsub.php
>> > >
>> > >
>> >
>>
>

--0000000000005a177b05d3d240a6--