免责声明:
正如@feroze 之前所说,将您的 cookie 域设置为 localhost 对您来说效果并不好。我假设您正在编写一个帮助程序,允许您将 HTTP 请求通过隧道传输到外部域。请注意,这不是最佳实践,并且在很多情况下不需要(即jQuery 内置了很多很酷的跨域支持,另请参阅新的CORS 规范)。但有时您可能会卡在这样做(即外部资源仅是 XML,并且位于不支持 CORS 的服务器上)。
关于 Cookie 域及其工作原理的背景信息:
如果您还没有查看过HTTP Cookie:Wikipedia 上的域和路径——您需要知道的几乎所有内容都在其中。
在评估 cookie 时,客户端(“本地”请求者)和 Web 服务器(“外部”响应者)都会考虑域和路径。当客户端请求资源时,客户端应仅在这些 cookie 与请求的 URI 的域(或更通用的父域)和路径(或更通用的父路径)匹配的情况下发送 cookie。
Web 浏览器可以正确处理这个问题。例如,如果 Web 浏览器具有域“localhost”的 cookie,并且您正在请求“google.com”,则“localhost”域的这些 cookie 不会在请求中发送到“google.com”。-- 事实上,大多数现代浏览器不仅不会发送它们,它们还会在接收到的 Set-Cookie 响应标头中完全忽略它们(这些称为第三方 cookie——允许在您的网络浏览器是一个巨大的隐私/安全问题——不要这样做!)。
它也可以在另一个方向上工作——即使客户端不太可能在请求中包含第三方 cookie,如果包含,外部 Web 服务器应该忽略它(甚至一些用于正确域/路径的 cookie ,以防止臭名昭著的超级cookie问题。(即托管“example.com”的Web服务器应忽略属于其父域的cookie:“.com”,因为“.com”是“公共后缀”)) .
你应该做什么[如果你必须]:
我向您推荐的操作过程是,当您读取客户端的 cookie(我不是 MVC 人,但在常规 ASP.NET 中,这将在 Request.Cookies 中)时,循环浏览它们(确保过滤掉您自己网站的合法 cookie,尤其是 SessionId 等 - 或正确使用 Path,因此它们一开始就不会发送到此页面),然后一次将它们添加到传出请求的 cookie 集合中,将域重写为“ www.whatever.com”(根据您的示例——如果您正在动态执行此操作,请将 URL 加载到新的 Uri() 对象中并使用 .Host 属性),然后将路径设置为“/”。-- 这将为向外网络服务器的传出请求构建“Cookie”标头。
当该请求返回到您的服务器时,您需要检查新 cookie 的传入响应——这些 cookie 可以重新打包并以与我在前一段中说明的循环类型大致相同的循环发送回您的客户端,除了您'll想重写主机为request.url.host-除非您的传递页面的路径是静态的,否则您需要将路径设置回“/”使用 MVC)然后你想将它设置为 Request.Url.AbsolutePath 例如。
快乐编码!
编辑:
另外,您需要设置传出请求的X-Forwarded-For标记,以便您调用的网站不会认为您的 Web 服务器是一个向它们发送垃圾邮件的单个客户端。