XMLHTTP发送HTTP请求失败的可能性分析
(一) Access Denied
TomoSoft ID Number: Q20011122
Article last modified on 11-22-2001
The information in this article applies to:
Microsoft XML, versions 2.6, 3.0, 3.0 sp1
提要
现在我们越来越离不开XMLHTTP对象和ServerXMLHTTP对象了。为了更好地驾驭,一定要搞清楚她们的特性,以及在何种情况下她们会闹别扭。
本文尽可能地给出她们的出错的各项相关报告。由于我自己的个人经验教训,我更关注“Access Denied”这个话题。其他方面的报告请各方高士整理一下了。
我们将会混着XMLHTTP和ServerXMLHTTP说,虽然她们从底层协议到特性均不相同,但是她们的共同之处还是挺多的。
“ACCESS DENIED”和“Permission Denied”
如果我们用ServerXMLHTTP对象访问一个用了集成Windows验证的web站点时,传递的NT用户名密码无效或者没有相应的权限,自然会遭遇到Access Denied,这一点毋庸置疑。
也就是说,虽然微软没有禁止传递空的用户名密码,但是实践证明这么做,可能会给你带来点麻烦。
我的一次经历就是我当前的子线程会默认从父线程那里继承Security Context,而父线程的用户身份是有权限的,但是子线程调用ServerXMLHTTP对象提交一个HTTP操作,就会得到一个“Access Denied”。那里我就是没有传递用户名和密码。
所以我们的第一个定理就是:
定理1 但凡你能在XMLHTTP或者ServerXMLHTTP的open方法时传递用户名密码,就请一定传,即使这时的进程的运行身份是邮件管理员。
它附带的一个推论是:
即使你曾经给open方法传递空用户名密码测试成功,也不意味着未来在其他环境中同样的代码仍然可以奏效。
有时候,你在XMLHTTP或ServerXMLHTTP的open时传递的NT用户名密码,它是有权限执行该项HTTP操作的,但是它偏偏也报告“Access Denied”。这又是为什么呢?
微软的一种解释就是,这是由它们的底层实现的特性所决定的。:)
对于XMLHTTP:
当XMLHTTP对象向一个Remote URL发送HTTP请求时,它用的是the Internet Explorer URLMON和WinInet组件。因为这些组件是被设计在“A Regular User Process”这种情况下使用的,而IIS和ASP会对URLMON和WinInet的某些功能性造成不良影响。
所以微软说,不赞成在ASP脚本页面中使用“Microsoft.XMLHTTP”对象(即XMLHttpRequest)来向其他Web Servers发送请求。因为这可能导致一些无法预料的后果,如肯定是不能连接SSL(HTTPS) Server的,等等。
这个问题在Knowledge Base 的Q304420一文中也有论述。在这篇《XMLHTTP Open Method Fails with "Permission Denied" Error》的文章中,描述的现象就是:
虽然文章没有说为什么,但是我相信就是上面所阐述的道理。
所以依照微软的建议,这里有了定理2:
如果你要从Server-Side ASP script中做一个HTTP请求,请使用ServerXMLHTTP对象。
对于ServerXMLHTTP:
MSXML 3.0使用的是Windows HTTP Services(WinHTTP)。
如果在调用ServerXMLHTTP代码的机器上,WinHTTP Proxy configuration setting没有配置或者没有正确配置,都会造成“Access Denied”!
这是因为ServerXMLHTTP对象需要依赖于WinHTTP来建立server-to-server的HTTP连接。这时可能会有两种可能:
一是没有运行Proxycfg.EXE来正确地设置proxy setting;
二是在运行Proxycfg.EXE配置之后,没有重新启动IIS。
至于如何下载Proxycfg.EXE,如何配置proxy setting,请参看《Q289481 INFO: Proxy Configuration Utility Must Be Run for ServerXMLHTTP to Work》,这里不再详述。
(先写这么多吧,To Be Continued…)