>Суббота, 1 января 2022, 17:41 +03:00 от Rowan Tommins ><rowan.coll...@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 «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 I just gave an example of what at the moment can cause an exception in any 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 logic of the application. And fixing this behavior, I believe, will automatically fix many libraries (not necessarily PSR) that do not take this behavior into account. -- Kirill Nesmeyanov
