POST always has content_type 'application/x-www-form-urlencoded'?

[olliebun]

I'm using Rest-Client to submit a simple POST to CouchDB, with content-type application/json. Rest-Client's UrlEncoded class has this code, though:

def headers
  super.merge({'Content-Type' => 'application/x-www-form-urlencoded'})
end

Is there a way around this? I don't see why the content type should be messed with if the developer has specified it.

I'm calling it like this:

RestClient.post uri, payload, headers, &block

Here are the parameters:

URI: http://cerales:password@localhost:5984/testing
Payload: {"dan":true,"yep":1}
Headers: {:content_type=>:json, :accept=>:json}

Payload is a string, but I've tried it with a hash too.

[lpar]

This seems to work for me:

RestClient.post url, { 'body' => msg }.to_json, :content_type => 'application/json'

In the Sinatra app:

post '/', :provides => :json do
  logger.info "Media type is " + request.media_type

Result:

I, [2011-12-12T16:02:29.201537 #22150]  INFO -- : Media type is application/json

[quigebo]

@Cerales - try adding a #to_json to your payload

[mhenrixon]

I have the same issue, rest-client is broken so time to turn to something else I guess. Sucks because the API is nice but I need to be able to post json and it won't let me.

RestClient.post "https://#{uid}:#{pwd}@api.twilio.com/#{uri}", { "to" => to, "from" => from, "body" => "Hey ho let's go" }.to_json, { content_type: 'application/json' }

that request tells me the content-type is wrong and that I should specificy 'application/x-www-form-urlencoded' instead so obviously this needs to be fixed.

[jcoyne]

It's working fine for me. Can't duplicate.

[ab]

Sorry, I wasn't able to reproduce this on master. Are you still seeing this? Could you provide a test case?

[matkruse]

The problem seems to be that if the payload is being passed in as a hash, then the content-type is overridden. Unless you want to pass a header overridden message back to the user due to the payload structure, I think you can close this issue. @quigebo is right on.

[ab]

Yeah, it seems possible that rest-client should raise an exception if you pass a Content-Type header and also a Hash for the payload, since that combination is incompatible. Also possible it would be less intrusive to simply warn().

[ryannmicua]

Would be nice if this was at least in the examples.

One wouldn't expect to have to convert a hash to a json string when all the other examples show the payload being a hash. Also, one would expect to be able to "override" the content type (and other headers) and not be overridden without the user knowing about it.

[cazador4]

+1

[ioquatix]

Yeah, it seems possible that rest-client should raise an exception if you pass a Content-Type header and also a Hash for the payload, since that combination is incompatible. Also possible it would be less intrusive to simply warn().

Why not derive the encoding of the hash from the content_type specified?

[YOHN89]

+1