Entity bodies are not passed back for PATCH requests

[thoughtless]

Our app passes data in the entity body of a PATCH request via jquery. It works fine in the browser but when capybara-webkit makes the request the (rails) server never gets the entity body.

The problem is similar to #427

Is this also not supported by QtWebKit?

[jferris]

This is likely the same issue as #427. It seems like QtWebKit only looks for a response on certain request types. We haven't found a workaround for this yet in Qt, but I'd be open to suggestions.

[thoughtless]

In theory it should be possible because of sendCustomResponse: http://harmattan-dev.nokia.com/docs/platform-api-reference/xml/daily-docs/libqt4/qnetworkaccessmanager.html#sendCustomRequest

I would assume that this method is what is being used now because the PATCH requests are made, they just don't have a body. Perhaps the "problem" is that sendCustomRequest doesn't accept a byte array for the data. However, put and post do.

But I'm not an expert on this stuff. I could be way off.

[thoughtless]

In case anyone else with the same issue finds this, my work around ended up looking something like this.

if (userAgent = window?.navigator?.userAgent).match /capybara-webkit/ || userAgent.match /PhantomJS/
  type = 'post'
  url = URI(url).setQuery('_method', 'patch').toString()
else
  type = 'patch'

$.ajax
  url: url
  type: type
  dataType: 'json'
  contentType: 'application/json; charset=UTF-8'
  data: data

[Borzik]

Hey! If someone has more info on that Qt WebKit issue, pls share it in the issue I created at QtWebKit issue tracker.
Hope it will be resolved someday.

[mfpiccolo]

I am just using "put" instead of "patch" for the time being until patch can pass through data properly.

[hiattp]

According to QTBUG-42456 the Qt side of this issue was fixed in 5.4.1. But after updating Qt:

% qmake -v
QMake version 3.0
Using Qt version 5.4.1 in /usr/local/Cellar/qt5/5.4.1/lib

Webkit still doesn't work with PATCH requests. Interestingly, 5.4.1 will send CONTENT_LENGTH with a value that looks correct, but not CONTENT_TYPE or the body. Haven't delved in yet but maybe the ball is back in Webkit's court; @jferris thoughts?

[hiattp]

As a quick followup and for anyone else hunting down a solution, poltergeist running PhantomJS 2 (which uses Qt 5) handles PATCH requests as expected.

[jferris]

It looks like we directly send the outgoing data upstream to Qt: https://github.com/thoughtbot/capybara-webkit/blob/master/src/NetworkAccessManager.cpp#L16

I'm not sure what we would be doing differently.

@hiattp did you make sure to rebuild capybara-webkit after updating Qt?

[hiattp]

I uninstalled and reinstalled the gem after upgrading Qt, would there be another step to rebuilding? I did notice a different request structure (e.g. the headers noted above) and slightly different test errors after reinstalling so I felt confident it was using the new version of Qt but maybe I missed a step

[jferris]

@hiattp nope, uninstalling and reinstalling should do it.

I'll try to take a look at this soon.

[jferris]

@hiattp I just tried to reproduce this, but I'm unable to write a failing test: 6b6a2e1

If you have some time, could you try running that test locally? It's on the jf-patch-body-test branch.

[hiattp]

@jferris Sorry for the long delay; I couldn't make that test fail either. And yet switching from poltergeist to webkit still makes patch requests fail in my Rails suites (no bodies being sent). Very mysterious; I'll try to dig deeper.

[philipp-spiess]

I had the same problem when running with qt4. Updating to qt5 solved the issue for me.

I'm now on 5.4.1 and installed it using homebrew for OSX:

brew remove qt
brew install qt5
brew linkapps qt5
brew link --force qt5

gem uninstall capybara-webkit
bin/bundle install

I'm now waiting to have the qt5 apt packages approved by Travis CI: travis-ci/travis-ci#4352

[tcoopman]

I have the same issue and I tried to make it work with Qt5.5 but patch requests still fail. (This is on ubuntu 14.04)

[dkniffin]

I'm having the same issue on OS X (Yosemite). I'm running qt5:

$ qmake --version
QMake version 3.0
Using Qt version 5.5.0 in /usr/local/Cellar/qt5/5.5.0_1/lib

[voltechs]

Same here, OS X Yosemite running QT5

$ qmake --version
QMake version 3.0
Using Qt version 5.5.1 in /usr/local/Cellar/qt5/5.5.1/lib

[tombroomfield]

Same issues, no content body.

QMake version 3.0
Using Qt version 5.5.1 in /usr/local/Cellar/qt5/5.5.1/lib`

Changing to a PUT request worked for me.

[delphaber]

+1, Using PUT fixed the problem

↳ $ qmake --version
QMake version 3.0
Using Qt version 5.5.1 in /usr/local/Cellar/qt5/5.5.1_2/lib

↳ $ bundle list | grep capybara
  * capybara (2.6.2)
  * capybara-webkit (1.8.0)

[ehannes]

+1, switched to PUT.

$ qmake --version
QMake version 3.0
Using Qt version 5.2.1 in /usr/lib/x86_64-linux-gnu

$ bundle list | grep capybara
  * capybara (2.6.2)
  * capybara-webkit (1.10.1)

[wahhaj]

I'm having the same issue - PATCH requests send a correct CONTENT_LENGTH but no CONTENT_TYPE or body. Switching to PUT is not a viable option at the moment.

$ qmake --version
QMake version 3.0
Using Qt version 5.5.1 in /usr/local/Cellar/qt55/5.5.1/lib

$ bundle list | grep capybara
  * capybara (2.7.1)
  * capybara-webkit (1.11.1)

[Didericis]

Same issue on MacOS - Sierra with Qt 5.5.1

$ qmake --version
QMake version 3.0
Using Qt version 5.5.1 in /usr/local/Cellar/qt55/5.5.1/lib

$ system_profiler SPSoftwareDataType
System Software Overview:
  System Version: OS X 10.11.6 (15G1217)
  Kernel Version: Darwin 15.6.0

[twalpole]

Closing this due to age. We can reopen if/when a way to replicate is provided using current versions