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 。
[末页] 选择页数 1 2
