php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #79575 Content-Length header name is getting corrupted
Submitted: 2020-05-08 16:59 UTC Modified: 2020-05-11 08:56 UTC
Votes:3
Avg. Score:4.3 ± 0.9
Reproduced:2 of 2 (100.0%)
Same Version:1 (50.0%)
Same OS:2 (100.0%)
From: kevin dot seymour at gmail dot com Assigned:
Status: Verified Package: OpenSSL related
PHP Version: 7.3 OS: *
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: kevin dot seymour at gmail dot com
New email:
PHP Version: OS:

 

 [2020-05-08 16:59 UTC] kevin dot seymour at gmail dot com
Description:
------------
When you run the below script you'll see the Content-Length header will come back with the correct value, but that the word Content is jumbled.  For example:

Cteonnt-Length: 195628.

If you change Accept-Encoding to identity (disable compression) the value comes back correctly.  This is causing unexpected end of data errors when we use SoapClient to attempt to parse a WSDL as only part of the XML is returned.

There is a lot of testing information here:

https://stackoverflow.com/questions/61681804/php-file-get-contents-returning-inconsistent-partial-data-for-http-requests

Test script:
---------------
php << 'EOF'
<?php
$ctx = stream_context_create(array(
    'http' => array(
        'header' => "Accept-Encoding: gzip"
     )
));
$xml = file_get_contents('https://webservices3.autotask.net/atservices/1.6/atws.wsdl', false, $ctx);
echo var_dump($http_response_header);
?>
EOF

Expected result:
----------------
Content-Length should remain with the same header name.

Actual result:
--------------
Content-Length header field name is corrupted.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2020-05-09 13:32 UTC] cmb@php.net
-Status: Open +Status: Verified -Package: *Compression related +Package: OpenSSL related -Operating System: RHEL +Operating System: * -PHP Version: 7.2.30 +PHP Version: 7.3
 [2020-05-09 13:32 UTC] cmb@php.net
Apparently, the respective SSL_read() call[1] yields the broken
contents. 

[1] <https://github.com/php/php-src/blob/php-7.3.17/ext/openssl/xp_ssl.c#L2099>
 [2020-05-11 08:00 UTC] nikic@php.net
This is pretty weird. If the corrupted output comes from SSL_read(), then I don't think the problem here can be on the PHP side, right?
 [2020-05-11 08:56 UTC] cmb@php.net
I'm not sure whether we prepare SSL correctly for this case.
 [2020-07-15 02:58 UTC] kevin dot seymour at gmail dot com
Is there additional information required to diagnose this issue completely? Was it determined if this was indeed an OpenSSL issue?
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved.
Last updated: Mon Mar 10 21:01:30 2025 UTC