当浏览器发出请求时可以正常处理，但当同一台计算机上的 ASP.NET 应用程序发出请求时则不能处理
我正在调试在 Cassini 的不同实例下的同一台计算机上运行的两个 ASP.NET 应用程序，并且“自定义错误”关闭。一个应用程序在端口 100 上运行，并希望从在端口 90 上运行的另一个应用程序执行 GET 请求。因此它运行以下代码：
WebRequest request = WebRequest.Create(
"http://localhost:90/Controller/Action?Param1=foo&Param2=bar");
request.Timeout = 10000;
request.GetResponse();
最后一行抛出 WebException带有 HTTP 400 代码和 null InnerException。如果我在剪贴板中复制完全相同的 URL，将其粘贴到在同一台计算机上运行的 IE 中 - 请求将在端口 90 上排队到应用程序，并调用其 /Controller/Action/ ，甚至参数也会被调用顺利通过。
这里的问题根源可能是什么以及如何解决？
I'm debugging two ASP.NET applications running on the same machine under different instances of Cassini and with "custom errors" off. One app is running on port 100 and wants to perform a GET request from the other app running on port 90. So it runs this code:
WebRequest request = WebRequest.Create(
"http://localhost:90/Controller/Action?Param1=foo&Param2=bar");
request.Timeout = 10000;
request.GetResponse();
and the last line throws a WebException with HTTP 400 code and null InnerException. If I copy the very same URL in clipboard, past it into IE running on the same machine - the request is queued to the app on port 90 and its /Controller/Action/ is invoked and even parameters are passed okay.
What could be the problem origin here and how do I solve it?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我认为你应该尝试不带参数的网址。
如果它确实有效，您需要添加一些用户代理标头以允许使用参数。
您或许还应该看看 WebClient。
MSDN
我个人还会考虑使用 IISExpress 或 IIS 来开发此类解决方案。
这里只是一个局外人的观察，考虑通过浏览器的 ajax 调用来调用第二个 web 方法，并使用 javascript (jQuery) 聚合客户端的结果。
I think you should try without the params in the url.
if it does work you need to add some user-agent headers to allow the use of params.
Also you should probably look at WebClient.
MSDN
personally I would also look at using IISExpress or IIS to develop this kind of solution.
Just an outsider's observation here, consider making this call to the second webmethod via an ajax call from the browser and aggregate the results clientside using javascript (jQuery).
我会尝试使用 采用 URI 对象的 WebRequest.Create 重载，这样您就可以排除错误的 URL。
I would try and use the overload of WebRequest.Create that takes a URI object, that way you can rule out a fat-fingered URL.
调试了两个小时 - 结果发现端口 90 处的服务会将请求重定向回端口 100 处的服务，但不会在 URL 中提供所需的参数，因此端口 100 处的服务中的处理程序将抛出异常并返回 HTTP 400，然后由
GetResponse()报告。解决方案是更改逻辑，以便不对该特定请求进行重定向，因为重定向对于该特定请求没有任何意义。陪审团认为 Cassini 和 ASP.NET 均无罪。
Two hours debugging - and it turned out that service at port 90 would redirect the request back to the service at port 100 but wouldn't provide a required parameter in the URL, so the handler in the service at port 100 would throw an exception and return the HTTP 400 which was then reported by the
GetResponse(). The solution was to change the logic so that there's no redirect for this specific request because the redirect would make no sense for this specific request.And the jury finds both Cassini and ASP.NET to be not guilty.