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.coll...@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 «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 > >
