WordPress / WordPress/Requests
cURL incompatibility with Kaspersky (kesl)
Nobody has claimed this yet.
- Dominant language
- PHP
- Stars
- 3.6k
- Forks
- 500
- Avg merge
- 2d 21h
- Merged PRs (30d)
- 5
Description
Summary
I'm facing an issue with some servers having kesl service (Kaspersky) installed and running.
Sometimes wp_remote_* calls fails with error:
Scaricamento del pacchetto di installazione da https://downloads.wordpress.org/plugin/jetpack.10.1.zip...
Warning: Il download non è andato a buon fine. "cURL error 18: transfer closed with 332690 bytes remaining to read"
The number of bytes is completely randomic.
Since it's not consistent, I've prepared this script to be run over and over (without wp-cli cache of course):
while :; do wp plugin install jetpack && wp plugin delete jetpack && rm -rf /root/.wp-cli/cache/*; done
After digging a lot into WpOrg\Requests\Transport\cURL implementation I've found these lines being the cause of the issue:
<?php
// Force closing the connection for old versions of cURL (<7.22).
if (!isset($headers['Connection'])) {
$headers['Connection'] = 'close';
}
Disabling these lines, the issue disappear. Why aren't we checking the cURL version here?
I would then suggest these changes:
- Add a new const const CURL_7_22_0 = 0x071600
- Check the version and add that header only if needed
Your environment
| Environment | Answer |
|---|---|
| Operating system and version (e.g. Ubuntu 20.04, CentOS, tried both) | |
| PHP version | 7.4 (tried others as well) |
| Requests version | provided with WordPress latest |
| Autoloader used | WordPress |
| Link to your project | into a vpn, not accessible through the internet |
Tested against develop branch?
- I have verified the issue still exists in the
developbranch of Requests.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start at the WpOrg\Requests\Transport\cURL implementation used by wp_remote_* calls and inspect the Connection header logic alongside the available cURL version. Verify the behavior against the reported Kaspersky kesl transfer failure; done means the header is conditional for older cURL versions and the existing download path remains functional.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- php
- Domain
- networking
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100