CODEWITHSUNDEEP
c#iisreporting-serviceshttpwebrequestgetresponse
BIdude
BIdude

Reputation: 111

WebRequest fails with "414 Request URI too long" in ASP.NET application

We have an ASP.NET application that requests an SSRS 2005 report in HTML format after passing the parameters for the report as a WebRequest. The application only fails when a report with a large number of multi-select parameters is requested, throwing a "414: Request URI too long" error at the webRequest.GetResponse() line.

The code used to make the request is:

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();

As the report fails on the server side, I have looked into IIS and ReportServer properties to increase the maxUrl, maxRequestLength, MaxQueryString, etc. in terms of bytes (as per this article) but the application still throws an error. I have tried this in the web.config files and directly on the IIS manager.

The reporting server version in 2005 and it is hosted on Windows Server 2008, which is running IIS 7.

On David Lively's advise I tried requesting the URI by putting the parameters in the body. This works for smaller requests, but still fails for large multi-select parameters. The amended code is as follows:

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();

Even though the requestURI of the webRequest does not store parameters, it seems that the GetReponse() function adds the parameters to the 'address' property of the webRequest. could this be the problem? if so, how can it be fixed.

Upvotes: 11

Views: 14815

Answers (7)

Timur Lyapin
Timur Lyapin

Reputation: 1

Had a similar issue, except that POST was working, but second POST with exactly same parameters returned 414.

Setting req.KeepAlive = false; solved the problem, God knows why.

Upvotes: 0

peter
peter

Reputation: 42207

I got this at work on my IIS7 site. Got it fixed with a registry hack, i can search it up but won't work before 3/1. Meanwhile, try if you get the error when you use the ip-address in stead of the normal URL, when you don't, chances are high it is the same problem.

Upvotes: 1

Richthofen
Richthofen

Reputation: 2086

webRequestURL.IndexOf("&") ... Is this meant to be "?" instead of "&"? I'm guessing you construct a valid URL for querying the page and then reverse engineer it to be a POST request by looking for the URL before the first '&'...

However, it's possible the GetResponse is appending the body to the URL because it sees the Question Mark in the URL and assumes that the parameters must go in the URL? Try doing a more exact URL match with zero parameters and no '?'.

Upvotes: 1

Andrew
Andrew

Reputation: 1616

Can you show the value of webRequestURL?

It's going to be "too big".

If you are passing parameters to this URL, can they be in the POST body instead?

Upvotes: 1

Jay Sampat
Jay Sampat

Reputation: 195

Check your service's binding settings. I guess the service will allow the string upto 8192 length. Set te readerQuotas to a larger size. Might help.

...

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

.....

Upvotes: 3

Kasapo
Kasapo

Reputation: 5384

Is it possible for you to use POST variables instead of GET? That way, there are no limits that I'm aware of, as all of your data will be sent in packets instead of HTTP headers.

Actually it looks like you might be using POST from what's in your code. Can you look in the server logs to verify the URI that is causing this to fail? If you're sending POST data, the request uri shouldn't be an issue unless it's unrelated to the data you're POSTing.

Upvotes: 5

3Dave
3Dave

Reputation: 29051

Since you're already using POST to fetch the report, I'd suggest putting the parameters that you're currently passing in the query string in the request body, instead. Querystring parameters work fine for a limited number of parameters, but aren't appropriate for a large number of items.

Upvotes: 2

Related Questions