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…)
本文地址：http://com.8s8s.com/it/it2527.htm