Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116754
MIME-Version: 1.0
References: <CABEW5qdH4w3JJpvZP4pD4R2tTvAFLiPZ_UNBnwA_38cZ4Mf8og@mail.gmail.com>
 <1640910093.890171965@f721.i.mail.ru> <fe1cd7bb-0b28-4e49-32ba-913674d8b6a8@gmail.com>
 <1641095231.967164658@f750.i.mail.ru>
In-Reply-To: <1641095231.967164658@f750.i.mail.ru>
Date: Sun, 2 Jan 2022 00:19:42 -0500
Message-ID: <CAEUnE0e9T9_04tdgQc5cyCVAoewDH24xxT4Br1iz35nUevB=5w@mail.gmail.com>
To: Kirill Nesmeyanov <nesk@xakep.ru>
Cc: internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000c995d605d4928dfb"
Subject: Re: [PHP-DEV] RFC: Stop to automatically cast numeric-string to int
 when using them as array-key
From: tendoaki@gmail.com (Michael Morris)

--000000000000c995d605d4928dfb
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, Jan 1, 2022 at 10:47 PM Kirill Nesmeyanov <nesk@xakep.ru> wrote:

>
> >=D0=A1=D1=83=D0=B1=D0=B1=D0=BE=D1=82=D0=B0, 1 =D1=8F=D0=BD=D0=B2=D0=B0=
=D1=80=D1=8F 2022, 17:41 +03:00 =D0=BE=D1=82 Rowan Tommins <
> rowan.collins@gmail.com>:
> >
> >On 31/12/2021 00:21, Kirill Nesmeyanov wrote:
> >> I support this behavior fix because in its current form, due to a
> similar problem (almost?), all PSR-7 implementations contain bugs that
> violate RFC7230 (section 3.2:
> https://datatracker.ietf.org/doc/html/rfc7230#section-3.2 ). Thus,
> physically, by the standard, all headers can have the name "0" (like =C2=
=AB0:
> value=C2=BB), but when stored inside implementations, it is converted to =
a
> string and a problem arises ($message->getHeaders() //
> returns array<int|string, string> instead of array<string, string>).
> >
> >You appear to be technically correct - the RFC defines a header name
> >only as "token", which implies the following would all be valid HTTP
> >headers:
> >
> >42: The Answer
> >!: Bang
> >^_^: Surprised
> >
> >In practice, it would be a bad idea to use any of these.
> >
> >Every single one of the field names registered with IANA [1] starts with
> >a letter, and proceeds with only letters, digits, and hyphen ('-'). [The
> >exception is "*", listed there as "reserved" to specifically prevent its
> >use conflicting with the wild-card value in "Vary" lists.]
> >
> >I'm actually surprised this definition hasn't been updated with
> >interoperability advice in recent revisions of the standard. I did find
> >this general advice for internet message headers in RFC 3864 [2]:
> >
> > > Thus, for maximum flexibility, header field names SHOULD further be
> > >  restricted to just letters, digits, hyphen ('-') and underscore ('_'=
)
> > >  characters, with the first character being a letter or underscore.
> >
> >The additional restriction on underscore ('_') in HTTP arises from CGI,
> >which maps headers to environment variables. For instance, Apache httpd
> >silently drops headers with anything other than letters, digits, and
> >hyphen [3] to avoid security issues caused by environment manipulation.
> >
> >If I was developing a PSR-7 or similar library, I would be inclined to
> >drop any header composed only of digits, and issue a diagnostic warning,
> >so that it wouldn't escalate to a type error later. It certainly doesn't
> >seem reasonable to change the entire language to work around that
> >inconvenience.
> >
> >[1]  https://www.iana.org/assignments/http-fields/http-fields.xhtml
> >[2]  https://datatracker.ietf.org/doc/html/rfc3864#section-4.1
> >[3]  https://httpd.apache.org/docs/trunk/env.html#setting
> >
> >Regards,
> >
> >--
> >Rowan Tommins
> >[IMSoP]
> >
> >--
> >PHP Internals - PHP Runtime Development Mailing List
> >To unsubscribe, visit:  https://www.php.net/unsub.php
>
> I just gave an example of what at the moment can cause an exception in an=
y
> 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.
>
> Just in case, I will repeat my thesis: I cannot imagine that anyone is
> using this functionality consciously and that it is part of the real logi=
c
> of the application.


You don't have a lot of experience with legacy code then. PHP, particularly
old PHP (like 4, 5.1 era) was used by a lot of idiots.

I was one of those idiots (Perhaps I still am an idiot - jury is
deliberating on that but I digress).

Snark aside though, PHP has more than its fair share of self taught
programmers (again, not trying to be insulting as I am one myself), and
they do things with the code that veterans and formally trained programmers
would never think to try, let alone implement.

I guarantee fixing how key handling is done will break something - either
in the form of code exploiting the weird behavior, or code that is guarding
against the weird behavior; not to mention any tests that might be written
- though amateurs rarely write test code (again, speaking from past
experience I've grown beyond).



> And fixing this behavior, I believe, will automatically fix many librarie=
s
> (not necessarily PSR) that do not take this behavior into account.
>
>

And blow up who knows how many old code bases - many of which don't have
unit test suites to discover if there is a break ahead of time.  This is
the sort of BC break that would cause a cliff of users unable to migrate to
the major version that implements it.  A Python 2 vs. 3 style of break.

Even with that all said it may indeed be worth fixing - but this will
require the same sort of kid gloves approach removing register globals had
(for the newer folks, there was a time when $_REQUEST["var"] would auto
populate $var with lovely security snarls).  IIRC PHP 3 had register
globals always on, 4 created a config toggle to turn them off, and PHP 5.0
turned that toggle off by default, finally PHP 5.3 (6 without unicode more
or less) removed support for register globals entirely (My memory could be
off - it's in the changelogs for the curious).

I leave the decision making to the maintainers and contribs who do the
actual work. Hell, I personally don't even use PHP that much these days
having gotten a job where I focus on writing Cucumber tests in JavaScript
that run on node.js. I keep up with PHP and this list though cause one
never knows what the next job will entail. I just dropped out of lurk mode
to underscore along with others up thread the massive ramifications of what
is being proposed. As someone who wrote stupid code I can see this
breaking, tread lightly. And hell, I don't even know how much of that code
is still in use since I've changed employers many times since it was
written. This situation is not unique and can create huge headaches for
companies running projects on legacy code bases.

--000000000000c995d605d4928dfb--