Re: [PHP-DEV] header() allows arbitrary status codes

[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 >= 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  wrote:
>>
>>> 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 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] 
> [2] 
>
> Christoph
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

>>>
>>
>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] header() allows arbitrary status codes

[Hans Henrik Bergan]

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 
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  wrote:
>
>> 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 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] 
>> > > [2] 
>> > >
>> > > Christoph
>> > >
>> > > --
>> > > PHP Internals - PHP Runtime Development Mailing List
>> > > To unsubscribe, visit: https://www.php.net/unsub.php
>> > >
>> > >
>> >
>>
>

Re: [PHP-DEV] header() allows arbitrary status codes

[Hans Henrik Bergan]

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  wrote:

> 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 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] 
> > > [2] 
> > >
> > > Christoph
> > >
> > > --
> > > PHP Internals - PHP Runtime Development Mailing List
> > > To unsubscribe, visit: https://www.php.net/unsub.php
> > >
> > >
> >
>

Re: [PHP-DEV] header() allows arbitrary status codes

[Paul Dragoonis]

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 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] 
> > [2] 
> >
> > Christoph
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: https://www.php.net/unsub.php
> >
> >
>