[转载]一种基于代理CGI技术的跨域永久性解决方案 - tenfyguo的技术专栏 - 博客频道 - CSDN.NET

      前两天，我的一位同事问我有没有一种办法实现imgcache.qq.com和face.qq.com的cookie互操作，我说有，方案很简单，只要把 cookie的domain设置成.qq.com的域名后缀就可以了，这样一来，在face.qq.com域名中设置的cookie的值，在 imgcache.qq.com域中也可以检索到，同样，在imgcache.qq.com设置中的cookie也可以在face.qq.com中检索 到，所以可以非常方便的实现cookie的跨域名互操作的目的。

那么，这种方案有没问题呢？或者说有哪些方面是我们觉得有点“不爽”的？答案是肯定的，首先一个重要的问题是跨域名的cookie污染，通过设 置cookie的域名为.qq.com，该方案会使得所有发送到*.qq.com的http Request的请求头（cookie的信息是通过Http 请求头进行携带的)均带上cookie信息，一方面这些cookie的信息只是face.qq.com中才需要使用的，而对其他后缀也是qq.com的业 务是不需要使用到这些cookie信息的，因此，这里发送多余的请求头信息对网络带宽来说是一种浪费，如果cookie的信息量比较少还可以，如果携带的 信息量很大显然该方案很容易受到挑战的。那么，该方案有什么好处呢？简单，是的，该方案的实现成本很低。

好，回到我们刚才的需求场景：实现用户最近设置的头像列表（共保存6个），由于face.qq.com一般是在qq客户端的mini portal打开的，用户一般不会在地址栏看到face.qq.com的域名，为了提高性能，只把首页放到face.qq.com的域名下，而对其他的静 态页面放到自建的CDN imgcache.qq.com，以实现用户访问业务的最近接入。显然，我们通过把用户最近设置6个头像item的id保存到cookie中，并且设置域 名.qq.com是可以使得在imgcache.qq.com域名下的静态页面访问和设置的最近设置列表并且该设置共享到face.qq.com域名下 的。

如果现在我们要求设置的cookie信息既能够在face.qq.com中访问，同时imgcache.qq.com的静态页面也可以访问，但 又不造成域名污染，有没办法？这里tenfy想到了一种可以实现上面头像的需求并且不造成cookie的跨域名污染，取名为基于代理cgi的技术方案，顾 名思义，该方案需要在face.qq.com的域名下部署一个代理cgi以实现cookie信息的跨域名访问，我们暂把该代理cgi叫做 cookie_proxy.cgi，该cgi的功能很简单：1，设置当前登录用户的最近设置的头像item；2，获取当前登录用户的最近设置头像的 item list，并且这些item 信息是设置到域名为face.qq.com的cookie中的，通过这样的处理使得cookie的信息只会在浏览器发送到face.qq.com的请求头 中才会带上，从而对其他域名的业务不会造成污染。有了该代理cgi就很方便了，在域名为face.qq.com的页面，获取和设置最近设置的头像 list，只需要操作自己域名下的cookie信息即可；而对imgcache.qq.com域名下页面，现在则无法通过从cookie中读取最近的设置 列表，但可以通过访问域名face.qq.com下的代理cgi获取最近的设置列表，同理，也不要把最近设置的item设置到 imgcache.qq.com的cookie中，因为这样，face.qq.com下的页面是无法访问的，而是通过代理cgi进行设置即可，当然这里的 操作都是通过调用异步的接口进行设置的，并且也不是关键的路径。

那么，对上面的需求来说，哪种方案更好呢？大家可能会觉得代理cgi的方案更好，但，如果是我，则会选择方案一，理由是实现简单，方便，几乎没 什么维护成本，并且在客户端使用的头像业务会使得跨域名的cookie污染问题变得更加不care，原因是头像的mimi portal是qq客户端单独打开一个IE控件进行显示的，并且用户无法在该mini portal中通过浏览器URL进行其他业务的访问，有的话，也是跟头像业务相关的其他几个小入口，这使得因为cookie请求头带来的多余带宽浪费显得 更加微不足道了（因为用户再单独打开的浏览器访问qq.com的页面是不可能带上这些cookie的）。