. Fix POST when you use content to send your data and not parameters
. use of ``null !==`` instead of ``!is_null()``
Removing unnecessary strtoupper on request method
merged branch mtdowling/master (PR #56)

Commits
-------

cda7c1f Removing unnecessary strtoupper on request method

Discussion
----------

Removing unnecessary strtoupper on request method
Updating Guzzle version and POST unit test
Updating composer.lock
Updated phar
merged branch mtdowling/post_fix (PR #57)

Commits
-------

437edb9 Updating Guzzle version and POST unit test Updating composer.lock Updated phar

Discussion
----------

Updating Guzzle version and POST unit test

Updating to [latest version of Guzzle](https://github.com/guzzle/guzzle/blob/master/CHANGELOG.md).  Updating dependencies because some of the commits referenced in the old composer.lock file no longer exist.
Use CURLAUTH_BASIC instead of GuzzleRequestInterface::AUTH_BASIC as this is what $guzzleRequest->setAuth() expects
merged branch fabian/patch-1 (PR #58)

Commits
-------

f0d6027 Use CURLAUTH_BASIC instead of GuzzleRequestInterface::AUTH_BASIC as this is what $guzzleRequest->setAuth() expects

Discussion
----------

Use CURLAUTH_BASIC instead of GuzzleRequestInterface::AUTH_BASIC

This is what $guzzleRequest->setAuth() expects: https://github.com/guzzle/guzzle/blob/master/src/Guzzle/Http/Message/Request.php#L493
removed unused `use`
Merge remote-tracking branch 'upstream/master' into postContentFix
. Split of the line of the previou patch for readability
. Fixed coding standards with php-cs-fixer
enabled PHP extension cURL is a requirement
merged branch jakoch/patch-2 (PR #64)

Commits
-------

20a64e6 enabled PHP extension cURL is a requirement

Discussion
----------

enabled PHP extension cURL is a requirement

Changes done as per feedback. (New Pull Request, because i deleted my fork already.)
merged branch lyrixx/patch-1 (PR #61)

Commits
-------

83259b8 removed unused `use`

Discussion
----------

removed unused `use`
merged branch JEDIBC/postContentFix (PR #55)

Commits
-------

5da05f5 . Split of the line of the previou patch for readability . Fixed coding standards with php-cs-fixer
35209eb Merge remote-tracking branch 'upstream/master' into postContentFix
ec33307 . use of ``null !==`` instead of ``!is_null()``
f757aea . Fix POST when you use content to send your data and not parameters

Discussion
----------

Fix POST when you use content to send your data and not parameters

Sometimes, you have to use $request->content to POST your datas instead of $request->parameters (for example sending a soap request)

---------------------------------------------------------------------------

by JEDIBC at 2012-05-24T12:25:37Z

Basically I need to crawl a crappy aspx website which take POST datas like : a=1&b=2&b=3&b=4 (multiple checkbox).
So I use content instead of parameters which worked when the http client was the ZF2 one.
updated the phar
removed the phar from the bin section of the compoesr file (closes #65)
Upgrading guzzle dependency to 2.8.*, fixes #70
Use guzzle/http instead of guzzle/guzzle, refs #70
merged branch BRMatt/upgrade-guzzle (PR #71)

Commits
-------

f8bcc3c Use guzzle/http instead of guzzle/guzzle, refs #70
244e4c2 Upgrading guzzle dependency to 2.8.*, fixes #70

Discussion
----------

Upgrading guzzle dependency to 2.8.*, fixes #70

Fixes #70

---------------------------------------------------------------------------

by fabpot at 2012-07-19T14:09:45Z

Would it be possible to switch to guzzle/http only instead of the full guzzle/guzzle package? What do you think @mtdowling

---------------------------------------------------------------------------

by stof at 2012-07-19T14:55:16Z

@fabpot apparently, ``guzzle/http`` depends on ``guzzle/common`` and ``guzzle/parser``, meaning you will still use the whole guzzle.

---------------------------------------------------------------------------

by mtdowling at 2012-07-19T15:32:24Z

Actually, switching to guzzle/http means you don't have to include the Guzzle/Service namespace. Seems like a good idea to me.

On Jul 19, 2012, at 7:55 AM, Christophe Coevoet<reply@reply.github.com> wrote:

> @fabpot apparently, ``guzzle/http`` depends on ``guzzle/common`` and ``guzzle/parser``, meaning you will still use the whole guzzle.
>
> ---
> Reply to this email directly or view it on GitHub:
> https://github.com/fabpot/Goutte/pull/71#issuecomment-7100479

---------------------------------------------------------------------------

by stof at 2012-07-19T15:45:08Z

@mtdowling guzzle/service is not available as a separate package ?

---------------------------------------------------------------------------

by mtdowling at 2012-07-19T16:41:22Z

Right, because it would be redundant; a guzzle/service package would require everything, so I left it out.

On Jul 19, 2012, at 8:45 AM, Christophe Coevoet<reply@reply.github.com> wrote:

> @mtdowling guzzle/service is not available as a separate package ?
>
> ---
> Reply to this email directly or view it on GitHub:
> https://github.com/fabpot/Goutte/pull/71#issuecomment-7102007

---------------------------------------------------------------------------

by BRMatt at 2012-07-24T08:29:18Z

@fabpot Would you like me to update the PR to use guzzle/http?

---------------------------------------------------------------------------

by fabpot at 2012-07-24T08:35:27Z

If possible, yes. Thanks.

---------------------------------------------------------------------------

by BRMatt at 2012-07-24T16:03:32Z

@fabpot Pushed the change

---------------------------------------------------------------------------

by mtdowling at 2012-07-24T17:23:21Z

Do we need to ship the composer.lock file with Goutte? If I remember correctly, this has caused multiple issues in the past. What's the benefit of the composer.lock file vs well defined dependencies in composer.json?

---------------------------------------------------------------------------

by stof at 2012-07-24T17:35:53Z

@mtdowling shipping the lock file with goutte is useless IMO: it would only be used when installing the vendors in goutte, i.e. when running its testsuite, not when installing it as a dependency

---------------------------------------------------------------------------

by BRMatt at 2012-07-24T23:07:00Z

@stof Surely that's a good enough reason to commit a lock file? You want to ensure that everybody running the test suite is using the same environment. Having a well configured composer.json file (I assume you mean explicit versioning) isn't enough, as being too explicit can cause dependency hell when different gems require similar versions of the same dependencies, or as in this case, you need bugfixes found in the latest version of the package's dependencies.

The composer documentation also recommends committing the file.

---------------------------------------------------------------------------

by stof at 2012-07-24T23:10:01Z

@BRMatt if you lock the testsuite to an older version than the one selected by composer by default with your constraint, it means you are testing against a version different than the one used by your users.
And composer recommends to commit it for projects, where you indeed want to lock the vendors.