AJAX POST content-type Warning

[visoft]

I have a link that does a POST, e.g.

link_to "Add", my_url(obj), :method => :post, :remote => :true

In my Cucumber output I get the message:

content-type missing in HTTP POST, defaulting to application/octet-stream

According to the docs, this warning can be muted by setting the following:

networkRequest.setHeader(QNetworkRequest::ContentTypeHeader, "application/octet-stream");

If you don't want to or can't add it, is there another way to stop this warning from showing up?

Thanks,
-Damien

[itsmeduncan]

👍

[ValeriiVasin]

I have similar issue.

[mhoran]

I actually think this is a Rails UJS issue, not something that can be fixed in capybara-webkit. The docs you point out are for when making POST requests from within Qt. However, the error your're getting is from testing the action of UJS. Here are the headers from a UJS action:

Accept:*/*
Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-US,en;q=0.8
Connection:keep-alive
Content-Length:0
Cookie:redacted
Host:redacted
Origin:redacted
Referer:redacted
User-Agent:Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.63 Safari/535.7
X-CSRF-Token:QImL5N0WkDYOo/XNcwrR4IA0eOT9xCF5U2bl1h8QGJA=
X-Requested-With:XMLHttpRequest

Note that there is no Content-Type header. capybara-webkit (really, QWebPage) is handling the POST via JavaScript, but because the UJS helpers don't set the header, it defaults to application/octet-stream. We don't want (and probably can't) to set the default header to application/octet-stream, as this may cause unexpected side-effects.

Hope this helps.

[visoft]

It's not that big of a deal. I don't think capybara-webkit should set the header; I was just hoping there was a way to keep the warnings out of my Cucumber output. I suppose a work-around would be to set the header in UJS. I think I tried hooking into the AJAX send, but wasn't able to get the warning to go away that way, but honestly I don't remember... Thanks for taking the time to look into the issue.

[dtuite]

I have the same problem and it's actually causing intermittent failures in my cucumber specs.

You can see that the spec fails here when the content type is missing:

  @javascript @favourite-concept
  Scenario: Favouriting a Concept   # features/suggestion.feature:41
    Given I am a signed in user     # features/step_definitions/registration_steps.rb:1
http://connect.facebook.net/en_GB/all.js|30|The "fb-root" div has not been created, auto-creating
    When I suggest "apple"          # features/step_definitions/suggestion_steps.rb:1
    And I click that concept's star # features/step_definitions/suggestion_steps.rb:83
content-type missing in HTTP POST, defaulting to application/octet-stream
    Then it should be favourited    # features/step_definitions/suggestion_steps.rb:87
      expected css "li.concept.fav" to return something (RSpec::Expectations::ExpectationNotMetError)
      ./features/step_definitions/suggestion_steps.rb:88:in `/^it should be favourited$/'
      features/suggestion.feature:45:in `Then it should be favourited'

But then I run the same spec 2 seconds later and it passes:

  @javascript @favourite-concept
  Scenario: Favouriting a Concept   # features/suggestion.feature:41
    Given I am a signed in user     # features/step_definitions/registration_steps.rb:1
http://connect.facebook.net/en_GB/all.js|30|The "fb-root" div has not been created, auto-creating
    When I suggest "apple"          # features/step_definitions/suggestion_steps.rb:1
    And I click that concept's star # features/step_definitions/suggestion_steps.rb:83
    Then it should be favourited

The line where the POST request is sent in my app is here:

    $.post("/favourites", { concept_id: @id }, postSuccess, "json")

I'll have a look at fixing this by setting the content type and add an update.

[emeraldMaster]

hi, I have the same issue! :(

[georges]

Same here. following thread.

[i-am-logger]

Following thread, same issue here

[latensified]

Yep.

[andreacfm]

same here. following

[mhoran]

Is this actually causing issues for anyone, or is it simply the warning that is causing concern? Last time I checked, this issue was caused by Rails omission of a content type header. Without changing Rails UJS, there's not much that can be done on our side.

[davesmylie]

For me it was more annoyance - there were so many of these messages on the screen that it made it hard to see what tests were passing/failing.

[aratak]

Same after latest update. Following

[rheaton]

+1

[santry]

For those of you using link_to with remote: true and method: post you can manually set the Content-Type header to silence the warning:

CoffeeScript:

# Set Content-Type on XHR POST requests so Qt stops complaining
$('a[data-remote="true"]').bind 'ajax:beforeSend', (event, xhr, settings) ->
  if settings.type == 'POST'
    xhr.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded')

JavaScript:

$('a[data-remote="true"]').bind('ajax:beforeSend', function(event, xhr, settings) {
  if (settings.type == 'POST') {
    xhr.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded');
  }
});

Of course you can adjust the jQuery selector as needed to reduce the scope of remote links that are affected.

jquery-ujs should probably be doing this itself, so when I get a chance I'll put together a pull request for them.

[jsgarvin]

@santry , When I put in your code, my controllers start trying to treat the request as HTML instead of JS (eg. "Processing by DailyPlansController#edit as HTML") in integration tests.

[santry]

@jsgarvin can you post a gist with some of the code?

[jsgarvin]

@santry Here is the current content of my app/assets/javascripts/missing_content_type_patch.js. When I include this file in my assets manifest, I get integration test errors and failures resulting from the controller treating the requests as HTML instead of JS. When I remove the file from the manifest, I simply get the content-type missing in HTTP POST messages.

$(document).ready(function() {
  $('a[data-remote="true"]').bind 'ajax:beforeSend', (event, xhr, settings) ->
    if settings.type == 'POST'
      xhr.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded');
}

There's no difference if don't put it inside a document ready block, so that's apparently not necessary, but doesn't seem to help either.

[santry]

@jsgarvin you seem to have mixed my CoffeScript in with your JavaScript, resulting in a syntax error. You want this instead:

$(document).ready(function() {
  $('a[data-remote="true"]').bind('ajax:beforeSend', function(event, xhr, settings) {
    if (settings.type == 'POST') {
      xhr.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded');
    }
  });
});

[jsgarvin]

Ha! That's a bit embarrassing. Let's see if I can redeem myself.

Your version works great now for any links that were on the page at the time the page was initially loaded. However, links drawn on the page as a result of an earlier AJAX call were still producing the missing content type warning/error. The following version seems to address those as well, at least for me.

$(document).ready(function() {
  $('body').on('ajax:beforeSend', 'a[data-remote="true"]', function(event, xhr, settings) {
    if (settings.type == 'POST') {
      xhr.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded');
    }
  });
});

[santry]

@jsgarvin yes, that'll fix links added after the initial page render. Hopefully the jquery-ujs guys will accept my pull request and this will all be taken care of!

[oma]

what's the status on this? will it be merged? (why not?)

[jferris]

@oma there isn't anything to merge here yet. The code snippets in the comments address an issue in rails-ujs and can't be generically applied from capybara-webkit. See rails/jquery-ujs#301.

We have a general discussion of warning suppression going on in #502. We're not happy with the current solution, but there's some discussion in there if anybody wants to try to put together an alternate. I may get a chance to work on that at some point, but my time is limited and #494 is my next priority.

[oma]

thanks for explaining @jferris - appreciated!

[calleluks]

Since #586 has been merged, can this be closed? This issue seems to refer to suppressing the warnings rather than the Content-Type header being set to the wrong thing like stated in #636.

[calleluks]

I'll close this issue due to inactivity. Please re-open it if you're still experiencing these issues.