Avoid using func_get_args #1741
Conversation
| @@ -199,7 +199,7 @@ private function constructRequest($method, $absUrl, $headers, $params, $hasFile) | |||
|
|
|||
| $opts = []; | |||
| if (\is_callable($this->defaultOptions)) { // call defaultOptions callback, set options to return value | |||
| $opts = \call_user_func_array($this->defaultOptions, \func_get_args()); | |||
| $opts = \call_user_func_array($this->defaultOptions, [$method, $absUrl, $headers, $params, $hasFile]); | |||
There was a problem hiding this comment.
There's a really obscure case where this is breaking. For users on PHP < 7, \call_user_func_array returns the original value of $method (i.e. before we do $method = \strtolower($method) on line 198), but this change will change it to lower case it. Since $this->defaultOptions is a potentially-user-defined callback we can't be 100% certain this won't break somebody, but this would only happen in an instance where somebody was introducing a non-lower-cased verb into our request infrastructure (custom requests?)
I think this case is unlikely but maybe it would be better to postpone this to the major?
There was a problem hiding this comment.
custom requests are only available on the beta SDKs, not the GA ones - so we should be good?
There was a problem hiding this comment.
Unfortunately you can initialize StripeClient or ApiRequestor directly and call ->request (happens in the wild). I don't think we ever documented this though, so it's probably fine?
There was a problem hiding this comment.
fair enough, will close this out and this can go in the next month's major release
Resolves the incompatibility issues with PHP 8.0 as described in #1739