Titanium JIRA Archive
Titanium SDK/CLI (TIMOB)

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

GitHub Issuen/a
Resolution Date2011-04-15T03:11:58.000+0000
Affected Version/sn/a
Fix Version/sn/a
Labelsdefect, ios, iphone, xhr
ReporterBryan Jackson
AssigneeRalf Pfeiffer


When sending a request to XHR to the following URL:

http://mike@demandocat.com:testing@api.lafitness.com/Services/Private.svc/GetCustomer"> http://mike@demandocat.com:testing@api.lafitness.com/Services/Priva...

The request is directed to demandocat.com instead of api.lafitness.com.

Some sort of issue exists parsing URLs that contain username/passwords when they contain the @ char.


  1. Bryan Jackson 2011-04-15

    Note the title should say iPhone not Android

  2. Don Thorp 2011-04-15

    Fixed title to reflect iPhone, not Android.

  3. Ralf Pfeiffer 2011-04-15

    to scrub

  4. Blain Hamon 2011-04-15


    The authority (Username and host info) is defined as [ userinfo "@" ] host [ ":" port ]

    userinfo is defined as *( unreserved / pct-encoded / sub-delims / ":" )

    unreserved is defined as ALPHA / DIGIT / "-" / "." / "_" / "~"

    pct-encoded is defined as "%" HEXDIG HEXDIG

    sub-delims is defined as "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "="

    In none of userinfo is "@" allowed as a valid character.

    Per rfc 3986, the URI is requesting host of demandocat.com, port 'testing', which is an invalid number. Thus, this URI is invalid.

    To specify a userinfo that would contain the "@" character, it MUST be pct-encoded as "%40"

  5. David Pratt 2011-04-15

    Invalidated without any evaluation to ensure authentication is possible using this means or test case for basic auth? The ability for a client to pass credentials by this means is very basic functionality. It does not work with this client with iOS.

    Before closing or invalidating the ticket, it would be preferable to demonstrate that the functionality performs as expected or repair/assign if it does not. This issue has been satisfactorily repaired for Android with a test confirmation one can now properly authenticate. I feel this has been evaded. This is necessary functionality for web services work and we have a crippled client if it cannot perform basic authentication using this method.

  6. David Pratt 2011-04-15

    Blain. I can put together something that demonstrates the inability to authenticate by passing credentials in url where doing same in curl succeeds. Passing credentials in this way is a common thing to want to do and this requires a fix.

  7. Ralf Pfeiffer 2011-04-15

    Hello fairwinds,

    Our current situation:

    With URLs, we have already gone down the slippery slope in Titanium. I would have preferred that we were strict in the main API, and yet also provide helper functions to encode/decode, escape, where the algorithms are well-documented and understood.

    In the coming months we will systematically scrub our API and seek to achieve a good balance between achieving better standards compliance as well providing functionality for ease of use by the end developer.

    On this specific issue:

    Blain's comment is accurate, that "@" is not allowed in the userinfo, and that if non-allowed characters exist, they should be escaped. In this case if "@" is the userinfo should be "%40".

    What we will do:

    We'll take the action to discuss this issue internally, as Android and iOS differ in their approach right now.

    Thanks for your input, and expect an update on this within a week.

    ~Ralf Dir of Platform Engineering

  8. David Pratt 2011-04-15

    Hi Ralph. Not sure the issue for me was properly characterized by the ticket. The core issue for me is not simply the @ in the name but authenticating via:

    http://user:pw@example.com">http://user:pw@example.com or

    neither of which will authenticate using the client. Am quite happy to encode the user:pw string including any @ character that might exist there.

  9. David Pratt 2011-04-15

    Ralph. One of those examples should be https above, sorry for typo.

  10. Lee Morris 2017-03-09

    Closing ticket as invalid.

JSON Source