It appears that pre-205 behavior for getCanonicalServiceName was to return ":0" if the fs uri didn't contain an authority, ie. "har:///my.har", "path/my.har", etc. Otherwise if it had an authority, it would try to convert the host to an ip and return it. If that failed, just return the unresolved host.
Nathan and I discussed, and here's our recommendation:
The real problem is that a filesystem has no means of signifying that it does not have tokens. Logically, a filesystem with no tokens should not have a service name for its non-existent token. Perhaps getCanonicalServiceName should return null if the filesystem does not support tokens. The TokenCache can skip that filesystem while getting tokens. Null avoids a conflict with any valid credentials key, including empty string.
The solution will be similar to John's earlier patch. Instead of har returning an empty string service, it will return null. The token cache will skip filesystems that return a null service. The filesystem base class will return null if the uri has no authority. I think this covers all use cases with <10 LOC.
The NPE in the token method will be changed into a more reasonable exception in the ip->host change. However, these exceptions won't be a problem if har returns a null service, instead of calling the methods with bad input that triggers the exception.
Thoughts? If this is not acceptable, what are the sticking points?