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

7

11

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.

Inchoation answered 5/12, 2012 at 16:39 Comment(0)
S
5

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.

Sphalerite answered 5/12, 2012 at 20:28 Comment(1)
Thanks Kasapo, I looked at the server logs and can see that the request being made is a POST request. However, I can't see any mention of the 414 error I'm getting which is odd. I'm looking at the IIS log for the reportServer instance.Inchoation
A
3

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>

.....

Ambrogio answered 25/12, 2012 at 19:56 Comment(0)
H
2

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.

Hallo answered 5/12, 2012 at 20:25 Comment(2)
Thanks for the idea David, I tried putting the parameters in the request body and it works correctly for a smaller selection of parameters but still fails with the same error when a large number of multi-select parameters are selected.Inchoation
Please find my amended code and edits in the original question above. cheers!Inchoation
T
1

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?

Tenderfoot answered 27/12, 2012 at 3:25 Comment(0)
S
1

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 '?'.

Silkworm answered 27/12, 2012 at 22:10 Comment(0)
C
1

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.

Chufa answered 27/12, 2012 at 22:22 Comment(0)
B
0

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.

Barclay answered 28/11, 2013 at 23:43 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.