Titanium JIRA Archive
Titanium SDK/CLI (TIMOB)

[TIMOB-1983] setRequestHeader Broken for iPhone platform

GitHub Issuen/a
Resolution Date2011-04-17T01:57:44.000+0000
Affected Version/sn/a
Fix Version/sRelease 1.5.0
Labelsios, iphone, regression
ReporterDavid Pratt
AssigneeReggie Seagraves


setRequest is broken on trunk for iPhone. Authorization header is not sent in request using latest nightly build r4c5cd4a3 (Oct 1).

var myUsername = 'testuser';
var myPassword = 'testpass';

var request = Titanium.Network.createHTTPClient({

    onload:function(e) {
        if (request.status != 200 && request.status != 201) {
    onerror:function(e) {
        Ti.API.info("Got Error: "
            + e.error);

request.open('GET', 'https://myserverurl', true);
request.setRequestHeader('Authorization','Basic ' + Titanium.Utils.base64encode(myUsername + ':' + myPassword));


  1. Don Thorp 2011-04-15

    Assigning to Ralf to triage. Ralf it looks like a regression so I've tagged it as such, it may not actually be.

  2. Blain Hamon 2011-04-15

    This is odd given that the files in question haven't been changed in any behavior-changing manner since before 1.4.0. The setRequestHeader in that form is also used in KS's fourSquare demo, so we can recreate that way.

  3. johnmcknight (at yahoo) 2011-04-15

    I don't think this is a bug. The open method expects that the requestMethod has been defined before it has been called. In the example, the open is done first and then the requestMethod is set and this can't work in the current implementation. If you swap the order it will work as expected. BTW - This also affects timeout in that it must be defined before the open method is called. I have assumed this is more of a documentation issue than a bug.

  4. David Pratt 2011-04-15

    Hi John. setRequestHeader was placed between the open and send as this was the only way it worked previously. Will confirm and reply back. Will be very satisfied if this simple change resolves the issue as I am attempting to stick with nightly builds.

  5. David Pratt 2011-04-15

    I can confirm that changing order does NOT work with the Sep 8 nightly build I reverted to as a result of this issue. I does work with setRequestHeader following open but before send with this version.

    I am obtaining latest nightly build today and will check if lastest build is in anyway different and report back.

  6. Don Thorp 2011-04-15

    Here is the specification entry for http://www.w3.org/TR/XMLHttpRequest/#the-setrequestheader-method">setRequestHeader notice that it's an error for it to be called before it's in an OPEN state.

  7. johnmcknight (at yahoo) 2011-04-15

    I am doing this with the build from last night and it is working for me.

         xhr.setRequestHeader("content-type", "multipart/form-data");
         xhr.open("POST", service_url);

    BTW - I am running iOS SDK 3.2 and 4.1 and running Oct 7 r3be604b2.

    Did you empty your iPhone build so it can force a new build with the latest nightly?

  8. David Pratt 2011-04-15

    Hi Don. Right.

    I am on SDK 4.1. John, will let you know shortly whether this works with change of order. If it does, it is still a bug as it is meant to be set following open.

  9. Stephen Tramer 2011-04-15

    Passing to Thom so he can test. Our KS->XHR->Cookies test uses request headers (in the specified manner, after open() is called) and works.

  10. Thomas Huelbert 2011-04-15

    KS->XHR->Cookies ius failing in build 1.5.0.d58dbe. back to you Stephen.

  11. Stephen Tramer 2011-04-15

    Test is passing for me off of the same build. Not sure what's going on here.

  12. Stephen Tramer 2011-04-15

    Okay, test has intermittent failures. Pass/fail may have something to do with the remote service and not with our XHR header. We're going to need another way to test non-cookie headers, looking into it.

  13. Stephen Tramer 2011-04-15

    Thom, gonna say that this one is fixed again now that I've found a more reliable test, but with some (possible) caveats.

    The KS->Mashups->Foursquare test was always able to reliably produce a correct result for me. I would recommend you test it before performing the following, which you may need to do if you keep getting geolocation errors from it:

    • Go to "Settings->General->Reset->Reset location warnings"

    If you must do this, it appears to be an Apple bug that has to do with geolocation fussiness in the transition from 3.1.x to 3.2, internally. Not sure why.

    Second, I've opened up bug #2106, which indicates how certain module listeners may interact poorly with themselves. 4SQ demonstrates this when used in conjunction with any other geolocation requests on a different context - so don't run the 4SQ test in the same session that you run geolocation.

  14. Stephen Tramer 2011-04-15

    Reassigning back to me. Thom should catch it because it's fixed-in-qa anyway.

  15. Thomas Huelbert 2011-04-15

    thanks for the info Stephen, closing against iPod 4th gen (4.1), 3g 3.1.2 with mobile sdk build

  16. David Pratt 2011-04-15

    I can authenticate using Basic Authorization with my app using curl but returns 401 error with titanium most recent nightly 1.4.2-r8e708e78. Were there commits to the code to change correct this problem. Something is not right. The alternative to setting headers is to embed username:password in url ie. https://user:pw@example.com">https://user:pw@example.com which I had tried before but is also broken. See ticket #2149. Perhaps the original issue is related to #1502 which is unresolved.

  17. David Pratt 2011-04-15

    Sorry. To be clear, I can authenticate against my api using curl using name:pw in url or by setting headers. With Titanium app cannot get past 401 with headers set and cannot authenticate with user:pw in url due to #2149.

  18. Ralf Pfeiffer 2011-04-15

    to scrub

  19. Ralf Pfeiffer 2011-04-15

    Our testing shows this to be working properly.

    If there is an issue, it is likely with 2149, which we are investigating.

  20. David Pratt 2011-04-15

    Hi Stephen. There is something here that is not getting picked up with whatever you are doing for testing. The httpclient does not consistently work. In fact, I can demonstrate authentication failure where curl succeeds always with same credentials (with headers set or user:pw in url where titanium fails on both counts. I am prepared to create a small app to demonstrate.

  21. David Pratt 2011-04-15

    Have not had a reply to above. The client is not reliable. Please advise whether you are willing to look at code that will demonstrate failure and I will bundle a small app to send along with instructions to demonstrate failure. Will need some detail for sending as will not post here. Am going to attempt wrapping another lib as a module in the interim. Am frustrated by the problems and the block to development on iOS.

  22. Thomas Huelbert 2011-04-15

    fairwinds - if you could post the file to drop.io and send me (thuelbert@appcelerator.com) an email, I'll make sure the file gets to Stephen. Thanks.

  23. David Pratt 2011-04-15

    Thomas. drop.io has been bought so will be unable to post there. Will simply send app.js content with some instructions as soon as I have them written up. I would expect this later today or tomorrow. You will see by the small example bad things have become with a small piece of code that does nothing but fetch json using the client. Parse, authentication failure, headers being ignored, and inability to get content as needed from the client. This will be contrasted by simple curl fetches that succeed in all cases.

  24. Thomas Huelbert 2011-04-15

    fairwinds - d'oh, that's right. I'll look for your email.

  25. Anthony Webb 2011-04-15

    I think this should be opened back up. I am still having the issue where headers cant be set properly. I am using the latest cont build from Dec 23 (Dec 23 2010 14:19 readb8ad1) and tested on the emulator and iphone device (4.2) No matter what I try I can never override the content-type, it always is: application/x-www-form-urlencoded;

    Consider the following code:
    var xhr = Titanium.Network.createHTTPClient();
    xhr.onload = function()

        Ti.API.info('I am in utf-8 onload for POST');

    }; xhr.onerror = function()

        Ti.API.info('I am in utf-8 error for POST');

    }; xhr.setRequestHeader("setoutside", "one");
    xhr.setRequestHeader("content-type", "multipart/form-data");
    xhr.setRequestHeader("setinside", "two");
    xhr.send({"a":"hi", "b":"there"});

    When this hits my server I have the following headers:

    Accept-Encoding gzip
    Connection keep-alive
    Content-Length 12
    Content-Type application/x-www-form-urlencoded; charset=utf-8
    Cookie CFID=3538862; CFTOKEN=38108057
    Host api.localmedia.fm
    Setinside two
    User-Agent Appcelerator Titanium/cont-1.6.0 (iPhone Simulator/4.2; iPhone OS; en_US;)
    X-Requested-With XMLHttpRequest

  26. Stephen Tramer 2011-04-15

    Please follow bug #2675. We are in the process of revising our XHR support and this issue will be taken care of as part of it.

  27. Anthony Webb 2011-04-15

    Thanks Stephen, I've remove photo support from my app as I cant post stuff to the server without using multipart/form-data, here's hoping it is fixed soon, I will watch 2675. It is worth nothing though that adding the interface bits to my app was a breeze with appcelerator :)

JSON Source