Nous avons une application ASP.NET qui demande un rapport SSRS 2005 au format HTML après avoir transmis les paramètres du rapport comme WebRequest. L'application échoue uniquement lorsqu'un rapport avec un grand nombre de paramètres multi-sélection est demandé, en lançant une erreur "414: Demander Uri Trop Trop" "à la Le Le code utilisé pour faire la demande est la suivante: p> Comme le rapport échoue sur le côté serveur, j'ai examiné les propriétés IIS et NOCKERVER pour augmenter le maxurl, la maxrequestlength, la MaxQueryString, etc. . En termes d'octets (conformément à Cet article ) mais le L'application jette toujours une erreur. J'ai essayé ceci dans les fichiers web.config et directement sur le gestionnaire IIS. P> La version du serveur déclarant en 2005 et elle est hébergée sur Windows Server 2008, qui exécute IIS 7. P> sur David Lively's Advise J'ai essayé de demander l'URI en mettant les paramètres dans le corps. Cela fonctionne pour les plus petites demandes, mais échoue toujours pour de grands paramètres multi-sélection. Le code modifié est le suivant: P> WebRequest.getresponse () code> Ligne. 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();
7 Réponses :
Puisque vous utilisez déjà le message pour aller chercher le rapport, je vous suggère de placer les paramètres que vous passez actuellement dans la chaîne de requête dans le corps de la demande, à la place. Les paramètres de QueryString fonctionnent bien pour un nombre limité de paramètres, mais ne sont pas appropriés pour un grand nombre d'articles.
Merci pour l'idée David, j'ai essayé de mettre les paramètres dans le corps de la demande et cela fonctionne correctement pour une sélection plus petite de paramètres mais échoue toujours avec la même erreur lorsqu'un grand nombre de paramètres multi-sélection sont sélectionnés.
Veuillez trouver mon code et mes modifications modifiés dans la question initiale ci-dessus. Tchin Tchin!
est-il possible pour vous d'utiliser des variables post-cibles au lieu d'obtenir? De cette façon, il n'y a aucune limite dont je suis au courant, car toutes vos données seront envoyées dans des paquets au lieu des en-têtes HTTP.
En réalité, il semble que vous utilisiez peut-être l'article de ce qui est dans votre code. Pouvez-vous regarder dans les journaux du serveur pour vérifier l'URI qui cause cela échoue? Si vous envoyez des données publiques, l'URI de la demande ne devrait pas être une question à moins que ce soit sans rapport avec les données que vous postez.
Merci Kasapo, j'ai examiné les journaux du serveur et je peux voir que la demande étant faite est une demande postale. Cependant, je ne peux voir aucune mention de l'erreur 414 que je reçois ce qui est étrange. Je regarde le journal IIS pour l'instance Signalererver.
Vérifiez les paramètres de liaison de votre service. Je suppose que le service permettra la chaîne jusqu'à 8192 longueur. Définissez Te ReaderQuotas à une plus grande taille. Pourrait aider.
... .....
Pouvez-vous montrer la valeur de webrequestturl?
Ça va être "trop grand".
Si vous passez des paramètres à cette URL, peuvent-ils être dans le corps de poste à la place?
webrquesturl.indexof ("&") ... Est-ce que cela signifie être "?" à la place de "&"? Je suppose que vous construisez une URL valide pour interroger la page, puis inversez l'ingénieur pour être une demande de poste en recherchant l'URL avant le premier »& '...
Cependant, il est possible que GetResponse soit à l'URL de l'URL, car elle voit le point d'interrogation dans l'URL et suppose que les paramètres doivent aller dans l'URL? Essayez de faire une correspondance d'URL plus précise avec des paramètres zéro et non '?'.
Je l'ai eu au travail sur mon site IIS7. Je l'ai corrigé avec un piratage de registre, je peux le chercher mais ne fonctionnera pas avant le 3/1. Pendant ce temps, essayez si vous obtenez l'erreur lorsque vous utilisez l'adresse IP à la place de l'URL normale, lorsque vous ne le faites pas, les chances sont élevées, c'est le même problème.
eu un problème similaire, sauf que le message travaillait, mais le deuxième poste avec exactement les mêmes paramètres renvoyés 414.
réglage req.keekeealive = false; résolu le problème, Dieu sait pourquoi.