I am trying to use WWW to connect and download a text file from a web server however I keep getting this exception:

UriFormatException: Invalid URI: The format of the URI could not be determined.
MonoForks.System.Uri…ctor (System.String uriString, Boolean dontEscape)
MonoForks.System.Uri…ctor (System.String uriString)
(wrapper remoting-invoke-with-check) MonoForks.System.Uri:.ctor (string)
MonoForks.System.Windows.Interop.PluginHost.get_SourceUri ()
MonoForks.System.Uri uri)
UnityEngine.UnityCrossDomainHelper.GetSecurityPolicy (System.String requesturi_string,
IPolicyProvider policyProvider)
UnityEngine.UnityCrossDomainHelper.GetSecurityPolicy (System.String requesturi_string)

This only happens in any form of WebPlayer platform both inside and outside the editor however works perfectly fine when used in a standalone or IOS build. Following is the line that creates a new WWW request (dummy used for security).

WWW faqFile = new WWW(“” + (int)(Time.time * 1000));

Where the value on the end is to make sure it returns a new version of the file each time not a cached version, and the dummy ip replaces the original ip.

When the original URL is entered in a web browser I am able to access the file. There is no issues with permissions and no problems with crossdomain.xml.
This is all simply to do with the URI being used as far as I can tell.

Could anyone please shed some light on this issue?


The issue appears to be with the editor emulation of the webplayer. The webplayer appears to be accessing the data fine now. Is there any work-arounds for the editor? It’s kind of a pain to make a new build to test every change.

Thanks for all responses

First: From what place do you run your webplayer? Do you have it on your actual server and load the player via it’s appropriate URL? If not the webplayer is required to check the crossdomain policy file on the server you try to contact.

Another thing is, we have no idea how your URL looks like. A common mistake is to try to add basic authorization information at the front of the URL (with @) but this is not supported by the http. Most browsers interpret this information and add an “Authorization” header to the request.

See this post for how you can add such an header:

There might be something else wrong with your URL, however you stripped the most important part. Can you replace all elements you have in there with dummys and explaind each part?

Otherwise this leads nowhere…