Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:115642 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 80338 invoked from network); 6 Aug 2021 12:51:04 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 6 Aug 2021 12:51:04 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id D18BD180504 for ; Fri, 6 Aug 2021 06:20:33 -0700 (PDT) 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-f51.google.com (mail-wr1-f51.google.com [209.85.221.51]) (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 ; Fri, 6 Aug 2021 06:20:33 -0700 (PDT) Received: by mail-wr1-f51.google.com with SMTP id b13so11069002wrs.3 for ; Fri, 06 Aug 2021 06:20:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=pDXKKFSBKjJUbAK2K1JN4TooFbvMb5ylBnWins+f0So=; b=n664J5e5rY0a21TZecC4nMLstnz/K0wjTBjU2jy2Q0k5YoU2ppbrMnSe7H7mKCDtvz ixS55fGhejP8+5jQv4koJX0w+acJ7DARUkFEUNxDN0UORRKDBa7IO3fQ+Adhqxpw5lZG wm7GpxkY+kKvsu6v8b25jdJSiixA5L5GH6WVJKhcj9yUwHzM8Z4izFeoMkp4tqlw/Dwk 9epkkVILxIBVuOmxANdBCzZTBeDGZJvBGJiev9TCKVSpFM8QK8m4ufz5YNo/xemz4ZYF /chqJ0BJOjrqusl2F66VMkz++XvIjL55e80D7SkoLhr4v2W+MPwrKsnrxZGSAx/vTOaD ryOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=pDXKKFSBKjJUbAK2K1JN4TooFbvMb5ylBnWins+f0So=; b=n/RdQOpW6V3ztBHUhUvduSExhXAWWbmTSLA2RfxfHTxjO3OjRvo0Hj90anj/He9qap oHGmCa82rAnbA+jP/w/EHI+QHyHML+rkojzPm461n2/T5xZOpHWDV9tYRSPP0BVnZgFg I0whlzc9uaICXeytKYJ28TtuX5g8rqPayqqUP9OwojKtajWJKWbqNOV03yw79dvjhfhR /4kXwFMObiRyVUdW96l6XObb4tFQhm3Yvu88nB8e97m4OQdzbqpUb04BOSLyIWqvvhWJ XSi2wCje2iQVcMEjMfgyHxBfnmOEckD5yJs0il1v9SaMdQPzX9cKb04FbsicnxJmylAM Q+KA== X-Gm-Message-State: AOAM532VmF36Uw/Dq5sUzuyiSsBCU5VuW2XYK/fp+arVLTIOL+pLn4Nv cOnvuB01qTDSRqQRKY9EFEVmj+FFZXM= X-Google-Smtp-Source: ABdhPJzjn/8CJ1Qjmxw1L+fTfswOb5WbNttdz/3QDjb/5ELHyW49ZJq8E1PolvzgzLKlEvq7xrxtww== X-Received: by 2002:adf:ffc3:: with SMTP id x3mr10380890wrs.136.1628256029059; Fri, 06 Aug 2021 06:20:29 -0700 (PDT) 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 j5sm9126964wrs.22.2021.08.06.06.20.28 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 06 Aug 2021 06:20:28 -0700 (PDT) To: internals@lists.php.net References: Message-ID: <70ae3208-250b-5d47-28d7-282d7bf44ed7@gmail.com> Date: Fri, 6 Aug 2021 14:20:26 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Subject: Re: [PHP-DEV] [RFC] Add parse_query_string as an alternative to parse_str From: rowan.collins@gmail.com (Rowan Tommins) On 06/08/2021 12:12, Kamil Tekiela wrote: > Perhaps, instead of adjusting this behaviour only for the new function, we > could remove this behaviour as a whole, given that it is a remainder of the > long-forgotten register globals? I don't see any use for it anymore Changing behaviour like this is tricky, because even if it's not that useful, it is consistent, so code to process a query string of "?foo.bar=42" will be looking at $_GET['foo_bar'] not $_GET['foo.bar']. If we "fix" the name mangling, that code will break, and not necessarily in a very obvious way. Note that there are other parts of the request which get mangled in similar ways, such as when HTTP headers are translated into CGI environment variables. The solution in that case is to ignore the CGI vars and use a function like getallheaders(), so having a non-mangling http_parse_query() doesn't feel out of place. Having the function mirror http_build_query() as closely as possible seems like a good idea, e.g. http_parse_query('foo_0=a;foo_1=b', 'foo_', ';') should return [0=>'a', 1=>'b']. Regards, -- Rowan Tommins [IMSoP]