Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116761
MIME-Version: 1.0
References: <CABEW5qdH4w3JJpvZP4pD4R2tTvAFLiPZ_UNBnwA_38cZ4Mf8og@mail.gmail.com>
 <1640910093.890171965@f721.i.mail.ru> <fe1cd7bb-0b28-4e49-32ba-913674d8b6a8@gmail.com>
In-Reply-To: <fe1cd7bb-0b28-4e49-32ba-913674d8b6a8@gmail.com>
Date: Sun, 2 Jan 2022 08:12:49 -0600
Message-ID: <CACL3jgOMFCD_ruEgA=cZuvCoDTG=JD-3xHangrO6WEKBN0s+pw@mail.gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000064f6f105d49a00f6"
Subject: Re: [PHP-DEV] RFC: Stop to automatically cast numeric-string to int
 when using them as array-key
From: nwallace@fyberstudios.com (Nick Wallace)

--00000000000064f6f105d49a00f6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I've sent a few emails to unsubscribe. Please remove me from this list. I'm
tired of these fucking emails about a dead language

On Sat, Jan 1, 2022, 8:41 AM Rowan Tommins <rowan.collins@gmail.com> wrote:

> 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
>
>

--00000000000064f6f105d49a00f6--