REST-Easy icon indicating copy to clipboard operation
REST-Easy copied to clipboard

Custom content type not respected when POSTing

Open danparsonson opened this issue 8 years ago • 12 comments

Hi,

I have a strange problem - I use REST-Easy (which I love, thank you!) in Firefox to debug a WCF service that speaks JSON. It's been working fine until the last day or so, when suddenly, all my POSTs have stopped working. Looking in Fiddler, it appears that the content-type, which I set to 'application/json' in the REST-Easy UI, is actually going out as 'text/plain;charset=UTF-8'. Replaying the requests in Fiddler with this corrected results in the service calls succeeding.

I can't understand why this has just recently stopped working - according to the status page, it hasn't changed since I installed it - and also what I can do to fix it? I've tried rolling back my code to a version that definitely worked, and I'm trying to run REST-Easy on two different machines, one talking to a local copy of the service, and one talking to a server VM. All with no success.

Maybe Firefox has changed something recently? I'm on 51.0.1.

Hope you can help!

Dan

danparsonson avatar Jan 31 '17 16:01 danparsonson

I'll give it a shot on Firefox 52 and see if I can reproduce.

nathan-osman avatar Feb 01 '17 02:02 nathan-osman

Hmm... even with Firefox 52, entering "application/json" for the MIME type causes the correct Content-Type header to be sent with the request.

mime

Do you have any other add-ons installed?

nathan-osman avatar Feb 01 '17 03:02 nathan-osman

Thanks for getting back to me - I've had a bit more of a play and here is how I can reproduce it:

  • With all other add-ons disabled, fire up a REST Easy tab and enter some url (e.g. http://www.bbc.co.uk/service - not a real service endpoint but doesn't matter for the initial request); leave the method as GET
  • Custom data - set the content type to something - "application/pineapple", whatever - leave the data field empty
  • Send the request - watching in Fiddler, the request goes through with the specified content type
  • Change the method to POST, send again, still working
  • Enter some data - {"a":"b"} - hit Send - now the request goes through with a content length and a content type of 'text/plain;charset=UTF-8'

Presumably since you're not seeing it then it's something else specific about my machine; antivirus maybe? If I find anything out I'll let you know.

Thanks,

Dan

danparsonson avatar Feb 01 '17 10:02 danparsonson

Aha! I was able to get text/plain; charset=UTF-8 after switching to a POST request. I'll see if I can figure out what is causing this to happen.

nathan-osman avatar Feb 01 '17 23:02 nathan-osman

+1 I confirm this bug and it makes the add-on almost useless... I am back to CURL until it is fixed.

set-killer avatar Feb 10 '17 16:02 set-killer

I'm seeing this bug as well; POST with custom content body containing JSON markup, and application/json content type, is being sent with Content-Type: text/plain; charset=UTF=8. I confirmed using Fiddler that that's what's going over the wire; it's not getting modified on the receiving end.

dougwebb avatar Mar 08 '17 20:03 dougwebb

Suggestion: in Application.js around line 280 you loop through setting request headers, and then further down you set the content-type header for custom mode. Maybe the first loop sets the content-type header, and the second attempt is ignored because it's already set? I'd consider that a bug in the browser API, but it seems like the sort of thing that might've quietly changed under you in a Firefox release.

dougwebb avatar Mar 08 '17 20:03 dougwebb

+1; FF 52.0.2; it is frustrating that even if I redefine Content-Type in "Headers" section, it still does not honor my value (application/json) and sends text/plain.

ya55en avatar Mar 29 '17 13:03 ya55en

Same here on FF 53.0.2 on Ubuntu, I can't use this addon until it's fixed...

njourdane avatar May 22 '17 12:05 njourdane

Confirming this on 53.0.3 (64-bit) (Fedora Linux.) I set the first dropdown for Form, and the second for application/x-www-form-urlencoded, but I still get a Content-Type: text/plain. I tried putting in my own Content-Type header but that didn't work either.

edgreenberg avatar Aug 04 '17 14:08 edgreenberg

Confirmed on FF 55 (ubuntu linux); content type set to application/json but being POST -ed using text/plain instead, resulting in the restfull webservice throwing an error.

futtta avatar Sep 02 '17 11:09 futtta

I faced the same problem. But then I noticed that my Request Body was just improperly formatted if but only if Fiddler changed the type from application/json to text/plain.
Example with improper format: { "longitude" : 1.352777, "latitude" : 49.183975, }

The last comma is not JSON-compliant. So, Fiddler changes the Content-Type to plain/text.

That may be worth considering if you face the same problem.

hendiadyoin avatar Jan 12 '18 14:01 hendiadyoin