wbemcli doesn't accept baseline dot ('.', 46 ASCII) character in username/password part of the URL, because it's considered as key/host delimiter, even if it's positioned before auth token delimiter ('@').
After looking at it a bit, I'm not sure what is the purpose of checking for '.' at this point to begin with. We end up overwriting the value of p after the 1st conditional, in all cases, so it's only relevant to that 1st conditional, which is the block of code that parses the user:password. And we shouldn't care about '.' in the user:password. I don't know what the original intent was, but as as it stands it looks like this code does nothing at all (except cause a bug!)
Indeed, your patch simply advances the ptr to '.' to a value to the right of '@'... which really just ensures the following conditional is always true... and then we discard p. So it's all starting to look useless.
Am I missing something? Does not the attached patch do the same thing?
I tested with a URL like:
wbemcli gi 'http://user.id:pass.w0rd@[fe80::aaaa:bbbb:cccc:dddd%eth0]:5988/root/cimv2:Linux_ComputerSystem.CreationClassName="Linux_ComputerSystem",Name="myhost.mydomain.com"'
Thanks for pointing this out.
After looking at it a bit, I'm not sure what is the purpose of checking for '.' at this point to begin with. We end up overwriting the value of p after the 1st conditional, in all cases, so it's only relevant to that 1st conditional, which is the block of code that parses the user:password. And we shouldn't care about '.' in the user:password. I don't know what the original intent was, but as as it stands it looks like this code does nothing at all (except cause a bug!)
Indeed, your patch simply advances the ptr to '.' to a value to the right of '@'... which really just ensures the following conditional is always true... and then we discard p. So it's all starting to look useless.
Am I missing something? Does not the attached patch do the same thing?
I tested with a URL like:
Committed to CVS