When retrieving server data, there are a few choices of format. Most commonly, the server will return data formatted as JSON or data formatted as HTML. If JSON is returned, the client will parse the response and decide for itself what to do with the information. If HTML is returned, the client will most likely place the html somewhere on the page. Both options have advantages and disadvantages.
As a common theme that will be seen in many of my future articles, jQuery isn’t the only library for doing ajax requests. Any of the following are perfectly good (and lighter-weight) alternatives.
Retrieving HTML Data
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
1 2 3 4 5 6 7 8 9
1 2 3 4 5 6 7 8
Retrieving JSON Data
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
1 2 3 4 5 6 7 8 9
- “Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource…”
Sending Data to the Server
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Please note that the above action method accepts a complex object as a parameter. This works because of the .NET framework, but there is a gotcha that is explained below.
1 2 3 4 5 6
Submitting json data:
1 2 3 4 5 6 7 8 9 10 11 12 13 14
The server does not need to change to accept json data.
The action method parameter isn’t being populated even though the data is being sent.
By far the sneakiest cause of this issue is that the .NET framework only populates properties of an object. Thus, even if the object type has the correct members, the members have to be declared as properties, not just public fields.
The action method parameter isn’t being populated, but I’m not sure if the data is being sent correctly or not.
Use the browser’s developer tools to inspect the request being sent. It should show exactly what data was sent to the server. Make sure the data was actually sent and that the variables are named correctly.
- Seeing that it is a cross-origin request, the browser first sends an HTTP OPTIONS request (no different than POST, PUT, etc.) to the exact same url.
- If the server responds to the OPTIONS request with the correct headers, the browser allows the request to continue.
Nifty, right? In order to implement it, the server must respond with the “Access-Control-Allow-Origin” header set to the origin of the requester. In .NET, this can be done with the following code:
Note that some say to add “Access-Control-Allow-Origin: *”, but that doesn’t work it all situations. Lists also do not work, as in “Access-Control-Allow-Origin: domain.com, another.com.” The safest path is the one described above. In the case of cross-origin file uploads, the following header may also be required:
If cookies are being sent along in the request, set the Access Control Allow Credentials to true.
It still says “cross-origin request blocked…”, and the headers are not being set correctly.
Make sure the server isn’t throwing an exception. The headers may not be set correctly in that case, causing the request to fail. Also, make sure the server responds correctly to HTTP OPTIONS requests. Try making a request with HTTPRequester or other tool.
It still says “cross-origin request blocked…”, and the headers are being set correctly.
Make sure the access-control-allow-origin header is exactly the same as the origin header property in the request, e.g. no trailing slashes. Also keep in mind that the browser gives this “cross-origin request blocked…” error very liberally even in situations where the request wasn’t blocked, the server just returned an error code.