by Njål

CORS = XmlHttpRequest to other servers – without JSONP

 

imageAs Webstep guru Thor Halvor explained in the this excellent blogpost – there are security restrictions to prevent/limit cross domain access of XMLHttpRequest’s – the cornerstone of AJAX.

Flash and silverlight has the same restrictions – and solves this by using crossdomain.xml and clientaccesspolicy.xml. These files are placed on the server you want to communicate with – and must contain * or the domain you want to contact the server from.

Anyways – there is a similar mechanism that XMLHttpRequest supports. This mechanism is called CORS – Cross-origin resource sharing. It is a newer(2004) and preferred alternative to JSONP – and works more or less like the xml files mentioned above. The only difference is that it isn’t implemented as a file – it’s part of the HTTP Header. This makes it a bit more difficult to set up than the others.

When a javascript on siteA wants to make a request to siteB – then the script first makes an initial OPTIONS request to site B – and looks at the HTTP Header it receives.

Access-Control-Allow-Origin: *

 

If the value is * – then it means that XmlHttpRequests can communicate with that site – from any other server – and a regular XMLHttpRequest can be made just like you were communication with your own server. You can of course type in domain names here to prevent everybody from using your API.

Here’s how to configure this on an Microsoft IIS Server – Web.Config – under the <configuration> node

<system.webServer>
  <httpProtocol>
    <customHeaders>
       <add name="Access-Control-Allow-Origin" value="*" />
    </customHeaders>
  </httpProtocol>
</system.webServer>

 

So to sum it up: use CORS whenever possible, instead of hacking your way around with JSONP. You’ll have prettier code, better error handling and it’s safer to use with regard to XSS Attacks as far as I have understood. Also – CORS supports all types of HTTP requests (Get/Post/Put,Delete), while JSONP only supports Get.

Read more about CORS here:
http://my.opera.com/core/blog/2011/10/28/cors-goes-mainline

A third (and the newest) alternative is UMP – I might blog more about this some other time.

by Njål

WebClient // HttpWebResponse – Problems with Chunked Transfer encoding

 

Doing a HTTP POST to a webserver using C# is pretty easy using the System.Net.HttpWebRequest. However – if you need to retrieve the answer/reply from the webserver – you’ll often get an exception:

Exception: 'Unable to read data from the transport connection: The connection was closed.'

When looking at the HttpWebResponse in the debugger – the length of the response is -1, so something strange is going on here.

When investigating further in the VS 2010 debugger/ Fiddler, I found out that the webserver (IIS 7 in this case) is sending the response using Transfer-Encoding: Chunked – which is relatively common in HTTP 1.1. It means that the length of the message isn’t specified in the HTTP Header Content-Length, but in the message itself.

Nothing wrong with this – but apparently HTTPWebResponse does not support Chunked Transfer Encoding (and thereby not HTTP 1.1).

The easiest way to fix this is to make sure the HttpWebRequest is sent using HTTP 1.0 – this way the server will reply with a HTTP Header specifying Content-Length.

HttpWebRequest wr = (HttpWebRequest)WebRequest.Create("http://www.degree.no");
wr.ProtocolVersion = Version.Parse("1.0");

An easier/alternative way of doing HTTP Communication in the .NET framework is the System.Net.WebClient class. But since it uses HttpWebRequest under its hood,  the same problem occurs here.

There is no way (afaik) to specify WebClient to use HTTP 1.0 – so use HttpWebRequest with HTTP 1.0 if you need to POST something to a server and read the response.