Sunday, January 13, 2013

ContentType is reported incorrectly to Silverlight Applications when setting the Accept Header when running under Chrome 24

ContentType is reported incorrectly to Silverlight Applications when setting the Accept Header when running under Chrome 24

As of Chrome 24 our SilverLight 5.0 application reports the Content-Type response header from the server as text/plain; charset=x-user-defined regardless of what the actual Content-Type was. This only happens when setting the accept header for the request.

This did not happen before Chrome 24 and does not happen on FireFox or Internet Explorer.

Here is sample code:

private void Button_Click( object sender, RoutedEventArgs e ) {     Uri documentUrl;      Uri.TryCreate( HtmlPage.Document.DocumentUri, new Uri( "/test.aspx", UriKind.Relative ), out documentUrl );      HttpWebRequest request = (HttpWebRequest)WebRequestCreator.BrowserHttp.Create( documentUrl );     request.Method = "GET";      //Setting the accept header causes the response to always report the ContentType as text/plain; charset=x-user-defined     request.Accept = "application/json";        request.BeginGetResponse( result =>     {         var response = request.EndGetResponse( result );          //response.ContentType is not what the server responded with         Dispatcher.BeginInvoke( () => textBlock1.Text = "Contenet Type was: " + response.ContentType );     }, null ); } 

Using Fiddler I have checked that the server is sending the correct content type.

Here are the request headers from the silverlight client:

GET http://localhost:54049/test.aspx HTTP/1.1 Host: localhost:54049 Connection: keep-alive Accept: application/json User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.52 Safari/537.17 Referer: http://localhost:54049/TestContentTypeTestPage.html Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3 

Here are the response headers from the server:

HTTP/1.1 200 OK Cache-Control: private Content-Type: application/json; charset=utf-8 Server: Microsoft-IIS/8.0 X-AspNet-Version: 4.0.30319 X-Powered-By: ASP.NET Date: Fri, 11 Jan 2013 21:59:43 GMT Content-Length: 442 

Using javascript to make a XHR call from the hosting html page does report the correct response type. So it seems that there is something broken between Chrome and SilverLight.

Here is the javascript code I used to test:

load('test.aspx', function (xhr) {     console.log(xhr.getResponseHeader('content-type')); }); function load(url, callback) {     var xhr = new XMLHttpRequest();      xhr.onreadystatechange = ensureReadiness;     function ensureReadiness() {         if (xhr.readyState < 4) {             return;         }         if (xhr.status !== 200) {             return;         }         // all is well           if (xhr.readyState === 4) {             callback(xhr);         }     };     xhr.open('GET', url, true);     xhr.setRequestHeader('Accept', 'application/json');     xhr.send(null); } 

I have read through the Chrome 24 release notes and I don't see anything that relates to what I am seeing.

Has any one else run into this or know of a way to work around it?

FYI, we are using Browser Http Handling and we cannot change to Client Http Handling.

Answers & Comments...




No comments:

Post a Comment

Send us your comment related to the topic mentioned on the blog