303 redirect makes request with original verb

[johaywood]

When receiving 303 See Other redirect response after a DELETE, capybara-webkit requests the redirect URI with the original DELETE verb rather than with a GET as specified in the W3C definitions

From the log:

Started DELETE "/admin/users/1" for 127.0.0.1 at 2016-01-21 17:43:20 +0000
Processing by UsersController#destroy as JS
  Parameters: {"id"=>"1"}
Redirected to http://127.0.0.1:54744/admin-dashboard/users
Completed 303 See Other in 47ms (ActiveRecord: 3.3ms)
Started DELETE "/admin-dashboard/users" for 127.0.0.1 at 2016-01-21 17:43:20 +0000

at which point the test fails because I don't have a [DELETE] "/admin-dashboard/users" path.

If I'm using Chrome to make the same request here's the log:

Started DELETE "/admin/users/4" for ::1 at 2016-01-21 13:13:23 -0500
Processing by UsersController#destroy as JS
  Parameters: {"id"=>"4"}
Redirected to http://localhost:3000/admin-dashboard/users
Completed 303 See Other in 31ms (ActiveRecord: 19.1ms)
Started GET "/admin-dashboard/users" for ::1 at 2016-01-21 13:13:23 -0500
Processing by DashboardController#users as JS
Rendered dashboard/_flash_messages.html.erb (0.1ms)
Rendered dashboard/_users.html.erb (3.0ms)
Rendered dashboard/users.js.erb (21.2ms)
Completed 200 OK in 47ms (Views: 42.7ms | ActiveRecord: 1.0ms)

[mhoran]

Hey @johaywood. This is likely due to the underlying implementation in QtWebKit/WebKit. Are you running the latest version of Qt (5.5) and have you compiled capybara-webkit against that version? I'm not sure if there's much we can do if WebKit is at fault, but we can certainly investigate.

[johaywood]

Thanks for the quick reply @mhoran. No, still on Qt 4.8.6, so that could be the issue. I'll check it out and see if upgrading works.

[johaywood]

Upgraded to Qt v5.5 and still having the same problem, but only if it's a JS request. As HTML seems to be working fine