The WebClient class uses the WebRequest class to provide access to resources.
You must use the WebClient class from a Silverlight control that is hosted in a Web page.
The following table describes WebClient methods for uploading data to a resource.
Method | Description |
|---|
OpenWriteAsync | Retrieves a Stream used to send data to the resource asynchronously, without blocking the calling thread. |
UploadStringAsync | Sends a String to the resource, without blocking the calling thread. |
The following table describes WebClient methods for downloading data from a resource.
Method | Description |
|---|
DownloadStringAsync | Downloads a String from a resource, without blocking the calling thread. |
OpenReadAsync | Returns the data from a resource asynchronously, without blocking the calling thread. |
You can use the CancelAsync method to cancel asynchronous operations that have not completed.
A WebClient instance does not send optional HTTP headers by default. If your request requires an optional header, you must add the header to the Headers collection.
Some headers are considered restricted and are either exposed directly (such as Content-Type) or protected by the system and cannot be set in a WebHeaderCollection object. Any attempt to set one of these restricted headers in the WebHeaderCollection object using the Item[([(HttpRequestHeader])]) or Item[([(String])]) property or throws an exception. If the WebHeaderCollection object is associated with a HttpWebRequest object, the exception is thrown by the Item[([(HttpRequestHeader])]) property. If the WebHeaderCollection object is associated with a WebClient object, the exception is thrown when an attempt to send the WebClient request occurs.
For a list of restricted headers, see the Remarks in the WebHeaderCollection class.
Silverlight 2 and later have support for cross-domain connectivity which allows an application to access resources from locations other than the site of origin. This is an important feature for enabling Silverlight applications to consume existing services on the web. The security policy system in the Silverlight runtime requires that a policy file be downloaded from a network resource before a network connection is allowed access to that resource. This security policy system affects cross-domain network access for WebClient and HTTP classes in the System.Net namespace. Network connections for WebClient and HTTP classes to the site or host of origin do not require a security policy. For more information, see Network Security Access Restrictions in Silverlight.
For security reasons, the Silverlight runtime restricts access to certain classes of URLs from the WebClient and HTTP classes in the System.Net namespace. There are similar access restrictions applied by the Silverlight runtime to other classes including the Image and MediaElement classes in the System.Windows.Controls namespace. The Silverlight runtime also applies access restrictions to XAML source files and font files based on the class of URL.
The connections affected are access to cross-zone, cross-domain, and cross-scheme URLs. These restrictions are designed to prevent networking threats (for example, threats based on a Silverlight application run from an internet server getting access to resources on a local intranet server). For more information, see Network Security Access Restrictions in Silverlight and URL Access Restrictions in Silverlight.
For security reasons, the Silverlight runtime restricts the WebClient class from sending specific headers to a cross-domain site unless the header is allowed by the security policy applicable to the target cross-domain site. This restriction applies to resources from locations other than the site of origin. The Authorization header can be set using the Headers property. However to set the credentials properly, the cross-domain policy applicable to the target must have the http-request-headers set to allow the Authorization header to be sent.
Version Notes
.png)
Silverlight for Windows Phone
Six active Web service connections are allowed simultaneously. Additional requests are paused until a connection is available.
Derived classes should call the base class implementation of WebClient to ensure the derived class works as expected.