[TIMOB-2535] iOS: XHR getAllResponseHeaders() returns NSDictionary instead of String

GitHub Issue	n/a
Type	Bug
Priority	High
Status	Closed
Resolution	Fixed
Resolution Date	2014-06-24T21:20:35.000+0000
Affected Version/s	Release 2.1.4, Release 3.1.3
Fix Version/s	Release 3.3.0, Release 3.4.0
Components	iOS
Labels	module_network, parity, qe-manualtest, qe-testadded
Reporter	Bill Dawson
Assignee	Pedro Enrique
Created	2011-04-15T03:22:08.000+0000
Updated	2014-08-15T23:00:43.000+0000

Description

I know you guys are going to re-visit XHR compliance in the future, I thought I'd throw this one in because our Android implementation supports it and it's in the spec. There's already a drillbit test for it in network.httpclient.js (test: responseHeadersBug), but I avoid running the getAllResponseHeaders stuff if it's iphone os, until you implement it. So after you implement it, just take out the if block and - bang! - you've got your drillbit test!

Comments

Anirudh Nagesh 2012-11-14

Requesting it to implement as a next feature to support consistency across all platforms. HD Ticket: APP-532487
Pier Paolo Ramon 2014-06-12

In Titanium SDK *3.3.0.RC* HTTPClient#getAllResponseHeaders has been implemented… but in a totally wrong way. It returns a NSDictionary of headers instead of a string. While it IS a pretty cool feature it should do it with a different name, as it was before (allRespondeHeaders). This is also a feature parity issue with Android. IMHO 3.3.3.*GA* should not ship with this issue.
Pier Paolo Ramon 2014-06-20

Any info on this?

Pedro Enrique 2014-06-24

Test case

   var win = Ti.UI.createWindow();
   var btn = Ti.UI.createButton({
   	title: 'here'
   });
   btn.addEventListener('click', function(){
   	var xhr = Ti.Network.createHTTPClient();
   	xhr.onload = function() {
   		Ti.API.info('--------------------');
   		Ti.API.info(this.getAllResponseHeaders());
   		Ti.API.info('--------------------');
   	};
   	xhr.open('GET', 'http://google.com');
   	xhr.send();
   });
   win.add(btn);
   win.open();

Result should be in parity with Android:

   X-XSS-Protection:1; mode=block
   Expires:-1
   X-Frame-Options:SAMEORIGIN
   Content-Type:text/html; charset=ISO-8859-1
   P3P:CP="This is not a P3P policy! See http://www.google.com/support/accounts/bin/answer.py?hl=en&answer=151657 for more info."
   Server:gws
   Alternate-Protocol:443:quic
   Date:Tue, 24 Jun 2014 21:00:15 GMT
   Cache-Control:private, max-age=0
   Set-Cookie:PREF=ID=bd119415e82c9847:U=463504427065f3e7:FF=0:TM=1403643614:LM=1403643615:S=bQTO_0beCluwQ_dW; expires=Thu, 23-Jun-2016 21:00:15 GMT; path=/; domain=.google.com, NID=67=KUhGTdpFS0guw-JzMx4A7lgyI59vHCJBSXIdh3n2YRTDWZMFHUnvpMjiNxLdfLSiHuaP8WXRWJaqspt7hfyvh7SlIGga_P9Gh-pr0J-x5y8Oub4WUmgHx-M8F0nF4G7o; expires=Wed, 24-Dec-2014 21:00:15 GMT; path=/; domain=.google.com; HttpOnly
   Transfer-Encoding:Identity

PR

Master: https://github.com/appcelerator/titanium_mobile/pull/5843 3_3_X https://github.com/appcelerator/titanium_mobile/pull/5844

Samuel Dowse 2014-06-30

Verified fixed on: Mac OSX 10.9.3 Appcelerator Studio, build: 3.3.0.201406271159 Titanium SDK, build: 3.3.0.v20140627202512 Titanium CLI, build: 3.3.0-rc4 iOS Device: iPad Air (7.1.1) iOS output is in parity with Android:

X-XSS-Protection:1; mode=block
   Expires:-1
   X-Frame-Options:SAMEORIGIN
   Content-Type:text/html; charset=ISO-8859-1
   P3P:CP="This is not a P3P policy! See http://www.google.com/support/accounts/bin/answer.py?hl=en&answer=151657 for more info."
   Server:gws
   Alternate-Protocol:80:quic
   Date:Mon, 30 Jun 2014 20:59:54 GMT
   Cache-Control:private, max-age=0
   Set-Cookie:PREF=ID=6a1009a14454a438:FF=0:TM=1404161994:LM=1404161994:S=_lX5AfwHKv39fU0u; expires=Wed, 29-Jun-2016 20:59:54 GMT; path=/; domain=.google.com, NID=67=EOay-dPkjid_hHo9gmK2q_WObmkTp3eR9QRpSLRTHC2T0usCxTeg-GiyrOP9KU9Y-Jtxm8zOZnrCHpLiwD94OFUT8kwp7DhUETfJRx1yWeF-l2_7_Bm_FuxwKhEkN6ge; expires=Tue, 30-Dec-2014 20:59:54 GMT; path=/; domain=.google.com; HttpOnly
   Transfer-Encoding:Identity

Closing.

JSON Source