Mis-interpretation of what is being transmitted by a remote httpclient request...

[Albacheeser]

I have found a bug in the API.CFG. It is in the section of the code in line 520s area where it is determining which mime type is being used (presumably to determine the function to call).

Background:
I am using Appcelerator Titanium 3.0 to build mobile apps because it is great for having one codebase for my mobile app but can port to 1) Android 2) iOS or 3) MobileWeb.

Here is the symptom of the problem:

• URL submitted from Mock Client or any browser (PC or mobile) - WORKED FINE 200!!
• URL submitted from a mobile app written in Titanium 3.0 (javascript based dev platform). It has an HTTPClient class that is used. I won't bore you with code. - 400 BAD REQUEST

Well, obviously the Titanium HTTPClient calls to Taffy are not supplying exactly the same info that occurs when a user submits the very SAME URL into a browser.

I explored for 3 days all the different special idiosyncrasies of any platform involved including the server, the server software, Titanium, etc.

Then, I decided to GREP all of the places in the CORE that had 400 just to see if Taffy was initiating the problem. I found about 7 or 8 places. So I iteratively went through and changed each one to 403 to see if the remote call from the mobile device would get a 403 instead of a 400. Low and behold it did and here is the place in the code where it occurs:

FILE: API.CFG

CONCLUSION:
the API.CFG claims that the "Your default mime type (#application._taffy.settings.defaultMime#) is not implemented". But would not that same fact be true whether regardless from where I submitted the URL? I believe there is a mismatch perhaps in the logic between the mimeType and mimeEXT.

Of course, I did not dig any deeper to determine what is different about what is being delivered to Taffy from a browser versus the mobile app httpclient. However, I suspect you all might be able to figure it out and let me know.

WHAT I DID AS A WORKAROUND FOR NOW:
I remarked out the code that claims the defaultMime is not implemented and just forced it to return "json" because that was the value of #application._taffy.settings.defaultMime#.

[atuttle]

Can you provide some sample code for me to use to debug? All you've said so far is that when you make a request with Titanium it goes through a different code path -- but you haven't said how you're making that request.

• What is the exact URL you're requesting?
• What request headers are you including?
• Are you using some library (e.g. jQuery) to make the request?

I can't move forward without these types of details. The more you can provide, the better.

[Albacheeser]

Hi Adam,

Thanks for the quick response. I am glad to provide any detail you may require. First, however, let me point out that I have verified that this issue is the very same as #125. After I posted my issue, I went back to my code and put in the "Accept" header as #125 said they had to do. IT WORKED!! Now...here is the detail...

Any of the following URLs should return the json data provided by my site which was based on your "jsonutil" example:
http://swatchman.servatus.biz/api/index.cfm/swatchsets/62001
http://swatchman.servatus.biz/swatchsets/62001
http://swatchman.servatus.biz/api/swatchsets/62001

If you key any of these into any browser your coldfusion json data spits back as expected. Now, it did not in my mobile app which of the following nature:
CLIENT INFORMATION:

PLATFORM: Appcelerator Titanium 3.0 which is an Eclipse based IDE that ports code to Android/iOS/MobileWeb from a single project codebase.

LANGUAGE: Javascript

Here is a simple version of the code that did NOT work:

var xhr = Ti.Network.createHTTPClient({
   onload:function(e){
         if(this.status == '200'){
            alert('Success!');
            alert(this.responseText);
         }                     
   },
   onerror:function(e){
       alert('statusText: '+this.statusText);
   },
   timeout : 5000
});

xhr.open("GET", "http://swatchman.servatus.biz/swatchsets/62001");
xhr.send();

The following modification also DID NOT Work:

xhr.open("GET", "http://swatchman.servatus.biz/swatchsets/62001");
xnr.setRequestHeader("Content-Type","application/json");
xhr.send();

The following modification ACTUALLY DID WORK:

xhr.open("GET", "http://swatchman.servatus.biz/swatchsets/62001");
xnr.setRequestHeader("Accept","application/json");
xnr.setRequestHeader("Content-Type","application/json");
xhr.send();

While I am thrilled to get it working, there probably still is the remaining issue of whether this is a Taffy bug. I can say this: after nearly 4 days of googling and researching, I could not find one example elsewhere where the "Accept" header was required as a general matter when making HTTPClient calls with Ti for JSON, XML, or otherwise.

For my part, it doesn't matter because I have found a workaround. However, for your part, it may behoove you to see if there is a way you can handle a request without that header in case someone else runs into what I did.

Thanks for developing this cool framework!

[Albacheeser]

Oh, in answer to your third question, there is no jQuery in my code and I am not certain that Ti supports it although I did see some community discussion of that.

[atuttle]

Thanks for providing all of your code samples and answering my questions so thoroughly, this is very helpful. I can confirm that this does indeed look like a bug.

The reason your requests work in the browser is that the browser includes the Accept header when you make a request (usually set to some variant of "text/html" because that's what browsers want to display)...

Another work-around would be to specify the format on the URL, like so:

xhr.open("GET", "http://swatchman.servatus.biz/swatchsets/62001.json");

Note that I've added .json to the URL. I expect that if you try this it will work.

Nevertheless, this is definitely a bug. I will see about getting it fixed for the impending 1.3 release. Thanks again for all of your effort and detail in reporting!

[jbvanzuylen]

Another way to test this is using Railo (my version is 3.3.4.003 final) with the tag cfhttp. It is creating a request without "Accept" header.

I did some additional debugging and found out that the key "application._taffy.settings.defaultMime" is holding the extension of the default mime type, so it should be checked against the supported extensions instead the supported mime types. Change line 520 to the following fixes the problem:

<cfelseif not structKeyExists(application._taffy.settings.mimeExtensions, application._taffy.settings.defaultMime)>

Or event better is using function "mimeSupported" that, according the name, should check this correctly

[atuttle]

Resolved by #132