[TIMOB-1983] setRequestHeader Broken for iPhone platform

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

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.

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.

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.

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.

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.

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);
     xhr.send(parms);
   

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?

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.

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.

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

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

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.

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.

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

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

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.

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.

to scrub

Our testing shows this to be working properly.

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

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.

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.

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.

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.

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

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.open("POST","http://api.localmedia.fm/files/endpoint_webform.cfm";)">http://api.localmedia.fm/files/endpoint_webform.cfm");
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

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.

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 :)