Le format de la demande n'est pas reconnu pour les URL se terminant de manière inattendue
Ce n'est pas une question - le poster ici pour référence:
Lors de la consommation d'un WebService, j'ai eu l'erreur suivante:
Le format de la demande n'est pas reconnu pour les URL se terminant de manière inattendue par / myMethodName
Malgré 90% de toutes les informations que j’ai trouvées (en essayant de trouver une solution à cette erreur) me disant d’ajouter les variables HttpGet et HttpPost à la configuration, cela ne fonctionnait pas pour moi ... et ça n'avait pas de sens pour moi de toute façon.
Mon application fonctionne sur de nombreux serveurs (plus de 30) et je n’ai jamais eu à ajouter cette configuration pour aucun d’eux. Soit la version de l'application exécutée sous .NET 2.0 ou .NET 4.0.
La solution pour moi était de ré-enregistrer ASP.NET contre IIS.
J'ai utilisé la ligne de commande suivante pour y parvenir ...
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_regiis.exe -i
Assurez-vous que vous utilisez la bonne méthode: Post/Get, le bon type de contenu et les bons paramètres (données).
$.ajax({
type: "POST",
url: "/ajax.asmx/GetNews",
data: "{Lang:'tr'}",
contentType: "application/json; charset=utf-8",
dataType: "json",
success: function (msg) { generateNews(msg); }
})
Superbe.
Cas 2 - où le même problème peut survenir) Dans mon cas, le problème était dû à la ligne suivante:
<webServices>
<protocols>
<remove name="Documentation"/>
</protocols>
</webServices>
Cela fonctionne bien sur le serveur car les appels sont faits directement vers la fonction webservice. Toutefois, cela échouera si vous exécutez le service directement à partir de .Net dans l'environnement de débogage et souhaitez tester l'exécution de la fonction manuellement.
Pour mémoire, je recevais cette erreur lorsque j'ai déplacé une ancienne application d'un serveur à un autre. J'ai ajouté les éléments <add name="HttpGet"/> <add name="HttpPost"/> au composant web.config, qui a modifié l'erreur en:
System.IndexOutOfRangeException: Index was outside the bounds of the array.
at BitMeter2.DataBuffer.incrementCurrent(Int64 val)
at BitMeter2.DataBuffer.WindOn(Int64 count, Int64 amount)
at BitMeter2.DataHistory.windOnBuffer(DataBuffer buffer, Int64 totalAmount, Int32 increments)
at BitMeter2.DataHistory.NewData(Int64 downloadValue, Int64 uploadValue)
at BitMeter2.frmMain.tickProcessing(Boolean fromTimerEvent)
Afin de corriger cette erreur, j'ai dû ajouter les lignes ScriptHandlerFactory à web.config:
<system.webServer>
<handlers>
<remove name="ScriptHandlerFactory" />
<add name="ScriptHandlerFactory" verb="*" path="*.asmx" preCondition="integratedMode" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
</handlers>
</system.webServer>
Pourquoi cela a fonctionné sans ces lignes sur un serveur Web et pas l'autre, je ne sais pas.
Dans mon cas, l'erreur est survenue lorsque je suis passé de mon PC local, Windows 10, à un serveur dédié avec Windows 2012. La solution pour a consisté à ajouter à web.config les lignes suivantes.
<webServices>
<protocols>
<add name="Documentation"/>
</protocols>
</webServices>
J'utilise la ligne de code suivante pour résoudre ce problème. Écrivez le code suivant dans le fichier web.config
<configuration>
<system.web.extensions>
<scripting>
<webServices>
<jsonSerialization maxJsonLength="50000000"/>
</webServices>
</scripting>
</system.web.extensions>
</configuration>
En html, vous devez inclure l'appel dans un formulaire avec un élément GET avec quelque chose comme
<a href="/service/servicename.asmx/FunctionName/parameter=SomeValue">label</a>
Vous pouvez également utiliser un POST, l'action étant l'emplacement du service Web et saisir le paramètre via une balise input.
Il y a aussi SOAP et des classes proxy.
Dans mon cas, j'avais une surcharge de fonction qui causait cette exception, une fois que j'ai changé le nom de ma deuxième fonction, ça fonctionnait bien, je suppose que le serveur Web ne supporte pas la surcharge de fonction
J'ai aussi eu cette erreur avec Apache mod-mono. Il semble que la page de documentation de webservice n’est pas encore implémentée sous Linux. Mais le service Web fonctionne malgré cette erreur. Vous devriez le voir en ajoutant ?WSDL à la fin de l'URL, c'est-à-dire http: //localhost/WebService1.asmx? WSDL
Dans notre cas, le problème provenait de l'appel du service Web à l'aide de la méthode de requête OPTIONS (au lieu de GET ou POST).
Nous ne savons toujours pas pourquoi le problème est soudainement apparu. Le service Web fonctionnait depuis 5 ans parfaitement sur HTTP et HTTPS. Nous sommes les seuls à utiliser le service Web et celui-ci utilise toujours POST.
Récemment, nous avons décidé de rendre le site hébergeant uniquement le service Web SSL. Nous avons ajouté des règles de réécriture à Web.config pour convertir tout élément HTTP en HTTPS, déployé et immédiatement commencé à recevoir, en plus des demandes GET et POST normales, des demandes OPTIONS. Les requêtes OPTIONS ont provoqué l'erreur décrite dans ce message.
Le reste de l'application a parfaitement fonctionné. Mais nous avons continué à recevoir des centaines de rapports d'erreur en raison de ce problème.
Plusieurs messages (par exemple, celui-ci ) expliquent comment gérer la méthode OPTIONS. Nous sommes allés traiter la demande OPTIONS directement dans le fichier Global.asax. Cela a fait disparaître le problème.
protected void Application_BeginRequest(object sender, EventArgs e)
{
var req = HttpContext.Current.Request;
var resp = HttpContext.Current.Response;
if (req.HttpMethod == "OPTIONS")
{
//These headers are handling the "pre-flight" OPTIONS call sent by the browser
resp.AddHeader("Access-Control-Allow-Methods", "GET, POST");
resp.AddHeader("Access-Control-Allow-Headers", "Origin, Content-Type, Accept, SOAPAction");
resp.AddHeader("Access-Control-Max-Age", "1728000");
resp.End();
}
}
Je recevais cette erreur jusqu'à ce que j'ajoute (comme indiqué dans le code ci-dessous) $. HoldReady (true) au début de mon appel de service Web et $. HoldReady (false) = après cela se termine. C'est une chose jQuery de suspendre l'état prêt de la page afin que tout script de la fonction document.ready l'attende (entre autres choses possibles mais inconnues de moi).
<span class="AjaxPlaceHolder"></span>
<script type="text/javascript">
$.holdReady(true);
function GetHTML(source, section){
var divToBeWorkedOn = ".AjaxPlaceHolder";
var webMethod = "../MyService.asmx/MyMethod";
var parameters = "{'source':'" + source + "','section':'" + section + "'}";
$.ajax({
type: "POST",
url: webMethod,
data: parameters,
contentType: "application/json; charset=utf-8",
dataType: "json",
async: true,
xhrFields: {
withCredentials: false
},
crossDomain: true,
success: function(data) {
$.holdReady(false);
var myData = data.d;
if (myData != null) {
$(divToBeWorkedOn).prepend(myData.html);
}
},
error: function(e){
$.holdReady(false);
$(divToBeWorkedOn).html("Unavailable");
}
});
}
GetHTML("external", "Staff Directory");
</script>
Je n'ai pas eu le problème lors du développement dans localhost. Cependant, une fois que j'ai publié sur un serveur Web, le service Web renvoyait un résultat vide (vide) et je voyais l'erreur dans mes journaux.
Je l'ai corrigé en réglant mon ajax contentType sur:
"application/json; charset=utf-8"
et en utilisant:
JSON.stringify()
sur l'objet que je publiais.
var postData = {data: myData};
$.ajax({
type: "POST",
url: "../MyService.asmx/MyMethod",
data: JSON.stringify(postData),
contentType: "application/json; charset=utf-8",
success: function (data) {
console.log(data);
},
dataType: "json"
});