When sending a request to XHR to the following URL:
\n\nhttp://mike@demandocat.com:testing@api.lafitness.com/Services/Priva...
\nThe request is directed to demandocat.com instead of\napi.lafitness.com.
\nSome sort of issue exists parsing URLs that contain\nusername/passwords when they contain the @ char.
(from [805f7249f4257f55c5b1a8691b13ef59669c0b84])\n[#2150 state:fixed-in-qa] Handle @ signs in the\nusername portion of the authority part of a URI. \nhttps://github.com/appcelerator/titanium_mobile/commit/805f7249f425...
This was a \"fun\" one: not even the native Android Uri class\nseemed to handle this properly, whereas falling back to the Java\nURL class seems to work. Maybe if Bryan is listening, he could try\nthis out with our latest build? If you use our continuous\nbuild server, be sure to choose a build on the master branch,\ndated Nov 28 or later.
To Appcelerator QA:
\nWe don't expose any APIs to look at the \"final\" url, host,\nuser-authentication info, etc., so this is hard to test unless you\nuse a protocol analyzer (or setup your own host server ;) ).
\nHere's an example of me using Wireshark in before and after\nscenarios, to show the difference.
... and here's a test app.js to use for it:
\n\nTitanium.UI.setBackgroundColor('#000');\nvar URL = 'http://mike@demandocat.com:testing@api.lafitness.com/Services/Private.svc/GetCustomer';\n\nvar xhr = Ti.Network.createHTTPClient();\n\nxhr.onerror = function(e) {\n 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.');\n};\nxhr.onload = function(e) {\n 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.');\n};\n\nxhr.open('GET', URL);\nxhr.send();\nHow dowes this impact #2149? I don't understand priority.\n#2149 given low priority while #2150 high\npriority for same issue on two platforms
The iPhone team has not prioritized the issue. Our fixing of\n#2149 has no impact positive or negative on the\niOS issue.
Hi. The priority on the ticket is set to Low on the ticket. Am\nfinding the httpclient in iOS for most part unusable and in a\ndeteriorating state. Not quite sure where to go with this as months\nare going by. I can send and receive json but in only the most\nbasic way and it is virtually useless for my apps since\nauthentication and transport are handicapped by issues that are\nstacking up (as long as seven months)
\nStandard authentication schemes, setting request headers,\ngetting response headers and this passing credentials in url are\nbasic things you need to get done in a client lib. Despite setting\nup a decent generic method for handling http, it is not my code but\nthe client that is broken, regresses and remains this way. To\nsummarize the issues in iOS:
\nA common thing to want to do with titianium is to interact with\na web service and has become increasingly frustrating since even\nbasic authentication cannot be accomplished without setting\nauthorization headers or passing credentials in a url, and JSON\ncannot be transported without errors in or in a secure way. I am\nsure you can get a sense that this is impossible to work with.
\nCan you advise whether you employ any unit testing on your side\nto see such things before they are reported? This is second time\nround for discussing headers for me and there is no doubt others\nare not finding lighthouse to report the trouble. I believe this is\nat least a second or third regression setting request headers.
\nIf these things cannot be fixed, perhaps replacing with\nsomething better is a reasonable option. I have attached a link for\na reliable general purpose http and REST lib used in many\nsuccessful iPhone projects and which includes unit tests. Please\nforward this to someone on the iPhone team to examine for potential\nwrapping. If things do not improve, I will be looking to wrap some\nof this generic functionality.
\n@fairwinds this is not a forum and polluting the tickets with\ninformation unrelated to the ticket doesn't help at all. Please\nmove your comments over to the iPhone ticket and make sure they\napply to that ticket. This is an android only ticket. Thank\nyou.
You are right of course - however the point is that tickets have\nbeen filed and some are now up to 7 months old. I will write\nanother for requestHeaders since this is another regression of this\nissue. Not sure whether anyone there understands the impact the\nissues are having as a whole. The client is seriously crippled at\nthis point. Where should this be communicated as each ticket on its\nown does not consider the scope of the issues that have left the\nclient in a virtually unusable state for application\ndevelopment.
Pass Titanium SDK version: 1.5.0 (12/01/10 09:30 ac7cfd8),\nAndroid Sim 1.6. 2.1, custom app