Please provide instructions how this can be tested

On 26 November 2014 at 11:35, laoneo notifications@github.com wrote:

Curl needs the accepted encoding header set as curl option and not only as

header.

You can merge this Pull Request by running

git pull https://github.com/laoneo/joomla-cms patch-4

Or view, comment on, or merge it at:

#5210
Commit Summary

• Handle accepted encoding in curl correct

File Changes

• M libraries/joomla/http/transport/curl.php https://github.com/joomla/joomla-cms/pull/5210/files#diff-0 (6)

Patch Links:

• https://github.com/joomla/joomla-cms/pull/5210.patch
• https://github.com/joomla/joomla-cms/pull/5210.diff

—
Reply to this email directly or view it on GitHub
#5210.

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

sorry but you cant test your own code. we assume you would never submit untested code


This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/5210.

Please fix the codestyle issue that Travis is complaining about.

Where can I find out what for a code style is wrong? It is a three line change, so there is not much room to make a mistake.

click on the details link and select one of the testruns and then scroll to the bottom.

Done....

@laoneo I have tested this with the code

$options = new JRegistry();
$http = new JHttp($options, new JHttpTransportCurl($options));
$content = $http->get(
    'https://www.google.com/calendar/ical/en.dutch%23holiday%40group.v.calendar.google.com/public/basic.ics', array('Accept-Encoding'=>'deflate'))->body;
echo $content;die;

Without the patch I see the calendar content and with the patch I see the calendar content. So it seems the patch is not needed.

Google doesn't deliver gzip compressed content. But I created a test calendar on my private iCloud account which I published. I've updated the test instructions, you can ad the code now as it is without searching for an iCloud url. Thanks for your help.

@laoneo I have taken the updated code (fixed the url as it started with ihttps ;) ) and added it to the content.php file. Without or with the patch, I always see the calendar data. So I can't reproduce the issue.

@roland-d strange, perhaps some different server settings. Hopefully some others will be able to reproduce the issue. Thanks for your help so far.

I have tested this again on a Mac and now I am able to reproduce the issue. Gzipped data is shown before the patch and regular calendar data after applying the patch. Test is succesfull.

@laoneo Unfortunately this cant be tested anymore because you have deleted your branch. Please resolve this or this will have to be closed.

@brianteeman It can be tested but it's a bit more cumbersome, you would have to change the file manually with the same changes as shown on the "Files changed" tab.

We can still merge it even though the branch is gone.

I have tested this item successfully on 5584223

I dont understand this or why we need it but I can confirm it does what it says as stated by @roland-d

With my test and Rolands I am setting this RTC and someone else can decide if this is needed or not

As for me I don't see an issue having this option. It enables another cURL option to be configured when sending a request.

From the PHP manual:

CURLOPT_ENCODING The contents of the "Accept-Encoding: " header. This enables decoding of the response. Supported encodings are "identity", "deflate", and "gzip". If an empty string, "", is set, a header containing all supported encoding types is sent.

I can recreate the branch with the patch if needed.

I "think" that will make it easier to be merged - not sure - but no harm

On 13 April 2016 at 11:29, Allon Moritz notifications@github.com wrote:

I can recreate the branch with the patch if needed.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#5210 (comment)

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/