Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:116750 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 41348 invoked from network); 1 Jan 2022 13:35:06 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 1 Jan 2022 13:35:06 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id C6CF41804AA for ; Sat, 1 Jan 2022 06:41:31 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,NICE_REPLY_A, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-wr1-f46.google.com (mail-wr1-f46.google.com [209.85.221.46]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Sat, 1 Jan 2022 06:41:31 -0800 (PST) Received: by mail-wr1-f46.google.com with SMTP id q16so60865204wrg.7 for ; Sat, 01 Jan 2022 06:41:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to:content-transfer-encoding; bh=94y+n4odsPvfmnBIWGBMbbgk9YxZkPqAfEc1iP4ojew=; b=bo+wR0nOxJ8ms4s5RBfc2KwgnqBdN6rSNuWeHvynh5JGiPNM2zCBily5SMUCTeg6Gf KZmB8P03XZpYoB2q0VMAdROsJ0hsrKA6jhlmhU37n0PYkrMTikkcyYdkzFkk1OoKfv9+ dIsazCMbKo163USDFAcP9W7Sgr6jL0ZuDNGylvIOBE2cQzepeQ6P7d+i1dyfLTlVNETi Sqk4MnKh3crx17EO5ZmlW6zoMpYOBW2dzK1RDj8N/8lYDG9rQjp097wNZY5qTQI0KhfA V00irnVEVqY67VsH4/fskOV10vTB5SpHv7IXcxWoNndEPVoReKb05i57fIknakuvos61 Dnjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=94y+n4odsPvfmnBIWGBMbbgk9YxZkPqAfEc1iP4ojew=; b=6Fn1Ly0v4VBvIyEr0l7FwJ0CXpUrCUVBUuZy6CACgDcsVQ9s/WByYgdPBZeMvwlYS+ kNZ2rOxmwSeY/4OpUpwan/GlbSBWtQQ8pQbeOwn0b1jlV4CyvXPHlrPcmIHkE0zxtTc2 bfE4oon4GCwWCqTL11irwMvO9Rv3cHPk6VzIqCGfkH9lcTIjWVrzItXAzxp6USNP60Xt NgLdmdG+RZH2vL87Vng9fSFq3vHGn9U6REb/vMkAnv3NsA8DrRlEuZrdzy3lRjC4D9GM uNlfGaMQh9xhnEr1iYuHujaX9mO5nVuPqX+CzcRuP6TPIUcEyUfuVUp1ta4/HWjpCGoH 3wig== X-Gm-Message-State: AOAM530vkJjX4RVMfh9V0YGXV/9kRDzyeI7x6fS4vUhX0teVQ0xYOmaJ gT1VPHL7XgYxEAFGvnIJRN19ZgJg+WE= X-Google-Smtp-Source: ABdhPJzapSh8+mVDhLoERG/41sV1tuqcrRE5/ZK++8WJe/FjN74SRkPQTFCnl3ExoFWSoqMYn8nstg== X-Received: by 2002:adf:9bdb:: with SMTP id e27mr32922544wrc.417.1641048089092; Sat, 01 Jan 2022 06:41:29 -0800 (PST) Received: from [192.168.0.22] (cpc104104-brig22-2-0-cust548.3-3.cable.virginm.net. [82.10.58.37]) by smtp.googlemail.com with ESMTPSA id b16sm32625395wmq.41.2022.01.01.06.41.28 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 01 Jan 2022 06:41:28 -0800 (PST) Message-ID: Date: Sat, 1 Jan 2022 14:41:25 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Content-Language: en-GB To: internals@lists.php.net References: <1640910093.890171965@f721.i.mail.ru> In-Reply-To: <1640910093.890171965@f721.i.mail.ru> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [PHP-DEV] RFC: Stop to automatically cast numeric-string to int when using them as array-key From: rowan.collins@gmail.com (Rowan Tommins) 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 instead of array). 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]