Problem Description
When a GET request should be returning a status of "301" or "302", I have the 3.3.0 GA SDK returning a "200".
Switching back to the 3.2.3 GA SDK fixes the problem.
When we have tested using the following code, the status returned is "302" in 3.3.0.GA and "301" in 3.2.3.GA.
Steps to reproduce
a) Create a simple project.
b) Update this code in app.js:
var xhr = Titanium.Network.createHTTPClient();
xhr.autoRedirect = false;
xhr.allResponseHeaders = true;
// what to do if it loads
xhr.onload = function(e) {
Ti.API.log('Status = ' + this.getStatus());
if (this.getStatus() == 301) {
Ti.API.log('Redirect to ' + this.getResponseHeader('location'));
} else {
Ti.API.log('This should have returned a 301 not a 200');
}
};
xhr.open('GET', 'http://google.co.nz');
xhr.send();
c) Run this with testing environment
Test results
In Titanium SDK: 3.3.0.GA
[DEBUG]: Application booted in 125.191987 ms
[INFO] : Status = 302
[INFO] : This should have returned a 301 not a 200
In Titanium SDK: 3.2.3.GA
[DEBUG]: Application booted in 110.395968 ms
[INFO] : Status = 301
[INFO] : Redirect to
http://www.google.co.nz/
Some sample code:
var xhr = Titanium.Network.createHTTPClient(); xhr.autoRedirect = false; xhr.allResponseHeaders = true; // what to do if it loads xhr.onload = function (e) { Ti.API.log('Status = ' + this.getStatus()); if (this.getStatus() == 301) { Ti.API.log('Redirect to ' + this.getResponseHeader('location')); } else { Ti.API.log('This should have returned a 301 not a 200'); } }; xhr.open('GET', 'http://google.co.nz'); xhr.send();Possibly related to TIMOB-15871.
hello, I commented that I could give you a solution but not the right as it is impossible for me to handle the error. My url is for session start and redirects the browser along with a session cookie. var xhr = Ti.Network.createHTTPClient({timeout: 8000, autoRedirect: false}); // xhr.onreadystatechange = function() { if(this.readyState == 3){ var cookieArray = xhr.getResponseHeader("Set-Cookie"), //read cookie locationArray = xhr.getResponseHeader("Location") // read location redirect } //IF NULL cookiearray error or session no valid }; xhr.open("POST", "http://myurl.com/login"); xhr.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded; charset=utf-8'); xhr.send({ "var1": "value1", "var2": "value2" }); By the way for iOs simply establish autoRedirect: false
[~mdelmarter] I'm looking at the source code and we're returning the status code that native implementation is giving us. https://github.com/appcelerator/APSHTTPClient/blob/master/APSHTTPClient/APSHTTPResponse.m#L25 I tested the URL you provided and it does return a redirect status code, 301. This is making the http client redirect to a different URL, http://www.google.co.nz/. If you still want to go to that URL, add the [autoRedirect](http://docs.appcelerator.com/titanium/latest/#!/api/Titanium.Network.HTTPClient-property-autoRedirect) property to the request to false
Hi Pedro, Did you see my sample code above? autoRedirect is already set to false. As mentioned, running the exact code I submitted, and in the exact environments I submitted, the status returned is "200" in 3.3.0 and "301" in 3.2.3. I am not sure how else to describe the issue. Maybe it is Yosemite, or iOS 8 beta 5 that is key to seeing this issue? But my bug report is accurate for my build environment, and on my iPhone running iOS 8 beta 5.
You're right, my mistake. I just ran it with 3.3.0.GA and this is what I got.
I'll give it another shot with iOS 8Got the same thing with iOS 8 and Xcode 6-Beta 4
Hi Pedro - it still intrigues me that you are getting a "302" instead of a "200" which I am getting on: * Yosemite + Xcode 5.5.1 + Simulator 7.1 + 3.3.0GA SDK. * Xcode 5.5.1 + iOS Beta 5 + 3.3.0GA SDK. Thanks for looking into it though.
I think we can establish that this problem is not reproducible on OS X Version: 10.9.3. As mentioned in the initial bug report the problem was happening on Yosemite - which is OS X Version 10.10. And also on iOS 8 beta 5. Not iOS 7.1. All the tests I see here to reproduce and try and fix this issue are not using the platforms initially reported on? Maybe the issue is isolated to these environments. Can anybody clarify with a test on these platforms?
Hello [~mdelmarter]: In order to move this bug from TC to TIMOB, we need to provide a testcase. The testcase was tested on Ti Mobile SDK 3.3.0.GA, that's the reason it's being shown here. Best Regards
[~emerriman] To find duplicate.
Ran the test code provided using the following environment: Mac OSX 10.9.4 Appcelerator Studio, build: 3.4.0.201409021758 Titanium SDK build: 3.4.0.v20140903121714, 3.3.0.GA, 3.2.3.GA Titanium CLI, build: 3.4.0-beta, 3.3.0 Alloy: 1.5.0-beta Xcode6-Beta7, Xcode5.1.1 iOS Devices iPhone 5(8.0b5), iPhone 5(7.1.1) As shown in the table below on both 3.4.0.v20140903121714 and 3.3.0.GA the status being shown is 200, this differs from 3.2.3.GA which gives us a 301. Using the Firefox webconsole to monitor this however I see that the website differs from all of these and gives a 302 status code followed by a 200 as shown in the attached screenshot || ||Status Code|| ||3.4.0.v20140903121714| 200 | ||3.3.0.GA| 200 | ||3.2.3.GA| 301 |
@Ewan - I am so glad that somebody else has managed to confirm this issue.
Really hoping to get a hot patch for this soon - I cannot update to SDK 3.3.0 or 3.4.0 without this fix, and with iOS 8 out the door it is getting more urgent.
Out of curiosity is this bug fix/patch related? https://github.com/appcelerator/APSHTTPClient/pull/16
PR's merged APSHTTPClient - https://github.com/appcelerator/APSHTTPClient/pull/17 Titanium SDK master - https://github.com/appcelerator/titanium_mobile/pull/6230 3_4_X - https://github.com/appcelerator/titanium_mobile/pull/6245
I can confirm that this fixes the issue. Thanks so much - you have no idea how happy it makes me to be able to use the 3.4.0 SDK in my app finally :)
Verified fix on: Mac OSX 10.10.1 Appcelerator Studio, build: 3.4.1.201410281743 Titanium SDK build: 3.5.0.v20141124155715, Titanium CLI, build: 3.4.1 Alloy: 1.5.1 iPhone 6 Plus (8.1), iPhone 6 Simulator (8.2) Using the test case provided ran on simulator and device the status code returned is 301 as expected. Closing ticket.