跨域问题来源于JavaScript的同源策略，即只有 协议+主机名+端口号 (如存在)相同，则允许相互访问。也就是说JavaScript只能访问和操作自己域下的资源，不能访问和操作其他域下的资源。
在以前，前端和后端混杂在一起， 比如JavaScript直接调用同系统里面的一个Httphandler，就不存在跨域的问题，但是随着现代的这种多种客户端的流行，比如一个应用通常会有Web端，App端，以及WebApp端，各种客户端通常会使用同一套的后台处理逻辑，即API， 前后端分离的开发策略流行起来，前端只关注展现，通常使用JavaScript，后端处理逻辑和数据通常使用WebService来提供json数据。一般的前端页面和后端的WebService API通常部署在不同的服务器或者域名上。这样，通过ajax请求WebService的时候，就会出现同源策略的问题。
需要说明的是，同源策略是JavaScript里面的限制，其他的编程语言，比如在C#，Java或者iOS等其他语言中是可以调用外部的WebService，也就是说，如果开发Native应用，是不存在这个问题的，但是如果开发Web或者Html5如WebApp，通常使用JavaScript ajax对WebService发起请求然后解析返回的值，这样就可能存在跨域的问题。
一般的，很容易想到，将外部的资源搬到同一个域上就能解决同源策略的限制的。即在Web网站上同时开发一个Http服务端页面，所有JavaScript的请求都发到这个页面上来，这个页面在内部使用其他语言去调用外部的WebService。即添加一个代理层。这种方式可以解决问题，但是不够直接和高效。
目前，比较常见的跨域解决方案包括JSONP (JSON with padding)和CORS (Cross-origin resource sharing )。一些解决方案需要客户端和服务端配合如JSOP，一些则只需要服务端配合处理比如CORS。下面分别介绍这两种跨域方案，以及服务端WebService如何支持这两种跨域方案。
JSONP以及WebService的支持
同源策略下，某个服务器是无法获取到服务器以外的数据，但是html里面的img,iframe和script等标签是个例外，这些标签可以通过src属性请求到其他服务器上的数据。而JSONP就是通过script节点src调用跨域的请求。
当我们向服务器提交一个JSONP的请求时,我们给服务传了一个特殊的参数,告诉服务端要对结果特殊处理一下。这样服务端返回的数据就会进行一点包装，客户端就可以处理。
举个例子，服务端和客户端约定要传一个名为callback的参数来使用JSONP功能。比如请求的参数如下:
|
1 |
http://www.example.net/sample.aspx?callback=mycallback |
如果没有后面的callback参数，即不使用JSONP的模式，该服务的返回结果可能是一个单纯的json字符串，比如：
|
1 |
{ foo : 'bar' } |
如果和服务端约定jsonp格式，那么服务端就会处理callback的参数，将返回结果进行一下处理，比如处理成：
|
1 |
mycallback({ foo : 'bar' }) |
可以看到，这其实是一个函数调用，比如可以实现在页面定义一个名为mycallback的回调函数：
|
1 2 3 4 |
mycallback = function(data) { alert(data.foo); }; |
现在，请求的返回值回去触发回调函数，这样就完了了跨域请求。
如果使用ServiceStack创建WebService的话，支持Jsonp方式的调用很简单，只需要在AppHost的Configure函数里面注册一下对响应结果进行过滤处理即可。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
/// <summary> /// Application specific configuration /// This method should initialize any IoC resources utilized by your web service classes. /// </summary> /// <param name="container"></param> public override void Configure(Container container) { ResponseFilters.Add((req, res, dto) => { var func = req.QueryString.Get("callback"); if (!func.isNullOrEmpty()) { res.AddHeader("Content-Type", ContentType.Html); res.Write("<script type='text/javascript'>{0}({1});</script>" .FormatWith(func, dto.ToJson())); res.Close(); } }); } |
JSONP跨域方式比较方便，也支持各种较老的浏览器，但是缺点很明显，他只支持GET的方式提交，不支持其他Post的提交，Get方式对请求的参数长度有限制，在有些情况下可能不满足要求。所以下面就介绍一下CORS的跨域解决方案。
CORS跨域及WebService的支持
先来看一个例子，我们新建一个基本的html页面，在里面编写一个简单的是否支持跨域的小脚本，如下：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 data-line="crayon-5812f0f7f394c466501089-29">29 30 31 32 33 面的一个Httphandler，就不存在跨域的问题，但是随着现代的这种多种客户端的流行，比如一个应用通常会有Web端，App端，以及WebApp端，各种客户端通常会使用同一套的后台处理逻辑，即API， 前后端分离的开发策略流行起来，前端只关注展现，通常使用JavaScript，后端处理逻辑和数据通常使用WebService来提供json数据。一般的前端页面和后端的WebService API通常部署在不同的服务器或者域名上。这样，通过ajax请求WebService的时候，就会出现同源策略的问题。
需要说明的是，同源策略是JavaScript里面的限制，其他的编程语言，比如在C#，Java或者iOS等其他语言中是可以调用外部的WebService，也就是说，如果开发Native应用，是不存在这个问题的，但是如果开发Web或者Html5如WebApp，通常使用JavaScript ajax对WebService发起请求然后解析返回的值，这样就可能存在跨域的问题。 一般的，很容易想到，将外部的资源搬到同一个域上就能解决同源策略的限制的。即在Web网站上同时开发一个Http服务端页面，所有JavaScript的请求都发到这个页面上来，这个页面在内部使用其他语言去调用外部的WebService。即添加一个代理层。这种方式可以解决问题，但是不够直接和高效。 目前，比较常见的跨域解决方案包括JSONP (JSON with padding)和CORS (Cross-origin resource sharing )。一些解决方案需要客户端和服务端配合如JSOP，一些则只需要服务端配合处理比如CORS。下面分别介绍这两种跨域方案，以及服务端WebService如何支持这两种跨域方案。 JSONP以及WebService的支持同源策略下，某个服务器是无法获取到服务器以外的数据，但是html里面的img,iframe和script等标签是个例外，这些标签可以通过src属性请求到其他服务器上的数据。而JSONP就是通过script节点src调用跨域的请求。 当我们向服务器提交一个JSONP的请求时,我们给服务传了一个特殊的参数,告诉服务端要对结果特殊处理一下。这样服务端返回的数据就会进行一点包装，客户端就可以处理。 举个例子，服务端和客户端约定要传一个名为callback的参数来使用JSONP功能。比如请求的参数如下:
如果没有后面的callback参数，即不使用JSONP的模式，该服务的返回结果可能是一个单纯的json字符串，比如：
如果和服务端约定jsonp格式，那么服务端就会处理callback的参数，将返回结果进行一下处理，比如处理成：
可以看到，这其实是一个函数调用，比如可以实现在页面定义一个名为mycallback的回调函数：
现在，请求的返回值回去触发回调函数，这样就完了了跨域请求。 如果使用ServiceStack创建WebService的话，支持Jsonp方式的调用很简单，只需要在AppHost的Configure函数里面注册一下对响应结果进行过滤处理即可。
JSONP跨域方式比较方便，也支持各种较老的浏览器，但是缺点很明显，他只支持GET的方式提交，不支持其他Post的提交，Get方式对请求的参数长度有限制，在有些情况下可能不满足要求。所以下面就介绍一下CORS的跨域解决方案。 CORS跨域及WebService的支持先来看一个例子，我们新建一个基本的html页面，在里面编写一个简单的是否支持跨域的小脚本，如下：
|
