Add PUT method support #1
Assignees
Milestone
Comments
ghost
assigned 
rmccue
pushed a commit
that referenced
this issue
Jun 9, 2017
Add setExpectedException shim for PHPUnit 6
Closed
jrfnl
added a commit
that referenced
this issue
Jun 21, 2021
…cURL)` PHP 8.1 deprecates passing `null` to non-nullable parameters for PHP native functions. Ref: https://wiki.php.net/rfc/deprecate_null_to_scalar_internal_arg The `Requests_Transport_fsockopen::request()` method passes `$request_body` into the PHP native `strlen()` function without sufficient validation, which on PHP 8.1 results in a `strlen(): Passing null to parameter #1 ($string) of type string is deprecated` notification. The existing `RequestsTest_Transport_Base::testEmptyPOST()` test method exposed this. When investigating this issue, I realized that no significant input validation was being done on the `$data` parameter. PR 368 in response to issue 248 added a test to verify that the "content-length" header was correctly set when `null` would be passed as `$data` and added a safe-guard specifically for when `null` would be passed. Also, as a matter of form, integers and floats were handled correctly for `fsockopen`, but anything else would lead to PHP errors in unexpected places in every supported PHP version, including integers and floats in combination with the `cURL` class. To mitigate this, I propose to: * Add a `Requests_Exception_InvalidArgument` class which extends the PHP native `InvalidArgumentException`. * Add input validation for the `$data` parameter to both the `cURL` as well as the `fsockopen` Transport class which maintains and stabilizes the pre-existing behaviour for handling of `null`, synchronizes the behaviour for integers and floats to be the same across `fsockopen` and `cURL`, but will throw the new `InvalidArgument` exception for any other type of unexpected input for the `$data` parameter. Includes additional tests covering this change.
jrfnl
added a commit
that referenced
this issue
Jun 21, 2021
…cURL)` PHP 8.1 deprecates passing `null` to non-nullable parameters for PHP native functions. Ref: https://wiki.php.net/rfc/deprecate_null_to_scalar_internal_arg The `Requests_Transport_fsockopen::request()` method passes `$request_body` into the PHP native `strlen()` function without sufficient validation, which on PHP 8.1 results in a `strlen(): Passing null to parameter #1 ($string) of type string is deprecated` notification. The existing `RequestsTest_Transport_Base::testEmptyPOST()` test method exposed this. When investigating this issue, I realized that no significant input validation was being done on the `$data` parameter. PR 368 in response to issue 248 added a test to verify that the "content-length" header was correctly set when `null` would be passed as `$data` and added a safe-guard specifically for when `null` would be passed. Also, as a matter of form, integers and floats were handled correctly for `fsockopen`, but anything else would lead to PHP errors in unexpected places in every supported PHP version, including integers and floats in combination with the `cURL` class. To mitigate this, I propose to: * Add a `Requests_Exception_InvalidArgument` class which extends the PHP native `InvalidArgumentException`. * Add input validation for the `$data` parameter to both the `cURL` as well as the `fsockopen` Transport class which maintains and stabilizes the pre-existing behaviour for handling of `null`, synchronizes the behaviour for integers and floats to be the same across `fsockopen` and `cURL`, but will throw the new `InvalidArgument` exception for any other type of unexpected input for the `$data` parameter. Includes additional tests covering this change.
jrfnl
added a commit
that referenced
this issue
Jun 21, 2021
…cURL)` PHP 8.1 deprecates passing `null` to non-nullable parameters for PHP native functions. Ref: https://wiki.php.net/rfc/deprecate_null_to_scalar_internal_arg The `Requests_Transport_fsockopen::request()` method passes `$request_body` into the PHP native `strlen()` function without sufficient validation, which on PHP 8.1 results in a `strlen(): Passing null to parameter #1 ($string) of type string is deprecated` notification. The existing `RequestsTest_Transport_Base::testEmptyPOST()` test method exposed this. When investigating this issue, I realized that no significant input validation was being done on the `$data` parameter. PR 368 in response to issue 248 added a test to verify that the "content-length" header was correctly set when `null` would be passed as `$data` and added a safe-guard specifically for when `null` would be passed. Also, as a matter of form, integers and floats were handled correctly for `fsockopen`, but anything else would lead to PHP errors in unexpected places in every supported PHP version, including integers and floats in combination with the `cURL` class. To mitigate this, I propose to: * Add a `Requests_Exception_InvalidArgument` class which extends the PHP native `InvalidArgumentException`. * Add input validation for the `$data` parameter to both the `cURL` as well as the `fsockopen` Transport class which maintains and stabilizes the pre-existing behaviour for handling of `null`, synchronizes the behaviour for integers and floats to be the same across `fsockopen` and `cURL`, but will throw the new `InvalidArgument` exception for any other type of unexpected input for the `$data` parameter. Includes additional tests covering this change.
jrfnl
added a commit
that referenced
this issue
Jun 21, 2021
…cURL)` PHP 8.1 deprecates passing `null` to non-nullable parameters for PHP native functions. Ref: https://wiki.php.net/rfc/deprecate_null_to_scalar_internal_arg The `Requests_Transport_fsockopen::request()` method passes `$request_body` into the PHP native `strlen()` function without sufficient validation, which on PHP 8.1 results in a `strlen(): Passing null to parameter #1 ($string) of type string is deprecated` notification. The existing `RequestsTest_Transport_Base::testEmptyPOST()` test method exposed this. When investigating this issue, I realized that no significant input validation was being done on the `$data` parameter. PR 368 in response to issue 248 added a test to verify that the "content-length" header was correctly set when `null` would be passed as `$data` and added a safe-guard specifically for when `null` would be passed. Also, as a matter of form, integers and floats were handled correctly for `fsockopen`, but anything else would lead to PHP errors in unexpected places in every supported PHP version, including integers and floats in combination with the `cURL` class. To mitigate this, I propose to: * Add a `Requests_Exception_InvalidArgument` class which extends the PHP native `InvalidArgumentException`. * Add input validation for the `$data` parameter to both the `cURL` as well as the `fsockopen` Transport class which maintains and stabilizes the pre-existing behaviour for handling of `null`, synchronizes the behaviour for integers and floats to be the same across `fsockopen` and `cURL`, but will throw the new `InvalidArgument` exception for any other type of unexpected input for the `$data` parameter. Includes additional tests covering this change.
jrfnl
added a commit
that referenced
this issue
Jul 24, 2021
…cURL)` PHP 8.1 deprecates passing `null` to non-nullable parameters for PHP native functions. Ref: https://wiki.php.net/rfc/deprecate_null_to_scalar_internal_arg The `Requests_Transport_fsockopen::request()` method passes `$request_body` into the PHP native `strlen()` function without sufficient validation, which on PHP 8.1 results in a `strlen(): Passing null to parameter #1 ($string) of type string is deprecated` notification. The existing `RequestsTest_Transport_Base::testEmptyPOST()` test method exposed this. When investigating this issue, I realized that no significant input validation was being done on the `$data` parameter. PR 368 in response to issue 248 added a test to verify that the "content-length" header was correctly set when `null` would be passed as `$data` and added a safe-guard specifically for when `null` would be passed. Also, as a matter of form, integers and floats were handled correctly for `fsockopen`, but anything else would lead to PHP errors in unexpected places in every supported PHP version, including integers and floats in combination with the `cURL` class. To mitigate this, I propose to: * Add a `Requests_Exception_InvalidArgument` class which extends the PHP native `InvalidArgumentException`. * Add input validation for the `$data` parameter to both the `cURL` as well as the `fsockopen` Transport class which maintains and stabilizes the pre-existing behaviour for handling of `null`, synchronizes the behaviour for integers and floats to be the same across `fsockopen` and `cURL`, but will throw the new `InvalidArgument` exception for any other type of unexpected input for the `$data` parameter. Includes additional tests covering this change.
jrfnl
added a commit
that referenced
this issue
Jul 30, 2021
…cURL)` PHP 8.1 deprecates passing `null` to non-nullable parameters for PHP native functions. Ref: https://wiki.php.net/rfc/deprecate_null_to_scalar_internal_arg The `Requests_Transport_fsockopen::request()` method passes `$request_body` into the PHP native `strlen()` function without sufficient validation, which on PHP 8.1 results in a `strlen(): Passing null to parameter #1 ($string) of type string is deprecated` notification. The existing `RequestsTest_Transport_Base::testEmptyPOST()` test method exposed this. When investigating this issue, I realized that no significant input validation was being done on the `$data` parameter. PR 368 in response to issue 248 added a test to verify that the "content-length" header was correctly set when `null` would be passed as `$data` and added a safe-guard specifically for when `null` would be passed. Also, as a matter of form, integers and floats were handled correctly for `fsockopen`, but anything else would lead to PHP errors in unexpected places in every supported PHP version, including integers and floats in combination with the `cURL` class. To mitigate this, I propose to: * Add a `Requests_Exception_InvalidArgument` class which extends the PHP native `InvalidArgumentException`. * Add input validation for the `$data` parameter to both the `cURL` as well as the `fsockopen` Transport class which maintains and stabilizes the pre-existing behaviour for handling of `null`, synchronizes the behaviour for integers and floats to be the same across `fsockopen` and `cURL`, but will throw the new `InvalidArgument` exception for any other type of unexpected input for the `$data` parameter. Includes additional tests covering this change.
jrfnl
added a commit
that referenced
this issue
Jun 26, 2023
The `error_get_last()` function can return `null` if no error occurred, in which case, the `throw new Exception()` statement will run into two new errors: * `Trying to access array offset on value of type null` for accessing `$error['message']`. * ... which then leads to a `Exception::__construct(): Passing null to parameter #1 ($message) of type string is deprecated`. This commit adds some defensive coding to handle the hypothetical situation that `error_get_last()` would return `null` when a file could not be opened. Note: I actually suspect this is a bug in PHPUnit 10, but need to investigate further to be sure. In the mean time, our test shouldn't fail on it.
jrfnl
added a commit
that referenced
this issue
Jun 26, 2023
The `error_get_last()` function can return `null` if no error occurred, in which case, the `throw new Exception()` statement will run into two new errors: * `Trying to access array offset on value of type null` for accessing `$error['message']`. * ... which then leads to a `Exception::__construct(): Passing null to parameter #1 ($message) of type string is deprecated`. This commit adds some defensive coding to handle the hypothetical situation that `error_get_last()` would return `null` when a file could not be opened. Note: this is actually a bug in PHPUnit 10 which breaks `error_get_last()`. We should be able to remove the extra defensive coding once the upstream bug has been fixed. Upstream bug report: sebastianbergmann/phpunit#5428
jrfnl
added a commit
that referenced
this issue
Jun 26, 2023
The `error_get_last()` function can return `null` if no error occurred, in which case, the `throw new Exception()` statement will run into two new errors: * `Trying to access array offset on value of type null` for accessing `$error['message']`. * ... which then leads to a `Exception::__construct(): Passing null to parameter #1 ($message) of type string is deprecated`. This commit adds some defensive coding to handle the hypothetical situation that `error_get_last()` would return `null` when a file could not be opened. Note: this is actually a bug in PHPUnit 10 which breaks `error_get_last()`. We should be able to remove the extra defensive coding once the upstream bug has been fixed. Upstream bug report: sebastianbergmann/phpunit#5428
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
No description provided.
The text was updated successfully, but these errors were encountered: