setRequest is broken on trunk for iPhone. Authorization header\nis not sent in request using latest nightly build r4c5cd4a3 (Oct\n1).
\nvar myUsername = 'testuser';
\nvar myPassword = 'testpass';
var request = Titanium.Network.createHTTPClient({
\n onload:function(e) {\n if (request.status != 200 && request.status != 201) {\n request.onerror(e);\n return;\n }\n },\n onerror:function(e) {\n Ti.API.info(\"Got Error: \"\n + e.error);\n }\n});\n\nrequest.open('GET', 'https://myserverurl', true);
\nrequest.setRequestHeader('Authorization','Basic ' +\nTitanium.Utils.base64encode(myUsername + ':' + myPassword));
\nrequest.send();
Assigning to Ralf to triage. Ralf it looks like a regression so\nI've tagged it as such, it may not actually be.
This is odd given that the files in question haven't been\nchanged in any behavior-changing manner since before 1.4.0. The\nsetRequestHeader in that form is also used in KS's fourSquare demo,\nso we can recreate that way.
I don't think this is a bug. The open method expects that the\nrequestMethod has been defined before it has been called. In the\nexample, the open is done first and then the requestMethod is set\nand this can't work in the current implementation. If you swap the\norder it will work as expected. BTW - This also affects timeout in\nthat it must be defined before the open method is called. I have\nassumed this is more of a documentation issue than a bug.
Hi John. setRequestHeader was placed between the open and send\nas this was the only way it worked previously. Will confirm and\nreply back. Will be very satisfied if this simple change resolves\nthe issue as I am attempting to stick with nightly builds.
I can confirm that changing order does NOT work with the Sep 8\nnightly build I reverted to as a result of this issue. I does work\nwith setRequestHeader following open but before send with this\nversion.
\nI am obtaining latest nightly build today and will check if\nlastest build is in anyway different and report back.
Here is the specification entry for setRequestHeader\nnotice that it's an error for it to be called before it's in an\nOPEN state.
I am doing this with the build from last night and it is working\nfor me.
\n xhr.setRequestHeader(\"content-type\", \"multipart/form-data\");\n xhr.open(\"POST\", service_url);\n xhr.send(parms);\n\nBTW - I am running iOS SDK 3.2 and 4.1 and running Oct 7\nr3be604b2.
\nDid you empty your iPhone build so it can force a new build with\nthe latest nightly?
Hi Don. Right.
\nI am on SDK 4.1. John, will let you know shortly whether this\nworks with change of order. If it does, it is still a bug as it is\nmeant to be set following open.
Passing to Thom so he can test. Our KS->XHR->Cookies test\nuses request headers (in the specified manner, after open() is\ncalled) and works.
KS->XHR->Cookies ius failing in build 1.5.0.d58dbe. back\nto you Stephen.
Test is passing for me off of the same build. Not sure what's\ngoing on here.
Okay, test has intermittent failures. Pass/fail may have\nsomething to do with the remote service and not with our XHR\nheader. We're going to need another way to test non-cookie headers,\nlooking into it.
Thom, gonna say that this one is fixed again now that I've found\na more reliable test, but with some (possible) caveats.
\nThe KS->Mashups->Foursquare test was always able to\nreliably produce a correct result for me. I would recommend you\ntest it before performing the following, which you may need to do\nif you keep getting geolocation errors from it:
\nIf you must do this, it appears to be an Apple bug that has to\ndo with geolocation fussiness in the transition from 3.1.x to 3.2,\ninternally. Not sure why.
\nSecond, I've opened up bug #2106,\nwhich indicates how certain module listeners may interact poorly\nwith themselves. 4SQ demonstrates this when used in conjunction\nwith any other geolocation requests on a different context - so\ndon't run the 4SQ test in the same session that you run\ngeolocation.
Reassigning back to me. Thom should catch it because it's\nfixed-in-qa anyway.
thanks for the info Stephen, closing against iPod 4th gen (4.1),\n3g 3.1.2 with mobile sdk build 1.5.0.62c1cae
I can authenticate using Basic Authorization with my app using\ncurl but returns 401 error with titanium most recent nightly\n1.4.2-r8e708e78. Were there commits to the code to change correct\nthis problem. Something is not right. The alternative to setting\nheaders is to embed username:password in url ie. https://user:pw@example.com which\nI had tried before but is also broken. See ticket #2149.\nPerhaps the original issue is related to #1502 which\nis unresolved.
Sorry. To be clear, I can authenticate against my api using curl\nusing name:pw in url or by setting headers. With Titanium app\ncannot get past 401 with headers set and cannot authenticate with\nuser:pw in url due to #2149.
to scrub
Our testing shows this to be working properly.
\nIf there is an issue, it is likely with 2149, which we are\ninvestigating.
Hi Stephen. There is something here that is not getting picked\nup with whatever you are doing for testing. The httpclient does not\nconsistently work. In fact, I can demonstrate authentication\nfailure where curl succeeds always with same credentials (with\nheaders set or user:pw in url where titanium fails on both counts.\nI am prepared to create a small app to demonstrate.
Have not had a reply to above. The client is not reliable.\nPlease advise whether you are willing to look at code that will\ndemonstrate failure and I will bundle a small app to send along\nwith instructions to demonstrate failure. Will need some detail for\nsending as will not post here. Am going to attempt wrapping another\nlib as a module in the interim. Am frustrated by the problems and\nthe block to development on iOS.
fairwinds - if you could post the file to drop.io and send me\n(thuelbert@appcelerator.com)\nan email, I'll make sure the file gets to Stephen. Thanks.
Thomas. drop.io has been bought so will be unable to post there.\nWill simply send app.js content with some instructions as soon as I\nhave them written up. I would expect this later today or tomorrow.\nYou will see by the small example bad things have become with a\nsmall piece of code that does nothing but fetch json using the\nclient. Parse, authentication failure, headers being ignored, and\ninability to get content as needed from the client. This will be\ncontrasted 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\nissue where headers cant be set properly. I am using the latest\ncont build from Dec 23 (Dec 23 2010 14:19 readb8ad1) and tested on\nthe emulator and iphone device (4.2) No matter what I try I can\nnever override the content-type, it always is:\napplication/x-www-form-urlencoded;
\nConsider the following code:
\nvar xhr = Titanium.Network.createHTTPClient();
\nxhr.onload = function()
\n{
\nTi.API.info('I am in utf-8 onload for POST');\n\n}; xhr.onerror = function()
\n{
\nTi.API.info('I am in utf-8 error for POST');\n\n}; xhr.setRequestHeader(\"setoutside\", \"one\");
\nxhr.open(\"POST\",\"http://api.localmedia.fm/files/endpoint_webform.cfm\");
\nxhr.setRequestHeader(\"content-type\", \"multipart/form-data\");
\nxhr.setRequestHeader(\"setinside\", \"two\");
\nxhr.send({\"a\":\"hi\", \"b\":\"there\"});
When this hits my server I have the following headers:
\nAccept-Encoding gzip
\nConnection keep-alive
\nContent-Length 12
\nContent-Type application/x-www-form-urlencoded; charset=utf-8
\nCookie CFID=3538862; CFTOKEN=38108057
\nHost api.localmedia.fm
\nSetinside two
\nUser-Agent Appcelerator Titanium/cont-1.6.0 (iPhone Simulator/4.2;\niPhone OS; en_US;)
\nX-Requested-With XMLHttpRequest
Please follow bug #2675. We are in the process of revising our XHR\nsupport 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\npost stuff to the server without using multipart/form-data, here's\nhoping it is fixed soon, I will watch 2675. It is worth nothing\nthough that adding the interface bits to my app was a breeze with\nappcelerator :)