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