Re: RFC: Stop to automatically cast numeric-string to int when using them as array-key

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 «0: value»), 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]