客户端的问题
在你的 WebService中成功的使用HttpSessionState的功能事实上依赖于对用户的一些假设。首先,也是最重要的一点,如果你是用默认的 HTTP Cookie模式来保存Session状态,你的客户端就必须支持cookie;如果你是用无cookie的机制来支持Session,那么你的客户端必须能够并且愿意重定向到一个新的URL,该URL由原来的URL中插入会话ID而得到。结果将表明,这并不是一个无足轻重的问题,它关系到你能否成功地部署你的程序。
所有工作都依赖于浏览器
如果你是用Microsoft Visual Studio.net来开发ASP.net Web Service应用程序,那么默认的调试方法就是打开IE访问你的.asmx文件。通常,系统将提供一个可以调用你的Web方法的友好的界面,这是一个调试你的Web Service代码的很好的途径。如果你已经将Web方法的EnableSession选项设置为true,它被非常漂亮地支持,甚至如果你打开了无 cookie的Session支持,客户端浏览器也可以完美地完成这项工作,你的Session对象将如你所愿地工作。
然而,大多数的Web Service请求不是来自浏览器,而是来自应用程序中的Web引用。我们如何使用.net框架的“添加Web引用”的特性呢?让我们来看一看。
添加Web引用的问题
我将使用我们前面看到的代码段来创建一个简单的XML Web Service。记起来了吧?这个Web方法被称作IncrementSessionCounter,它仅仅是简单地把一个整数存储在 HttpSessionState对象中,然后每次调用则将它加1,并且返回当前值。从客户端浏览器我们可以看到这个数字的值随着调用次数的增加而增加。
下一步,我创建了一个简单的WinForm应用程序,并且将上述的Web Service添加到Web引用中。下面就是调用我的Web Service的代码:
' 这里并没有与Session打交道 Private Sub Button1_Click(ByVal sender As System.Object, _ ByVal e As System.EventArgs) Handles Button1.Click Dim proxy As New localhost.Service1() Dim ret As Integer ret = proxy.IncrementSessionCounter() Label1.Text = "Result: " & CStr(ret) End Sub |
当我第一次调用Web Service时,一切正常,Web方法返回1,这就是那个Session变量的应有的初始值。现在我点击Button1来再次调用这个Web方法,我希望看到的返回值是2。可惜的是,无论我点击多少次Button1,返回值一直都是1。
你也许会怀疑原因就是我每次都创建了一个新的proxy类的实例去调用Web方法,因此每次我点击按钮,都会丢失上一次调用时的cookie。不幸的是,即使你将proxy类的初始化代码移到窗体的构造函数中,然后对每次Web方法调用使用同一个proxy类的实例,你还是不可能看到返回值有增加的迹象。
问题在于cookie。Web Service代码并未从调用请求中发现有效的会话ID,因此它每次被调用都创建一个全新的HttpSessionState对象,并且返回它的初始值 1。因为作为客户端的proxy类是从类System.Web.Service.Protocols.SoapHttpClientProtocol继承的,它不包含System.Net.CookieContainer类的实例,因此,没有地方来存放返回的cookie。为了解决这个问题,我对代码做了如下一些修改:
' 使用了ASP.NET的session ' 但是并不是无Cookie的session. Private Cookies As System.Net.CookieContainer Private Sub Button1_Click(ByVal sender As System.Object, _ ByVal e As System.EventArgs) Handles Button1.Click Dim proxy As New localhost.Service1() Dim ret As Integer ' 为proxy类设置cookie容器 If Cookies Is Nothing Then Cookies = New System.Net.CookieContainer() End If proxy.CookieContainer = Cookies ret = proxy.IncrementSessionCounter() Label1.Text = "Result: " & CStr(ret) End Sub |
现在代码工作正常了!每点击一次Button1,我都可以看到返回值增加1。注意到我并不是在函数中声明变量Cookies的,它是窗体类的一个私有成员,因为如果希望每次都返回同一个会话ID给服务器的话,就必须在每次请求中使用CookieContainer类的同一个实例。这就解释了为什么 SoapHttpClientProtocol类默认不自动地设置的cookie容器。正应为此,你可以在多个 SoapHttpClientProtocol类的实例中共享一个cookie容器,而不是为其每个实例自动地创建一个新的cookie容器。
无cookie的Session
从Web Service的开发者的角度来看,你可以想到相当多的人在试图使用你的Web服务时忘记在客户端代理类中添加Cookie容器。聪明的开发者或许灵光一闪,就会发现无cookie的Session应该可以出色地解决这个问题。如果将web.config文件中sessionState元素的 cookieless参数设置为“true”,你将会发现,通过浏览器界面调用Web方法时,session变量工作正常,但是如果你在Visual Studio.net中通过“添加Web引用”来调用它时,依然存在着一些问题。
为了研究无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: -- <html><head><title>Object moved</title></head><body> <h2>Object moved to <a href='/HttpSessionState/(l2z3psnhh2cf1oahmai44p21)/service1.asmx'>here</a>.</h2> </body></html> |
发生了什么呢?原来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请求。
我对代码做了如下修改,捕获“302 Found”异常,提示用户同意重定向他们的请求,然后再次在新的位置调用我的Web方法。
' 同时使用基于Cookie和Cookie的Session Private Cookies As System.Net.CookieContainer Private webServiceUrl as Uri Private Sub Button1_Click(ByVal sender As System.Object, _ ByVal e As System.EventArgs) Handles Button1.Click Dim proxy As New localhost.Service1() Dim ret As Integer ' 设置proxy类的Cookie容器 If Cookies Is Nothing Then Cookies = New System.Net.CookieContainer() End If proxy.CookieContainer = Cookies ' 设置proxy类的URL If webServiceUrl Is Nothing Then webServiceUrl = New Uri(proxy.Url) Else proxy.Url = webServiceUrl.AbsoluteUri End If Try ret = proxy.IncrementSessionCounter() Catch we As WebException ' 如果我们想检测HTTP状态码 ' 那么就需要一个HttpWebResponse类的实例 If TypeOf we.Response Is HttpWebResponse Then Dim HttpResponse As HttpWebResponse HttpResponse = we.Response If HttpResponse.StatusCode = HttpStatusCode.Found Then ' 这是一个“302 Found”响应,提示用户是否进行重定向 If MsgBox(String.Format(redirectPrompt, _ HttpResponse.Headers("Location")), _ MsgBoxStyle.YesNo) = _ MsgBoxResult.Yes Then ' 用户选择Yes,重新尝试新的URL webServiceUrl = New Uri(webServiceUrl, _ HttpResponse.Headers("Location")) Button1_Click(sender, e) Return End If End If End If Throw we End Try Label1.Text = "Result: " & CStr(ret) End Sub |
现在ASP.net的Session工作正常了。在你的应用程序中,你可以根据情况自行决定是否提示用户重定向HTTP POST请求。举一个例子,如果你正在调用一个Web Service,你也许就不希望出现任何可见的对话框。
这样看来,要使ASP.net的Session完全正常地工作还真不是很容易。但是,应该意识到上面的代码所展示的原理在其他情况下一样的有用。例如,任何平台上的任何Web Service,只要它使用HTTP cookie,都需要一个cookie容器,类似地,也许有很多其他的原因导致当你向一个Web Service服务器发送请求时收到“302 Found”响应。在一个复杂的应用程序中调用Web Service时,可能有许多特殊的情形需要你去处理,cookie和重定向的问题就是两种这样的情形,你应该将之作为你的Web Service调用代码中最基本的部分。
结 论
在你调用Web方法的过程中,ASP.net对状态保持是非常有用的,你必须意识到,当你使用手边的浏览器界面测试你的Web Service时,你并没有面对客户端程序必须处理的问题。幸运的是,这些问题并不是很难解决。