HTTP Client acts weirdly, triggers server error 500

You must Login before you can answer or comment on any questions.

My iPhone app needs to call two different APIs. Identical calls produce different results:

httpClient.open("GET","http://api.timezonedb.com/?zone=Europe/Bucharest&format=json&key=[MY KEY]");

works just fine and gives the proper response from the targeted API, while

httpClient.open("GET","http://xurrency.com/api/usd/ron/1?key=[MY KEY]");

leads to an HTTP client error with a status = 500, meaning the sending server has an issue. Adding 'www.' to the second one makes no difference. This is completely puzzling (and very frustrating) to me. Anybody have an idea what might be going on here? Are there certain APIs Appcelerator just doesn't like?

1 Answer

Accepted Answer

Titanium's HTTPClient is just doing vanilla HTTP. It doesn't care what is on the other end.

My suspicion is that the server doesn't like the way the entire HTTP request is being presented. That's a lot more than just the URL. It's all the various headers that go with the request. User-Agent and Cookie would be the most likely culprit.

I would suggest making a request to the xurrency API using something like curl. Examine the headers closely. If curl can't make the request work, look into the reasons why.

If it does work, try to figure out the difference between curl's request and HTTPClient's request. You can use something like wireshark to capture the request/response.

But the short answer is that there's nothing inherently "wrong" with the Titanium HTTPClient. But it's default requests might be different from other clients in subtle ways that can cause a server to reject the request (or worse, bail out with a 500 error).

— answered 9 months ago by Jason Priebe
answer permalink
2 Comments

  • Appreciate the suggestion. Let me just make sure I understand you right here (I'm not exactly experienced when it comes to HTTP): you're saying that the way the Appcelerator HTTPClient may be generating the request in a format the API site doesn't quite like, even though the same API call works fine when sent from from Safari, IE, Firefox, as well as my Android phone browser. Right?

    — commented 9 months ago by Lothar Katz

  • An HTTP request is more than just the URL. There are a lot of headers sent from client to server in the request, and likewise, a lot of headers sent from server to client.

    Browser applications have all sorts of headers that they send with every request. Example from Chrome on OS X: 

    Connection: close
Cache-Control: max-age=0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_4) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/21.0.1180.82 Safari/537.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
    The HTTPClient may not have any default headers at all (I really don't know). It's possible that your server-side API requires that one or more of these headers be present.

    Try this exercise. Use HTTPClient to open this URL:

    http://smorgasbork.com/httpecho.php

    In the debugger, have a look at what you get back. It will basically echo back all the request headers to you. Then hit the same URL with a browser (one that you know works with the xurrency API) and compare the headers that are sent.

    You can even try adding headers to your request to emulate the browser by using setRequestHeader.

    At the end of the day, there's very little magic going on in HTTP. With the right options, you can make the server think your app is any piece of client software it requires to make it behave correctly.

    — commented 9 months ago by Jason Priebe

Your Answer

Think you can help? Login to answer this question!