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
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
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-2024 The PHP Group
All rights reserved.
Last updated: Tue Oct 15 09:01:26 2024 UTC