C# WebRequest失败，返回“0”；414请求URI太长“；在ASP.NET应用程序中

我们有一个ASP.NET应用程序，它在以WebRequest的形式传递报告的参数后，请求HTML格式的SSRS 2005报告。只有在请求包含大量多选参数的报表时，应用程序才会失败，并在

webRequest.GetResponse（）

行抛出“414:Request URI too long”错误

用于发出请求的代码为：

HttpWebRequest webRequest = null;
HttpWebResponse webResponse = null;
string webRequestURL = _ReportManager.GetRSUrl(reportID); //this passes the report link on the SSRS server

//make the request

Byte[] bytes = Encoding.UTF8.GetBytes("xml_doc=" + HttpUtility.UrlEncode(webRequestURL));

webRequest = (HttpWebRequest)WebRequest.Create(webRequestURL);
webRequest.Method = "POST";
webRequest.ContentLength = bytes.Length;
webRequest.Timeout = Configuration.WebRequestTimeOut;

RSExecution2005.ReportExecutionService rsE = new RSExecution2005.ReportExecutionService();
rsE.Url = Configuration.ReportExecutionServiceUrl2005;
rsE.Credentials = System.Net.CredentialCache.DefaultCredentials;
webRequest.Credentials = rsE.Credentials;

Stream reqStream = null;
reqStream = webRequest.GetRequestStream();
reqStream.Write(bytes, 0, bytes.Length);
reqStream.Close();

webResponse = (HttpWebResponse)webRequest.GetResponse();

由于报告在服务器端失败，我研究了IIS和ReportServer属性，以增加maxUrl、maxRequestLength、MaxQueryString等的字节数（根据），但应用程序仍会抛出错误。我已经在web.config文件中以及直接在IIS管理器上尝试过这一点

报表服务器版本为2005年，它托管在运行IIS 7的Windows server 2008上

---

根据David Lively的建议，我尝试通过将参数放入主体中来请求URI。这适用于较小的请求，但对于较大的多选参数仍然失败。经修订的守则如下：

HttpWebRequest webRequest = null;
HttpWebResponse webResponse = null;
string webRequestURL = _ReportManager.GetRSUrl(reportID); //this passes the report link on the SSRS server

string postData = string.Empty;
string URIrequest = string.Empty;
URIrequest = webRequestURL.Substring(0, webRequestURL.IndexOf("&"));
int requestLen = webRequestURL.Length;
int postDataStart = webRequestURL.IndexOf("&") + 1;
postData = webRequestURL.Substring(postDataStart, (requestLen - postDataStart));

Byte[] bytes1 = Encoding.UTF8.GetBytes(postData);

webRequest = (HttpWebRequest)WebRequest.Create(URIrequest);
                webRequest.Method = "POST";
                webRequest.ContentType = "application/x-www-form-urlencoded";
                webRequest.ContentLength = bytes1.Length;
                webRequest.Timeout = Configuration.WebRequestTimeOut;

RSExecution2005.ReportExecutionService rsE = new RSExecution2005.ReportExecutionService();
rsE.Url = Configuration.ReportExecutionServiceUrl2005;
rsE.Credentials = System.Net.CredentialCache.DefaultCredentials;
webRequest.Credentials = rsE.Credentials;

Stream reqStream = webRequest.GetRequestStream();
reqStream.Write(bytes1, 0, bytes1.Length);
reqStream.Close();
webResponse = (HttpWebResponse)webRequest.GetResponse();

---

即使webRequest的requestURI不存储参数，getResponse（）函数似乎也会将参数添加到webRequest的“address”属性中。这可能是问题所在吗？如果是这样的话，如何修复它。

既然您已经在使用POST获取报告，我建议您将当前正在传递的查询字符串中的参数放在请求正文中。Querystring参数适用于有限数量的参数，但不适用于大量项目。

是否可以使用POST变量而不是GET？这样，我知道没有限制，因为您的所有数据都将以数据包而不是HTTP头的形式发送

---

实际上，看起来您可能正在使用代码中的POST。您能否查看服务器日志以验证导致此操作失败的URI？如果您正在发送POST数据，请求uri不应成为问题，除非它与您正在发布的数据无关。

检查您的服务的绑定设置。我想该服务将允许字符串长度达到8192。将te readerQuotas设置为更大的大小。也许会有帮助

---

…您能显示webRequestURL的值吗

它会“太大”

如果您正在将参数传递给此URL，它们是否可以放在帖子正文中？

webRequestURL.IndexOf（“&”）。。。这是不是应该是“？”而不是“&”？我猜您构造了一个用于查询页面的有效URL，然后通过在第一个“&”之前查找URL将其反向工程为POST请求

---

但是，GetResponse可能会将主体附加到URL，因为它在URL中看到问号，并假设参数必须放在URL中？尝试使用零参数和不带“？”的URL进行更精确的匹配。

我在IIS7网站上得到了这一点。用注册表黑客修复了它，我可以搜索它，但在3/1之前不会工作。同时，如果在使用ip地址而不是正常URL时出现错误，请尝试。如果不使用，则很有可能是相同的问题。

也有类似的问题，只是POST正常工作，但使用完全相同参数的第二篇POST返回414

---

设置req.KeepAlive=false；解决了这个问题，天知道为什么。

感谢David的建议，我尝试将参数放入请求正文中，对于较小的参数选择，它可以正常工作，但在选择大量多选参数时仍然失败，并出现相同的错误。请在上面的原始问题中查找我修改的代码和编辑。干杯谢谢Kasapo，我查看了服务器日志，可以看到所做的请求是POST请求。然而，我看不到任何关于我得到的414错误的提及，这很奇怪。我正在查看reportServer实例的IIS日志。

 <basicHttpBinding>
        <binding name="largeBuffer">
          <readerQuotas
                        maxDepth="2147483647"
                        maxStringContentLength="2147483647"
                        maxArrayLength="2147483647"
                        maxBytesPerRead="2147483647"
                        maxNameTableCharCount="2147483647" />
          <security mode="None"></security></binding>
  </basicHttpBinding>