3.0.0-RC1 - Receive "400 Looks like you're sending JSON data, but you haven't specified a content type. Aborting request." on POST attempt from Dashboard.

[nomadinjax]

I am now experiencing an error from the Dasboard on POST "400 Looks like you're sending JSON data, but you haven't specified a content type. Aborting request." since updating to 3.0.0-RC1. The same exact code worked fine under 2.2.4. I have taken all of my code out of onTaffyRequest and still get this issue.

I took a look at the code in api.cfc and I see this block:

<cfif contentTypeIsSupported(requestObj.contentType)>
    <cfset requestObj.bodyArgs = getDeserialized(requestObj.body, requestObj.contentType) />
    <cfset requestObj.queryString = cgi.query_string />
<cfelse>
    <cfif isJson(requestObj.body)>
        <cfset throwError(400, "Looks like you're sending JSON data, but you haven't specified a content type. Aborting request.") />
    <cfelse>
        <cfset throwError(400, "You must specify a content-type. Aborting request.") />
    </cfif>
</cfif>

And I see that the contentTypeIsSupported() is new to this version. I haven't really had time to wrap my head around what this is doing so I don't have a suggestion on the issue here.

[nomadinjax]

Not sure if this is related to #176

[atuttle]

Hi Damon. What version were you using prior to updating to 3.0.0-RC1?

[atuttle]

If this only happens from the dashboard, I'm guessing this is actually more closely related to the changes I made for #163

[nomadinjax]

I was on 2.2.4 previously.

[atuttle]

Can you share a sample URI and the request data you're sending, so that I can get a good test going for debugging?

[nomadinjax]

Sure.
Method: POST
URL: /LSIDMappings
Accept: json - although I notice that json appears in dropdown twice and it did not in the previous version - not sure if that is related to this issue. Either option gives same result.
Request Headers are empty.
Request Body: {} - NOTE: sending an empty body does not result in the error.

I have commented out my entire onTaffyRequest method and receive the same error so I don't believe anything I have in there is causing this.

I did dump the requestObj.contentType variable just before the <cfif contentTypeIsSupported(requestObj.contentType)> line and it was "application/json; charset=UTF-8". I then dumped the application._taffy.contentTypes variable which is what contentTypeIsSupported() validates against and I get an empty struct.

Let me know if you need additional information. Thanks

[nomadinjax]

I should add, this is ColdFusion 8.0.1.

[atuttle]

Thanks for the context. I'll get back to you when I know more.

[atuttle]

I notice that json appears in dropdown twice and it did not in the previous version - not sure if that is related to this issue. Either option gives same result.

This is because Taffy now supports multiple mime types per data format, and out of the box it supports both text/json and application/json. Maybe we should change the dropdown to show the content-type header value rather than the familiar name.

I did dump the requestObj.contentType variable just before the line and it was "application/json; charset=UTF-8". I then dumped the application._taffy.contentTypes variable which is what contentTypeIsSupported() validates against and I get an empty struct.

This sounds like the culprit. There may be some CF8 incompatibility with the way supported formats are initialized now.

[atuttle]

I don't have CF8 handy any more. Would you be available for a G+ Hangout session so we can debug on your computer together? You can email me at adam@fusiongrokker.com to set up a time, if you like.

[nomadinjax]

Line 836 in api.cfc, the _recurse_getSupportedContentTypes() function. This line:
<cfset response[local.m] = local.funcs[local.f].name />

Needs to be:

<cfset local.response[local.m] = local.funcs[local.f].name />

This addresses the issue in CF8.

[atuttle]

Nice find! Guess we don't need that meeting, then? Do you want to submit a pull request so your name can be immortalized in the commit logs for eternity? If you don't want to be bothered, I can obviously handle it pretty quickly.

[nomadinjax]

Go for it! I don't have the latest code in my fork and don't really have
the time to do all of that right now. My name is on the issue, that's
close enough! lol

On Tue, Sep 30, 2014 at 1:11 PM, Adam Tuttle notifications@github.com
wrote:

Nice find! Guess we don't need that meeting, then? Do you want to submit a
pull request so your name can be immortalized in the commit logs for
eternity? If you don't want to be bothered, I can obviously handle it
pretty quickly.

—
Reply to this email directly or view it on GitHub
#232 (comment).