zlib_decode(): data error

[Ugoku]

I realise this issue has been raised before (#3006, #3270) but no replies were given there and the results are many months old. Since a while, I'm getting the error mentioned in the issue title, when doing a composer require xxx/yyy or composer install Stack trace from the "very verbose" mode is as follows:

  [ErrorException]
  zlib_decode(): data error

Exception trace:
 () at phar://C:/ProgramData/ComposerSetup/bin/composer.phar/src/Composer/Util/RemoteFilesystem.php:218
 Composer\Util\ErrorHandler::handle() at n/a:n/a
 zlib_decode() at phar://C:/ProgramData/ComposerSetup/bin/composer.phar/src/Composer/Util/RemoteFilesystem.php:218
 Composer\Util\RemoteFilesystem->get() at phar://C:/ProgramData/ComposerSetup/bin/composer.phar/src/Composer/Util/Remote
Filesystem.php:83
 Composer\Util\RemoteFilesystem->getContents() at phar://C:/ProgramData/ComposerSetup/bin/composer.phar/src/Composer/Rep
ository/ComposerRepository.php:587
 Composer\Repository\ComposerRepository->fetchFile() at phar://C:/ProgramData/ComposerSetup/bin/composer.phar/src/Compos
er/Repository/ComposerRepository.php:296
 Composer\Repository\ComposerRepository->whatProvides() at phar://C:/ProgramData/ComposerSetup/bin/composer.phar/src/Com
poser/DependencyResolver/Pool.php:191
 Composer\DependencyResolver\Pool->computeWhatProvides() at phar://C:/ProgramData/ComposerSetup/bin/composer.phar/src/Co
mposer/DependencyResolver/Pool.php:180
 Composer\DependencyResolver\Pool->whatProvides() at phar://C:/ProgramData/ComposerSetup/bin/composer.phar/src/Composer/
DependencyResolver/RuleSetGenerator.php:221
 Composer\DependencyResolver\RuleSetGenerator->addRulesForPackage() at phar://C:/ProgramData/ComposerSetup/bin/composer.
phar/src/Composer/DependencyResolver/RuleSetGenerator.php:293
 Composer\DependencyResolver\RuleSetGenerator->addRulesForJobs() at phar://C:/ProgramData/ComposerSetup/bin/composer.pha
r/src/Composer/DependencyResolver/RuleSetGenerator.php:333
 Composer\DependencyResolver\RuleSetGenerator->getRulesFor() at phar://C:/ProgramData/ComposerSetup/bin/composer.phar/sr
c/Composer/DependencyResolver/Solver.php:172
 Composer\DependencyResolver\Solver->solve() at phar://C:/ProgramData/ComposerSetup/bin/composer.phar/src/Composer/Insta
ller.php:505
 Composer\Installer->doInstall() at phar://C:/ProgramData/ComposerSetup/bin/composer.phar/src/Composer/Installer.php:230

 Composer\Installer->run() at phar://C:/ProgramData/ComposerSetup/bin/composer.phar/src/Composer/Command/RequireCommand.
php:158
 Composer\Command\RequireCommand->execute() at phar://C:/ProgramData/ComposerSetup/bin/composer.phar/vendor/symfony/cons
ole/Symfony/Component/Console/Command/Command.php:257
 Symfony\Component\Console\Command\Command->run() at phar://C:/ProgramData/ComposerSetup/bin/composer.phar/vendor/symfon
y/console/Symfony/Component/Console/Application.php:874
 Symfony\Component\Console\Application->doRunCommand() at phar://C:/ProgramData/ComposerSetup/bin/composer.phar/vendor/s
ymfony/console/Symfony/Component/Console/Application.php:195
 Symfony\Component\Console\Application->doRun() at phar://C:/ProgramData/ComposerSetup/bin/composer.phar/src/Composer/Co
nsole/Application.php:146
 Composer\Console\Application->doRun() at phar://C:/ProgramData/ComposerSetup/bin/composer.phar/vendor/symfony/console/S
ymfony/Component/Console/Application.php:126
 Symfony\Component\Console\Application->run() at phar://C:/ProgramData/ComposerSetup/bin/composer.phar/src/Composer/Cons
ole/Application.php:82
 Composer\Console\Application->run() at phar://C:/ProgramData/ComposerSetup/bin/composer.phar/bin/composer:43
 require() at C:\ProgramData\ComposerSetup\bin\composer.phar:25

Any thoughts on why this happens and/or how to fix it? I'm only getting this on one of my systems, and it worked fine in the past, I'm not sure what changed since. I have reinstalled Composer just now, so I'm using the latest version. Specs of my system: Windows 8.1 x64, PHP 5.6.5 x64

Edit: when I require a new dependency on an other machine, then run composer install on my own system, that works just fine.

Edit 2: I just noticed Composer is connecting to http://packagist.org, despite having openssl enabled.

[alcohol]

Please, share more useful information. What are you installing for example (your composer.json), etc.

[Ugoku]

It doesn't matter what I try to install, everything fails. But in the case today, I did composer require knplabs/knp-snappy My composer.json (stripped to its bare essentials, but still failing):

{
  "require": {
    "knplabs/knp-snappy": "^0.4.0",
    "h4cc/wkhtmltopdf-amd64": "0.12.0"
  },
  "autoload": {
    "psr-4": {
      "Application\\": "Application"
    }
  }
}

[alcohol]

Can you try running composer config --global repositories.packagist.allow_ssl_downgrade false and then try to install or update again?

[nevvermind]

That composer.json works fine for me.

@Ugoku - installing with debug verbosity - composer install -vvv will output something like this:

Downloading https://api.github.com/repos/h4cc/wkhtmltopdf-amd64/zipball/ebaa56a8ba0ae70a147ee70d544abf743db290d3
    Downloading: 100%
Writing /Users/user/.composer/cache/files/h4cc/wkhtmltopdf-amd64/ebaa56a8ba0ae70a147ee70d544abf743db290d3.zip into cache

See if the URL is working or the zip file is valid.

[alcohol]

The difference is you are on OSX, and he is on Windows. Also he is falling back to http, and you are using https. Hence why I am asking him to try my config change.

[nevvermind]

Why would the OS matter when you're talking URLs and files? How do you know he's using http?

[alcohol]

The OS difference should not matter, but should not and does not are not exactly the same and there is no guarantee. It is after all, Windows.

As for knowing that he is using http (not https), because he said so.

[Ugoku]

@alcohol: after changing that config setting and running composer update -vvv again, I get exactly the same error as in my opening post :(

In the verbose output, it says this (in order):

Downloading https://packagist.org/packages.json
(some "Reading xxx from cache" stripped)
Reading C:/Users/Sander/AppData/Local/Composer/repo/https---packagist.org/provider-symfony$process.json from cache
Reading C:/Users/Sander/AppData/Local/Composer/repo/https---packagist.org/provider-cilex$cilex.json from cache
Reading C:/Users/Sander/AppData/Local/Composer/repo/https---packagist.org/provider-erusev$parsedown.json from cache
Reading C:/Users/Sander/AppData/Local/Composer/repo/https---packagist.org/provider-monolog$monolog.json from cache
Downloading http://packagist.org/p/symfony/config$b1c50ac649cbb1d1952965df19066f264a56e227694a6105e42a853499b64e77.json
Downloading http://packagist.org/p/symfony/config$b1c50ac649cbb1d1952965df19066f264a56e227694a6105e42a853499b64e77.json
Downloading http://packagist.org/p/symfony/config$b1c50ac649cbb1d1952965df19066f264a56e227694a6105e42a853499b64e77.json
Reading C:/Users/Sander/AppData/Local/Composer/repo/https---packagist.org/provider-symfony$config.json from cache
Reading C:/Users/Sander/AppData/Local/Composer/repo/https---packagist.org/provider-symfony$config.json from cache
zlib_decode(): data error
http://packagist.org could not be fully loaded, package information was loaded from the local cache and may be out of date
(some more Reading xxx from cache)
Downloading http://packagist.org/p/zendframework/zend-cache$7aff615084f7758fef3e699ffeacd289c0f39b13a27577645960c13b94955d14.json
(Bunch of Downloading/Reading lines stripped)
Downloading http://packagist.org/p/guzzle/batch$49f7767b8e6b6c1211f57539881d28350e506bae2c4c21df5e22be9a4838cf30.json

  [Composer\Downloader\TransportException]
  The "http://packagist.org/p/guzzle/batch$49f7767b8e6b6c1211f57539881d28350e506bae2c4c21df5e22be9a4838cf30.json" fil
  e could not be downloaded: failed to open stream: HTTP request failed!

Exception trace:
 () at phar://C:/ProgramData/ComposerSetup/bin/composer.phar/src/Composer/Util/RemoteFilesystem.php:267
 Composer\Util\RemoteFilesystem->get() at phar://C:/ProgramData/ComposerSetup/bin/composer.phar/src/Composer/Util/Remote
Filesystem.php:83
 Composer\Util\RemoteFilesystem->getContents() at phar://C:/ProgramData/ComposerSetup/bin/composer.phar/src/Composer/Rep
ository/ComposerRepository.php:587
 Composer\Repository\ComposerRepository->fetchFile() at phar://C:/ProgramData/ComposerSetup/bin/composer.phar/src/Compos
er/Repository/ComposerRepository.php:296
 Composer\Repository\ComposerRepository->whatProvides() at phar://C:/ProgramData/ComposerSetup/bin/composer.phar/src/Com
poser/DependencyResolver/Pool.php:191
 Composer\DependencyResolver\Pool->computeWhatProvides() at phar://C:/ProgramData/ComposerSetup/bin/composer.phar/src/Co
mposer/DependencyResolver/Pool.php:180
 Composer\DependencyResolver\Pool->whatProvides() at phar://C:/ProgramData/ComposerSetup/bin/composer.phar/src/Composer/
DependencyResolver/RuleSetGenerator.php:221
 Composer\DependencyResolver\RuleSetGenerator->addRulesForPackage() at phar://C:/ProgramData/ComposerSetup/bin/composer.
phar/src/Composer/DependencyResolver/RuleSetGenerator.php:330
 Composer\DependencyResolver\RuleSetGenerator->getRulesFor() at phar://C:/ProgramData/ComposerSetup/bin/composer.phar/sr
c/Composer/DependencyResolver/Solver.php:172
 Composer\DependencyResolver\Solver->solve() at phar://C:/ProgramData/ComposerSetup/bin/composer.phar/src/Composer/Insta
ller.php:505
 Composer\Installer->doInstall() at phar://C:/ProgramData/ComposerSetup/bin/composer.phar/src/Composer/Installer.php:230

 Composer\Installer->run() at phar://C:/ProgramData/ComposerSetup/bin/composer.phar/src/Composer/Command/UpdateCommand.p
hp:140
 Composer\Command\UpdateCommand->execute() at phar://C:/ProgramData/ComposerSetup/bin/composer.phar/vendor/symfony/conso
le/Symfony/Component/Console/Command/Command.php:257
 Symfony\Component\Console\Command\Command->run() at phar://C:/ProgramData/ComposerSetup/bin/composer.phar/vendor/symfon
y/console/Symfony/Component/Console/Application.php:874
 Symfony\Component\Console\Application->doRunCommand() at phar://C:/ProgramData/ComposerSetup/bin/composer.phar/vendor/s
ymfony/console/Symfony/Component/Console/Application.php:195
 Symfony\Component\Console\Application->doRun() at phar://C:/ProgramData/ComposerSetup/bin/composer.phar/src/Composer/Co
nsole/Application.php:146
 Composer\Console\Application->doRun() at phar://C:/ProgramData/ComposerSetup/bin/composer.phar/vendor/symfony/console/S
ymfony/Component/Console/Application.php:126
 Symfony\Component\Console\Application->run() at phar://C:/ProgramData/ComposerSetup/bin/composer.phar/src/Composer/Cons
ole/Application.php:82
 Composer\Console\Application->run() at phar://C:/ProgramData/ComposerSetup/bin/composer.phar/bin/composer:43
 require() at C:\ProgramData\ComposerSetup\bin\composer.phar:25

After which Composer exits.

Notice the first line says "Downloading https://packagist.org/packages.json" and subsequent cache readings use the repo/https---packagist.org folder, but then it switches to "Downloading http://packagist.org/p/symfony/config$b1c50ac649cbb1d1952965df19066f264a56e227694a6105e42a853499b64e77.json"

@nevvermind: To clarify my HTTP/HTTPS statement: when I run composer update (NOT in verbose mode), the error is "http://packagist.org could not be fully loaded, package information was loaded from the local cache and may be out of date". Looking in the Composer source, this is not a hardcoded error but really is the URL that is used.

If I disable the openssl extension for PHP and remove the allow_ssl_downgrade part from config.json, I get the same error as described in my opening post.

[alcohol]

Weird. Did you try running the command after doing a composer clear-cache ?

[Ugoku]

I had not, but have now. It's downloading a bunch of provider*.json files over HTTPS, until it gets to http://packagist.org/p/sebastian/global-state$b53387feba200d8b5e8edceb38f7ee998e77dcd375fcc64bf23bc511961af794.json which, as you can see, is loaded over HTTP. All files after that are downloaded over HTTP until it stops at http://packagist.org/p/symfony/finder$5faa85a87ad45dd50d43d33c64a3e2088fddc9373b2b582289bbc99fe95b3495.json to give the zlib error.

[Seldaek]

@Ugoku do you have a network proxy or something that could modify the http connections in some way? Because that could cause the zlib failure if the response body is fiddled with and it isn't valid gzip anymore.

[Ugoku]

Not that I know of... :P it works fine for my colleague in the same network, so there's no network proxy that does that. I also don't have the problem with any other program/website, it's only Composer.

Just tried this: Running curl -H "Accept-Encoding: gzip" -I http://packagist.org/p/symfony/finder$5faa85a87ad45dd50d43d33c64a3e2088fddc9373b2b582289bbc99fe95b3495.json gives a 302 Found with a redirect to the HTTPS equivalent, which in turn gives a 404 Not Found. I'm guessing that has something to do with it?

[Seldaek]

You get that redirect because the file doesn't exist anymore, so it hits symfony and symfony forces https and redirects, but then you get a 404 if you follow that redirect.

Could you install composer from source and check what's going on in the RemoteFilesystem when it fails with that zlib error? It's kinda hard for us to work on this if we can't reproduce it :/

[Ugoku]

Sorry, what do you mean by "install composer from source" ?

[alcohol]

cd /tmp
git clone git@github.com:composer/composer.git
cd composer
curl -sS https://getcomposer.org/installer | php
php composer.phar install
cd ..
/tmp/composer/bin/composer require -vvv xxx/yyy

You can modify the actual source files in /tmp/composer/src now and add more debugging statements wherever you require them. Every time you call /tmp/composer/bin/composer it will execute Composer with those modified source files, instead of running from a Phar binary.

[woodytang]

is there a conclusion yet? I had the exact same problem here, which is killing me...~~~ help!

[Ugoku]

Thanks @alcohol, I had to tweak it a bit (I'm on Windows :) ) to get it running, I generated composer.bat in the composer/bin folder with the following content:

@ECHO OFF
php "%~dp0composer" %*

Going to debug now, I'll keep you updated.

-edit- Okay, first thing I noticed:

[ErrorException]
Undefined variable: PHP_VERSION_ID

Which is quite odd, but not the source of the problem.

If I write $result to a file (before zlib_decode on line 218) it has the correct gzip header (0x1F, 0x8B) but decompressing the file (using PHP's zlib_decode, WinRAR, or 7-Zip) does not work. WinRAR and 7-Zip report the uncompressed file size as 2.504.067.759 bytes (2.5 GB!) whereas the actual file (https://packagist.org/p/symfony/finder$577ee87ebd6ba36e3412bda5920ca2713d3265429fd8523f0c1704025f9abb89.json, downloaded in a browser) is only 683 KB.

Would it help if I gave you the gzip file?

[alcohol]

That is weird. http://php.net/phpversion mentions nothing about that constant being OS dependent or anything. Merely that PHP_VERSION_ID is available as of PHP 5.2.7.

[peterpan666]

@woodytang and I had the same issue on a Mac and I've tested it on a vagrant machine, same problem

{
    "name": "laravel/laravel",
    "description": "The Laravel Framework.",
    "keywords": ["framework", "laravel"],
    "license": "MIT",
    "type": "project",
    "require": {
        "laravel/framework": "5.0.*",
        "xuma/laravel-amaran": "~1.0@dev",
        "baum/baum": "~1.1",
        "laracasts/presenter": "0.1.*",
        "nicolaslopezj/searchable": "1.*",
        "jenssegers/date": "~2.0",
        "guzzlehttp/guzzle": "6.0.1",
        "symfony/dom-crawler": "3.0.*@dev",
        "symfony/css-selector": "3.0.*@dev"

    },
    "require-dev": {
        "phpunit/phpunit": "~4.0",
        "phpspec/phpspec": "~2.1",
        "laracasts/generators": "dev-master",
        "barryvdh/laravel-ide-helper": "~2.0",
        "fzaninotto/faker": "1.5.*@dev",
        "codesleeve/laravel-stapler": "dev-master",
        "offline/persistent-settings": "dev-master",
        "way/generators": "dev-feature/laravel-five-stable"
    },
    "autoload": {
        "classmap": [
            "database"
        ],
        "psr-4": {
            "App\\": "app/"
        }
    },
    "autoload-dev": {
        "classmap": [
            "tests/TestCase.php"
        ]
    },
    "scripts": {
        "post-install-cmd": [
            "php artisan clear-compiled",
            "php artisan optimize"
        ],
        "post-update-cmd": [
            "php artisan clear-compiled",
            "php artisan ide-helper:generate",
            "php artisan optimize"
        ],
        "post-create-project-cmd": [
            "php -r \"copy('.env.example', '.env');\"",
            "php artisan key:generate"
        ]
    },
    "config": {
        "preferred-install": "dist"
    },

    "repositories": [
        {
            "packagist": false
        },
        {
            "type": "composer",
            "url": "http://packagist.cn"
        }
    ]

}

I've runned it without the repositories part and it seemed to work fine. @woodytang tried it again with the repositories part and it worked to...

Maybe a problem with server connection or something?...

[Seldaek]

@Ugoku it'd be interesting to get the file yes. Then I can also download it here and see if there is any difference.

[Ugoku]

@Seldaek: here you go :) https://www.dropbox.com/s/chz944upvye4zd1/result.gz?dl=0 This is for http://packagist.org/p/symfony/finder$577ee87ebd6ba36e3412bda5920ca2713d3265429fd8523f0c1704025f9abb89.json (Downloaded in browser and uploaded to https://www.dropbox.com/s/suz6fzdgvzhjrff/finder.json?dl=0)

@alcohol to make it even weirder: when I run it now, I don't get the error :/

[Seldaek]

@Ugoku ok so I compared yours and my cleanly downloaded one with curl -H 'Accept-Encoding:gzip' https://... - yours is exactly the same but truncated at 30377 bytes while mine is 41493 bytes.

[Seldaek]

Question is.. why would it be truncated without failing the file_get_contents call.

[Ugoku]

Did some more testing, every time Composer hits the zlib_decode code block, I output the URL and write the contents to a file with a unique filename. Result:

http://packagist.org/p/provider-2015-04$299ad23cd43cfbd7b6750ca1946f5d32297ca20ddefe30f59288b45aa0ddde0a.json http://packagist.org/p/provider-latest$c902af54b316e276d0f67ae7397acbd9f95e297085a53786c7379559fae2bedd.json http://packagist.org/p/symfony/finder$32c5233e919bcf365383bc5f656630fe7291654fcba9a8da89f2df5545b93194.json http://packagist.org/p/symfony/finder$32c5233e919bcf365383bc5f656630fe7291654fcba9a8da89f2df5545b93194.json http://packagist.org/p/symfony/finder$32c5233e919bcf365383bc5f656630fe7291654fcba9a8da89f2df5545b93194.json

It downloads the finder file 3 times, is that normal? All of them are corrupt and of different size (23085 bytes for the first, 18705 for the second, 20165 for the third) At first glance in a hex editor, they all look identical, except for the file size of course. The other files (provider-2015-04 and provider-latest) are larger in size, so it's not a size issue, and they decompress just fine.

[Seldaek]

That's because we retry 3 times in case of failed download, so yes when it starts going belly up it downloads the file again and again then fails, and they all look the same because they are the same. Except they're truncated at different points wherever the connection got dropped.

[Seldaek]

Could you print a timestamp on every request before/after the file_get_contents? nginx will close the connection after 20seconds if the body isn't fully sent to the client. Apart from that I can't think of what could go wrong on our end.

[Ugoku]

Ah, thanks for the clarification on the 3 downloads. Here's the full log of all file_get_contents calls when I run it now, with before/after microtime output:

./composer.json Before: 1434543152.6749 After: 1434543152.676

C:/Users/Sander/AppData/Roaming/Composer/composer.json Before: 1434543152.9187 After: 1434543152.92

Loading composer repositories with package information https://packagist.org/packages.json Before: 1434543153.3466 After: 1434543154.6304

Updating dependencies (including require-dev) http://packagist.org/p/provider-latest$df5bc15ec6faf00d160fe6d132679e7ffc29c7227d9d629716c32fe02fdf21c1.json Before: 1434543154.9412 After: 1434543155.1317

http://packagist.org/p/symfony/console$4ffb81d50a0e96344723a85c7c48e85719b27528c97365855690209a0e94538c.json Before: 1434543156.8442 After: 1434543156.9064

http://packagist.org/p/symfony/console$4ffb81d50a0e96344723a85c7c48e85719b27528c97365855690209a0e94538c.json Before: 1434543157.0114 After: 1434543157.085

http://packagist.org/p/symfony/console$4ffb81d50a0e96344723a85c7c48e85719b27528c97365855690209a0e94538c.json Before: 1434543157.1905 After: 1434543157.2729

They all download in < 0.1 second and the entire update takes less than 5 seconds, so nowhere near the 20 second timeout :(

[Seldaek]

And it's not all non-SSL requests failing since the provider-latest went through fine.

Maybe you should dump $http_response_header too to see if there is anything odd in there, but I doubt it.

What if you disable gzip (you can remove the header at line 409)? Do you fetch partial files as well then?

I am running out of ideas slowly :)

[alcohol]

@Seldaek can you share your nginx configuration? Just out of curiosity.

[Ugoku]

Nope, nothing odd in the headers as far as I can see. First one works, second one fails:

http://packagist.org/p/provider-latest$cf9f4ef31fc663282a889059600faa4bb57f47fed42f41fee943c597028d1363.json Array ( [0] => HTTP/1.1 200 OK [1] => Server: nginx [2] => Date: Wed, 17 Jun 2015 12:33:10 GMT [3] => Content-Type: application/json [4] => Last-Modified: Wed, 17 Jun 2015 12:32:14 GMT [5] => Connection: close [6] => Vary: Accept-Encoding [7] => ETag: W/"558168ce-a1e58" [8] => Content-Encoding: gzip ) http://packagist.org/p/symfony/console$4ffb81d50a0e96344723a85c7c48e85719b27528c97365855690209a0e94538c.json Array ( [0] => HTTP/1.1 200 OK [1] => Server: nginx [2] => Date: Wed, 17 Jun 2015 12:33:12 GMT [3] => Content-Type: application/json [4] => Last-Modified: Wed, 17 Jun 2015 08:12:16 GMT [5] => Connection: close [6] => Vary: Accept-Encoding [7] => ETag: W/"55812be0-ad219" [8] => Content-Encoding: gzip )

Disabling gzip works fine :| no corrupted files anymore..... So while it's a lot slower, I can at least use Composer again!

[alcohol]

I think @Seldaek would have preferred you showed the headers of the file that gets repeated multiple times. You are now showing the headers for two different files.

[Seldaek]

@Ugoku the main difference with gzip is that it switches to chunked encoding and removes the Content-Length header as it compresses the stream while sending it. So yeah the content length might help php know when to stop reading and not stop early for some obscure reason.. Although it still doesn't explain why it works with some files and not with others.

[Ugoku]

@alcohol the second one is the file that gets repeated 3 times. Headers are identical for each time: http://packagist.org/p/symfony/console$4ffb81d50a0e96344723a85c7c48e85719b27528c97365855690209a0e94538c.json Array ( [0] => HTTP/1.1 200 OK [1] => Server: nginx [2] => Date: Wed, 17 Jun 2015 12:33:12 GMT [3] => Content-Type: application/json [4] => Last-Modified: Wed, 17 Jun 2015 08:12:16 GMT [5] => Connection: close [6] => Vary: Accept-Encoding [7] => ETag: W/"55812be0-ad219" [8] => Content-Encoding: gzip ) http://packagist.org/p/symfony/console$4ffb81d50a0e96344723a85c7c48e85719b27528c97365855690209a0e94538c.json Array ( [0] => HTTP/1.1 200 OK [1] => Server: nginx [2] => Date: Wed, 17 Jun 2015 12:33:12 GMT [3] => Content-Type: application/json [4] => Last-Modified: Wed, 17 Jun 2015 08:12:16 GMT [5] => Connection: close [6] => Vary: Accept-Encoding [7] => ETag: W/"55812be0-ad219" [8] => Content-Encoding: gzip ) http://packagist.org/p/symfony/console$4ffb81d50a0e96344723a85c7c48e85719b27528c97365855690209a0e94538c.json Array ( [0] => HTTP/1.1 200 OK [1] => Server: nginx [2] => Date: Wed, 17 Jun 2015 12:33:12 GMT [3] => Content-Type: application/json [4] => Last-Modified: Wed, 17 Jun 2015 08:12:16 GMT [5] => Connection: close [6] => Vary: Accept-Encoding [7] => ETag: W/"55812be0-ad219" [8] => Content-Encoding: gzip )

[alcohol]

It literally requests all 3 of them in the same second? Weird, I can't imagine why the request would terminate so sudden and quickly.

[Ugoku]

Yes, indeed that's exactly what happens... in this comment above I used microtime before and after each file_get_contents and they all fail within 0.1 second (small files, 120 Mb connection, so that seems to make sense)

[frederikbosch]

@Ugoku How about removing context? I mean: what happens if you create a seperate script and just run file_get_contents? This way you can isolate your problem to the specific code that fails.

[Seldaek]

@frederikbosch without context you don't get gzipped data though..

[frederikbosch]

@Seldaek Lol, I did not mean the stream context but the general composer application context. @Ugoku should be able to post a tiny script that exposes his problem. Then we are able to use that script to try to reproduce his problem.

At this stage we are guessing and giving suggestions based on thought. But there are too many external factors involved. By moving the failing lines to a seperate script these factors can be eliminated. Hence we can solve a specific problem.

[staabm]

@Ugoku do you run some type of antivirus software or firewall?

Do you access the internet through a http proxy?

[Ugoku]

@staabm: yes, I am running both antivirus and firewall normally, but disabling them has no effect. I am not accessing internet through a proxy.

@frederikbosch: I will get to that today, I'll let you know.

[sbuzonas]

@Ugoku I believe this gist should cover the context composer sets up.

[Ugoku]

Sorry, didn't get around to this yesterday. Thanks for the script @slbmeh, but when I use that I get a non-gzipped file back :/

I could try a clean install of WAMP and Composer, see if that helps...

[frederikbosch]

@Ugoku It would be interesting to see and know why this fails. Could you share the gist that is returning the non-gzipped file? And maybe you could figure out which parameters have changed compared to the original script in composer.

[Ugoku]

Sure, anything I can do to help! :)

Here it is I took @slbmeh's gist and changed it to the URL that was failing for me.

I also tried changing $options to match the options Composer uses, which are as follows:

Array
(
    [http] => Array
        (
            [protocol_version] => 1.1
            [header] => Array
                (
                    [0] => User-Agent: Composer/source (Windows NT; 6.2; PHP 5.6.5)
                    [1] => Accept-Encoding: gzip
                    [2] => Connection: close
                )
            [ignore_errors] => 1
        )
)

But that just does the same

[frederikbosch]

@Ugoku That gist turns 404 for me. Is the url correct? Maybe it changed.

[Ugoku]

Yes, the URL appears to change every so often. I'm guessing everything between $ and .json is a hash for caching?

Current URL is http://packagist.org/p/symfony/finder$a4bc31ef5d391952af0e7202b072f6d587ae89623277f89aefad0f9d49a9bc2c.json

[frederikbosch]

@Ugoku Try this script: https://gist.github.com/frederikbosch/27b0620e153d3d9b3116. The http header in the stream context must be a string. Tiny mistake by @slbmeh I guess. I also commented out the content type. Now at least you should have the correct headers. If I take strlen of the content. It says int(41528). How about yours?

[Ugoku]

Nope: int(31837)... If I run the script a couple of times, the file size varies every time but the end result is the same: a corrupt file. From stream_get_meta_data, $headers['eof'] is false and unread_bytes is > 0, if that helps.

[frederikbosch]

@Ugoku Interesting... could you share the exact output from this file https://gist.github.com/frederikbosch/af1e6225a56b6bbbe465? I am interested in the header results before and after fetching the stream contents.

[frederikbosch]

@Ugoku Mine is as follows https://gist.github.com/frederikbosch/6bf542c5b0fadea402e4.