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 <dragoo...@gmail.com> wrote: > On Thu, 23 Dec 2021, 00:06 David Gebler, <davidgeb...@gmail.com> wrote: > > > On Tue, Dec 21, 2021 at 6:59 PM Christoph M. Becker <cmbecke...@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 > > > > > > > > >
