Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Custom content type not respected when POSTing #76

Open
danparsonson opened this issue Jan 31, 2017 · 12 comments
Open

Custom content type not respected when POSTing #76

danparsonson opened this issue Jan 31, 2017 · 12 comments
Labels

Comments

@danparsonson
Copy link

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

@nathan-osman
Copy link
Owner

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

@nathan-osman
Copy link
Owner

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?

@danparsonson
Copy link
Author

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

@nathan-osman
Copy link
Owner

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.

@set-killer
Copy link

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

@dougwebb
Copy link

dougwebb commented Mar 8, 2017

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
Copy link

dougwebb commented Mar 8, 2017

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.

@ya55en
Copy link

ya55en commented Mar 29, 2017

+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.

@njourdane
Copy link

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

@edgreenberg
Copy link

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.

@futtta
Copy link

futtta commented Sep 2, 2017

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.

@hendiadyoin
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

9 participants