[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 aNSDictionary
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:
Closing.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