[TIMOB-1502] HTTPClient: problems with header parsing and responseData in onerror handler

GitHub Issue	n/a
Type	Bug
Priority	Trivial
Status	Closed
Resolution	Fixed
Resolution Date	2011-04-17T01:56:20.000+0000
Affected Version/s	n/a
Fix Version/s	Release 1.5.0 M04
Components	iOS
Labels	getresponseheader, httpclient, ios, iphone, responsedata
Reporter	Robby
Assignee	Reggie Seagraves
Created	2011-04-15T02:54:30.000+0000
Updated	2011-04-17T01:56:20.000+0000

Description

Using SDK 1.4.0 release. I have a site that gives back a token in both the header (and as the body) of a HTTP 401 (auth required) response. For the life of me, I can't get HTTPClient to be able to get anything but NULL out of this.responseData/this.responseText. Also, this.getResponseHeader() for my custom header always shows up as NULL. If I change the returned code to 200 (OK), then I can get the responseText/responseData result no problem, but still can't parse my custom X-GUID response header.

So what I'm trying to say is that I may be running into two separate problems here:

getResponseHeader doesn't appear to work properly on error (4xx/5xx) OR valid (2xx) responses: One user in the Q&A section thinks it's because only the first header is being retrieved:
http://developer.appcelerator.com/question/49401/cookies-problem">http://developer.appcelerator.com/question/49401/cookies-problem
responseData/responseText is not populated on error responses (onerror callback handler), even if there is data in the response body. More info on this at: http://developer.appcelerator.com/question/50501/problem-getting-responsetextheaders-from-error-response"> http://developer.appcelerator.com/question/50501/problem-getting-re...
having HTTP auth problems with basic HTTP (but that may be already fixed going into 1.5.0, so I'll make another bug if that appears to be the case)

All in all, unless I'm being stupid here, it appears that HTTPClient is pretty broken for all but the most basic usecases in this 1.4.0 release. :/

Comments

Brion Vibber 2011-04-15
The getResponseHeader bit is covered in #519 but hasn't been fixed yet: https://appcelerator.lighthouseapp.com/projects/32238-titanium-mobile/tickets/519-problem-with-this-in-callbacks-for-xhr"> https://appcelerator.lighthouseapp.com/projects/32238-titanium-mobi...

This is hitting us for StatusNet Mobile; we need to be able to check the content-type so we don't try to parse XML on non-XML fetches (and thus explode), and it's a bit frustrating for these basic things to just not work.

Sample code to reproduce:
```
   var client = Titanium.Network.createHTTPClient();
   client.onload = function() {
       Titanium.API.info("Loaded! Status: " + this.status);
   
       var contentType = this.getResponseHeader('Content-Type');
       Titanium.API.info("Content-Type: " + contentType);
   };
   client.open("GET", "http://example.com/");
   client.send();
   
```
got on iphone:
[INFO] Loaded! Status: 200 [INFO] Content-Type: null <- BROKEN

got on android:
I/TiAPI (11249): (kroll$1) [23,606] Loaded! Status: 200
I/TiAPI (11249): (kroll$1) [13,619] Content-Type: text/html; charset=UTF-8 <- fine

Assigning to our support contact.

Brion Vibber 2011-04-15

Workaround: pull headers from an original reference instead of the 'this' reference:

   var client = Titanium.Network.createHTTPClient();
   client.onload = function() {
       Titanium.API.info("Loaded! Status: " + this.status);
   
       var contentType = this.getResponseHeader('Content-Type');
       Titanium.API.info("Content-Type (from this): " + contentType);
   
       var xcontentType = client.getResponseHeader('Content-Type');
       Titanium.API.info("Content-Type (from client): " + xcontentType);
   };
   client.open("GET", "http://example.com/");
   client.send();

which gives on iPhone:

   [INFO] Loaded! Status: 200
   [INFO] Content-Type (from this): null
   [INFO] Content-Type (from client): text/html; charset=UTF-8

and on Android:

   I/TiAPI   (11302): (kroll$1) [29,639] Loaded! Status: 200
   I/TiAPI   (11302): (kroll$1) [4,643] Content-Type (from this): text/html; charset=UTF-8
   I/TiAPI   (11302): (kroll$1) [1,644] Content-Type (from client): text/html; charset=UTF-8

Ralf Pfeiffer 2011-04-15

to scrub.
Stephen Tramer 2011-04-15

Paring this down to 2. only. #519 has been resolved and auth issues are separate and being addressed.
Jeff Haynie 2011-04-15

(from [4a2acd75260b60f09a89b23c26856039ad7a4b75]) [#1502 state:fixed-in-qa] No longer erase response information on failures. Need to revisit this for XHR compliance. https://github.com/appcelerator/titanium_mobile/commit/4a2acd75260b60f09a89b23c26856039ad7a4b75"> https://github.com/appcelerator/titanium_mobile/commit/4a2acd75260b...
Stephen Tramer 2011-04-15

Note that better XHR compliance is scheduled for a near-future release. If the XHR standard says that we MUST or SHOULD not provide any response data on 401, etc. then we will not.
Pedro Enrique 2011-04-15
test file exists in bug tests.
Tested in iPhone 4 running 4.2 and Simulator 4.2
SDK 1.5 12/9/2010 - r43358e5f

When testing on simulator, changed Titanium.API.info() to alert() to I could see the result

Console:
```
   [INFO] Error! Status: 401
   [INFO] Response: <html><body>YOU CAN'T HANDLE THE AUTHORIZATION</body></html>
   
```

JSON Source