[TIMOB-24983] Android: Add "HTTPClient.responseHeaders" support (feature parity with iOS)
GitHub Issue | n/a |
---|---|
Type | Improvement |
Priority | Low |
Status | Closed |
Resolution | Fixed |
Resolution Date | 2020-11-20T14:33:22.000+0000 |
Affected Version/s | n/a |
Fix Version/s | Release 9.3.0 |
Components | Android |
Labels | HTTPClient, android, network, parity |
Reporter | Joshua Quick |
Assignee | Gary Mathews |
Created | 2017-07-19T22:46:52.000+0000 |
Updated | 2020-11-20T14:33:22.000+0000 |
Description
*Summary:*
This is a feature parity issue between Android, iOS, and Windows Phone when using HTTPClient.
On iOS, you access the HTTP response's headers via the "responseHeaders" property, which returns them as a dictionary...
http://docs.appcelerator.com/platform/latest/#!/api/Titanium.Network.HTTPClient-property-responseHeaders
On Android and Windows Phone, you have to access the headers via the "allResponseHeaders" property instead, which returns all headers concatenated to a single string...
http://docs.appcelerator.com/platform/latest/#!/api/Titanium.Network.HTTPClient-property-allResponseHeaders
*Solution:*
Add "responseHeaders" property support to Android. The way iOS is doing it (returning a dictionary) is the superior solution. (In the future, we should add support to Windows as well.)
*Note:*
Check if iOS includes the response's "status line" in 1 of it's returned headers. This is because Android's Java HttpURLConnection.getHeaderFields() method does return the status line in the returned HashMap, which is using a null key. In my opinion, we should not return status line as a header in JavaScript (this is what our HTTPClient.statusText property is for), but we should double check our iOS implementation and follow what it does.
FR Passed, Waiting on Jenkins build.
*Closing ticket*. Fix verified in SDK version
9.3.0.v20201119063936
. Test and other information can be found at: https://github.com/appcelerator/titanium_mobile/pull/11899