The fact that Silverlight has limited features is no problem for me – I understand that with a smaller runtime you get less features, and I am grateful for the Silverlight alternative to WPF. A workaround is easy enough once you know where the problem is.

Which brings me to my point. I wasted a lot of time trying to figure out why I was only getting FileNotFound responses to my web requests. Stupidly, I referred to the online help:

http://msdn.microsoft.com/en-us/library/system.net.httpwebresponse.statuscode(VS.95).aspx

and it didn’t tell me of the limitations so I just kept plugging away.

So please keep your help files up to date and don’t forget to include the bad news.

In your post, you show the use of custom headers and in the reply. You also seem to point to them as a work around for other limitations (X-HTTP-Method-Override). However, when I actually try to use a custom header in Silverlight, it bombs. Remove the custom header and all is good (except of course you can’t do what you are trying to accomplish). Is this something that is supposed to work or was it intentionally left out?

Thanks,
~Jeff

WebClient ignores HTTP headers concerning the encoding of the response. This means that UTF-8 response will incorrectly be decoded using whatever is the default system code-page (and thus break extended characters very easily in an internationalization-dependent fashion). This is most unfortunate; HTTP supports the specification of a character set via the MIME type (or an explicit header) – is there a chance this will be fixed?

Concretely, unless a developer is extremely careful, using WebClient will result in a broken program depending on where the silverlight app is run, and even if the developer is extremely careful, it’s not possible to perform a robust http request using WebClient; instead, a rather complex series of fallbacks must be implemented using HttpRequest. Even without encoding auto-detection, such an implementation is needlessly error-prone and difficult to test, and as such would be a prime candidate for inclusion in WebClient (which seems to be intended to be simple, after all).

With ref to synch calls, i appreciate that asynch are largely preferable and we would be using them if we could but we are building a mapping site which calls to a GIS application for content. This application solely supports synchronous calls and so we are now in a position of looking for another GIS engine or using another web delivery mechanism…

Andy

What I would like to see is example of searching and downloading YouTube videos. I believe these API are created to build RIA sites that consume you own content, but not the content from other sites, or at least friendly sites.

I wish someone would just say “YouTube and Google Content are just off limits to silverlight, no mater what type of cross domain support we provide”

IS THIS TRUE? if not can you provide a simple example?

The GET / POST methods are okay, since we can use the x-http-method-override pattern.

I am concerned about the limited support for HTTP response codes. How would we handle a 401 to implement security?

A real world example of something I am working on is to consume RESTful services in a SilverLight client via a server, which is secured using digest authentication. It would seem awkward to navigate to the web server and be prompted with the browser’s default credentials dialog prior to even downloading the SilverLight application. How would we do this in a cross-domain scenario?

I also noticed that the WebClient class does not even have a Credentials (ICredentials) property like the full framework.

Cheers,

Stuart