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。