[TIMOB-2150] Android, parse problem with URLs that contain @ in username

(from [805f7249f4257f55c5b1a8691b13ef59669c0b84]) [#2150 state:fixed-in-qa] Handle @ signs in the username portion of the authority part of a URI. https://github.com/appcelerator/titanium_mobile/commit/805f7249f4257f55c5b1a8691b13ef59669c0b84"> https://github.com/appcelerator/titanium_mobile/commit/805f7249f425...

This was a "fun" one: not even the native Android Uri class seemed to handle this properly, whereas falling back to the Java URL class seems to work. Maybe if Bryan is listening, he could try this out with our latest build? If you use our http://builds.appcelerator.com.s3.amazonaws.com/index.html">continuous build server, be sure to choose a build on the master branch, dated Nov 28 or later.

To Appcelerator QA:

We don't expose any APIs to look at the "final" url, host, user-authentication info, etc., so this is hard to test unless you use a protocol analyzer (or setup your own host server ;) ).

Here's an example of me using Wireshark in before and after scenarios, to show the difference.

... and here's a test app.js to use for it:

   Titanium.UI.setBackgroundColor('#000');
   var URL = 'http://mike@demandocat.com:testing@api.lafitness.com/Services/Private.svc/GetCustomer';
   
   var xhr = Ti.Network.createHTTPClient();
   
   xhr.onerror = function(e) {
       Ti.API.info('XHR onerror running with message "' + e.error + '", HTTP response code  ' + xhr.status + '. If the status is "401", that is actually a good thing, as it probably means the request (which contains bogus user/password) indeed went to api.lafitness.com, as desired.  But only a protocol analyzer can confirm this.');
   };
   xhr.onload = function(e) {
       Ti.API.info('XHR onload running. HTTP response code=' + xhr.status + '. This is suspicious, as it suggests the request did not really go to api.lafitness.com, from where we would expect to get a 401, which should cause XHR onerror to run.  But only a protocol analyzer can verify what really happened.');
   };
   
   xhr.open('GET', URL);
   xhr.send();
   

How dowes this impact #2149? I don't understand priority. #2149 given low priority while #2150 high priority for same issue on two platforms

The iPhone team has not prioritized the issue. Our fixing of #2149 has no impact positive or negative on the iOS issue.

Hi. The priority on the ticket is set to Low on the ticket. Am finding the httpclient in iOS for most part unusable and in a deteriorating state. Not quite sure where to go with this as months are going by. I can send and receive json but in only the most basic way and it is virtually useless for my apps since authentication and transport are handicapped by issues that are stacking up (as long as seven months)

Standard authentication schemes, setting request headers, getting response headers and this passing credentials in url are basic things you need to get done in a client lib. Despite setting up a decent generic method for handling http, it is not my code but the client that is broken, regresses and remains this way. To summarize the issues in iOS:

• you cannot set user and password due to this specific issue #2149 Oct
• problem with this in callbacks for XHR issue #519 since Mar
• problems with header parsing and responseData in onerror handler issue #1502 Aug and workaround no longer works on trunk
• setRequestHeaders are broken again on nightly 1.5.0 that I obtained yesterday. This has been an ongoing regression #1983 and prior to that
• my JSON data is now generating parse errors from recent nightly build since and assuming response data is XML. And why wouldn't it - you are unable to set an Accept header or Content-Type header so the client is no longer aware it is getting JSON. So the parser still parses but emits an error. From all indications, this began showing up approximately two weeks ago. Folks have been discussing in Q & A but looks like they gave up.

A common thing to want to do with titianium is to interact with a web service and has become increasingly frustrating since even basic authentication cannot be accomplished without setting authorization headers or passing credentials in a url, and JSON cannot be transported without errors in or in a secure way. I am sure you can get a sense that this is impossible to work with.

Can you advise whether you employ any unit testing on your side to see such things before they are reported? This is second time round for discussing headers for me and there is no doubt others are not finding lighthouse to report the trouble. I believe this is at least a second or third regression setting request headers.

If these things cannot be fixed, perhaps replacing with something better is a reasonable option. I have attached a link for a reliable general purpose http and REST lib used in many successful iPhone projects and which includes unit tests. Please forward this to someone on the iPhone team to examine for potential wrapping. If things do not improve, I will be looking to wrap some of this generic functionality.

http://allseeing-i.com/ASIHTTPRequest/">http://allseeing-i.com/ASIHTTPRequest/

@fairwinds this is not a forum and polluting the tickets with information unrelated to the ticket doesn't help at all. Please move your comments over to the iPhone ticket and make sure they apply to that ticket. This is an android only ticket. Thank you.

You are right of course - however the point is that tickets have been filed and some are now up to 7 months old. I will write another for requestHeaders since this is another regression of this issue. Not sure whether anyone there understands the impact the issues are having as a whole. The client is seriously crippled at this point. Where should this be communicated as each ticket on its own does not consider the scope of the issues that have left the client in a virtually unusable state for application development.

Pass Titanium SDK version: 1.5.0 (12/01/10 09:30 ac7cfd8), Android Sim 1.6. 2.1, custom app