为了研究无cookie的session，我决定使用上面已经使用过的代码，看看它能否在session状态被设置为cookieless的服务器环境中能否工作正常。我也不想费心去删除cookie容器的相关代码，因为我希望得到能在两种session状态下都正常工作的代码。作为一个天生的乐观主义者，我一个字也不改就直接运行它。令人失望的事发生了——不过也不是完全没有想到，我不得不面对这个异常：
An unhandled exception of type 'System.Net.WebException' occurred in system.web.services.dll
Additional information: The request failed with the error message:
--
Object moved to here.
发生了什么呢？原来HTTP请求收到的不是“200 OK”响应。如果你熟悉HTTP协议，你或许可以从响应中的HTML代码中发现这是一个“302 Found”响应，这意味着该请求被重定向到超链接中指定的地址。返回HTML代码是很明智的，这样如果一个浏览器因为某些原因不支持重定向的话，它可以把代码显示出来，或者在重定向过程中显示这些代码直到重定向完成。注意到超链接中包含了一个有趣的字符串“(l2z3psnhh2cf1oahmai44p21)”，显然，我们可以推断这就是ASP.net的会话ID，它被嵌入了我们要重定向到的位置的URL中。在客户端代理中，我们需要做的仅仅是重新发送请求到这个新的URL。
无须再在Win32 WinInet API编程中跋涉，我们可以直接找到proxy类的一个属性允许自动重定向。用外行人的说法，就是如果我们接收到一个“302 Found”响应，就直接将请求重新发送到相应中HTTP位置头所指示的URL。当Visual Studio.net的智能提示显示proxy类的AllowAutoRedirect属性时，我感到这东西真是机灵得可爱。我马上就在代码中加上如下一行：
proxy.AllowAutoRedirect = True
我认为这仍然比创建一个CookieContainer类并关联到proxy类要容易得多，于是我又一次运行程序。很不幸，我遭遇了如下异常（为了简洁起见有所删节）：
An unhandled exception of type 'System.InvalidOperationException' occurred
in system.web.services.dll
Additional information: Client found response content type of 'text/html; charset=utf-8',
but expected 'text/xml'.
The request failed with the error message: …
如果你看到错误消息的内容，你会发现你所看到的HTML页面跟你浏览.ASMX文件的页面一样。问题是，为什么当我传送XML（以SOAP封装了的形式）到Web Service服务器时它返回的却是HTML代码？结果证实，你并没有在SOAP封装中发送HTTP POST请求，而仅仅发送了一个简单的没有内容的HTTP GET请求，因此你的Web Service服务端理所当然地假设这个请求来自浏览器，于是它返回普通的HTML响应。为什么会这样呢？
如果你了解HTTP协议，你会发现一个HTTP客户端在收到“302 Found”响应时发送HTTP GET请求到响应中指定的地址是合情合理的，即使初始请求是HTTP POST。这种方式下浏览器工作得很好，因为开始几乎所有的请求都是HTTP GET类型的，只有当你试图传递数据到一个URL时，才会出现上述失败的结果。
理由是在传送的数据中可能包含潜在的敏感数据，因此你需要确认是否用户真的想向新的资源传送数据。显然如果你转向基于重定向设置的新地址，你就没能确认用户是否真的允许将他们的数据发送到新的地址。因此数据并没有被发送，而代之以简单的HTTP GET请求。
