When a service registers itself with the naming service it seems the servicename (/) that is used as a key is case sensitive in the internal dictionary.
The side effect of this design decision/bug is that the callers that go to resolve the service have to supply the exact case sensitive url (fabfic://.
A bigger impact of this is using the reverse proxy because if the ultimate caller (caller outside the cluster) does not put the right casing in the following reverse proxy semantic path
http(s)://<Cluster FQDN | internal IP>:Port/<ServiceInstanceName>/<Suffix path>?PartitionKey=<key>&PartitionKind=<partitionkind>&ListenerName=<listenerName>&TargetReplicaSelector=<targetReplicaSelector>&Timeout=<timeout_in_seconds>
then the service does not get resolved. So in some sense it now depends on the caller whether they get resolved or not and we are now saying that our product url is case sensitive.
Questions
a) Is this a deliberate decision by the SF team or is this a bug?
b) Are there any guidelines around it. I can replace the reverse proxy with a custom code than can normalize casing pattern that we agree for our cluster.
Thx