|
|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
[2020-12-20 16:56 UTC] divinity76 at gmail dot com
Description: ------------ there are some apis which doesn't support http_build_query()'s array method of foo[0]=a&foo[1]=b&foo[2]=c, instead specifying arrays like foo=a&foo=b&foo=c , one such api is Google's Closure Compiler Rest API, https://developers.google.com/closure/compiler/docs/gettingstarted_api i recently had to generate a POST request to that api through PHP, i ended up doing ``` "output_info=compiled_code&output_info=warnings&output_info=errors&output_info=statistics&" . http_build_query(array( 'output_format' => 'json', 'compilation_level' => $compile_level, 'warning_level' => 'verbose', 'js_code' => $js_to_minify )) ``` i had to hack the output_info array data in there, instead of doing it the "proper way" of ``` http_build_query(array( 'output_format' => 'json', 'compilation_level' => $compile_level, 'warning_level' => 'verbose', 'js_code' => $js_to_minify, 'output_info' => array('compiled_code', 'warnings', 'errors', 'statistics') )) ``` it would be nice if http_build_query() could get a flag to treat numerically indexed densely populated arrays (eg what you get from array_values() or array("a","b","c") ) without brackets.. (there's probably a better name for it, idk what) not sure what the flag name should be though, PHP_QUERY_DENSE_NUMERICALLY_INDEXED_ARRAYS_WITHOUT_BRACKETS kinda feels too long Test script: --------------- <?php echo http_build_query( ["foo"=>["a","b","c"]], null, '&', PHP_QUERY_DENSE_NUMERICALLY_INDEXED_ARRAYS_WITHOUT_BRACKETS ); Expected result: ---------------- foo=a&foo=b&foo=c PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
|
|||||||||||||||||||||||||||||||||||||
Copyright © 2001-2024 The PHP GroupAll rights reserved. |
Last updated: Wed Dec 04 08:01:29 2024 UTC |
There is a misconseption about the last (and only) comment, I won't speak for the OP but I'm having the same issue described here. Yes, you could do it, because the issue is not about parsing/receiving the queryString in the $_GET superglobal... that would be if I were developing the website/api that receives the request and would imply that I'm using PHP. This issue is about *sending* those parameters out to an external website/api/server that might be developed by me or another person, and may not be coded with PHP. I find reasonable that the "fix" is proposed as an option/argument for the `http_build_query()` in order to avoid changing the current behaviour (currently compatible with PHP), but have the ability to modify it. The example/reason you're giving to say it wouldn't work implies that a PHP developer would use that option to generate a queryString that is not compatible with PHP and, at the same time, try to receive that queryString using PHP and pretend it will work. That would be an error of the developer, a pretty rare one because he/she would have to intentionally set that option. Actually, http_build_query has options like `arg_separator` that would make it not work in the receiving PHP end, for example: http_build_query(["foo" => "bar", "x" => "y"], "", "something") Would generate: foo=barsomethingx=y And $_GET would have: array(1) { ["foo"]=> string(15) "barsomethingx=y" } I think this a feature request more than a bug. It would help developers to build safe query strings that are compatible with other systems/languages. I really don't know if the current standard for URL allows square brackets to be used in order to have multiple values for the same query parameter or not. I've been looking at RFC3986 (section 3.4) and couldn't find anything about that, so I ask: are php generated query strings (using http_build_query) compatile with the current standard URL definition? I'll be looking forward to keep this conversation going, and I apologize if anything I wrote seemed a little aggresive, I'm not native english speaker.