Silverlight clientaccesspolicy.xml bug? or design?
clientaccesspolicy.xml, silverlight
Solution
The behavior you describe is in line with the documentation, which states:
There are three types of wildcards allowed:
A standalone '*' wildcard. This option is used to allow access to all domains of the same scheme. An HTTP service will allow all HTTP callers. An HTTPS service will allow all HTTPS callers.
An "http://*" literal wildcard. This option explicitly allows all HTTP callers, even if this is an HTTPS service.
A subdomain wildcard. This option uses a wildcard at the first segment of the path ("http://.contoso.com", for example) that allows all subdomains of the domain specified. So for the example. http://web.contoso.com and http://mail.contoso.com would be allowed. Note that a uri path where the wildcard does not occur as a prefix (http://web..com, for example) is disallowed.
http://msdn.microsoft.com/en-us/library/cc645032(VS.95).aspx
So there's nothing about wildcards for ports, which (you're right) does not make any sense when you allow wildcards for hosts and domains.
Problem
In the domain node of a clientaccesspolicy file you can specify a wildcard for a sub domain or protocol, but it would appear not for a port. Specifically when developing, if the service consumed is hosted on a third party, then access from a local debug version of a silverlight app running on the localhost asp.net development server works fine with the nodes: ``` <domain uri="*"/> <domain uri="http://*"/> <domain uri="http://localhost:1234"/> ``` (where 1234 is the specific determined port number) but it would appear not to work if specified in the form ``` <domain uri="http://localhost:*"/> ``` which is extremely annoying if there are multiple developers/projects using the service or you do not specify a port for the asp.net development server Does annyone know if I am simply getting the format incorrect or is this either a bug or an oversight in the handling of the clientaccesspolicy by silverlight?