It's a Monday morning and you push your first bit of code for the week. Suddenly all your Javascript tests start failing with crazy errors you've never seen before! And it's not just happening on one project! This post will hopefully help you track down the fix to the Bad Message 400 errors plaguing WebDriver.

by
Adam Bramley
/ 23 September 2019

Here at PreviousNext, we have automated processes to ensure our PHP images are updated on a weekly basis. On September 22nd 2019, that update included a version bump to the curl library from 7.65.1 to 7.66.0. This had a cascading effect which resulted in builds across all of our projects failing javascript tests running against selenium/standalone-chrome containers.

The errors looked something like this:

WebDriver\Exception\CurlExec: Webdriver http error: 400, payload :<h1>Bad Message 400</h1><pre>reason: Bad Content-Length</pre>

We were able to compare an old version of the PHP image (from a week ago) and track down that version change in CURL. But why was that failing? We didn't want to just go about pinning curl back to the old version and dusting our hands off.

Let's dive into the void (stacktrace)

WebDriver\Exception\CurlExec: Webdriver http error: 400, payload :<h1>Bad Message 400</h1><pre>reason: Bad Content-Length</pre>

/data/vendor/instaclick/php-webdriver/lib/WebDriver/Exception.php:155<br>/data/vendor/instaclick/php-webdriver/lib/WebDriver/AbstractWebDriver.php:132<br>/data/vendor/instaclick/php-webdriver/lib/WebDriver/AbstractWebDriver.php:218<br>/data/vendor/instaclick/php-webdriver/lib/WebDriver/Container.php:224<br>/data/vendor/behat/mink-selenium2-driver/src/Selenium2Driver.php:781<br>/data/vendor/behat/mink-selenium2-driver/src/Selenium2Driver.php:769<br>/data/vendor/behat/mink/src/Element/NodeElement.php:153

When inspecting the code through the above trace, we found that the instaclick/php-webdriver library was responsible for issuing the actual cURL command and was throwing the exception.

Op to the Rescue

When looking through the recent commits of the library, Nick Schuch noticed a suspicious commit that sounded a bit fishy. Sure enough, manually applying those changes got all the tests green again!

But how do we fix it for good? That's where it gets a bit tricky due to some composer constraints (as per usual).

Unfortunately the instaclick/php-webdriver library's HEAD is quite far aHEAD of the latest stable release (1.4.5), and we aren't able to simply bump to dev in our composer file due to behat/mink-selenium2-driver (a Drupal core dev requirement) constraining us to 1.x.

The Fix

The easiest approach for now is to commit a patch locally to your repository and manually patch it until the maintainer releases a new stable release. 

First download a custom patch file I've prepared against 1.4.5:

wget https://gist.githubusercontent.com/acbramley/c2809699c4dbf1774a14d89722743395/raw/e2c1479a73e7e9faff200802671bf982b6f3ac56/gistfile1.txt -O instaclick-curl-fix.patch

Then patch the library (using cweagans/composer-patches) with the new patch file by adding the following to the patches key in your composer.json:

"instaclick/php-webdriver": { "fix cURL POST": "instaclick-curl-fix.patch" }

Then simply run composer update instaclick/php-webdriver

Tagged

Drupal testing