Le format de la demande n'est pas reconnu pour l'URL se terminant inopinément par

Ce n'est pas une question - affichez-le 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 l'URL se terminant de façon inattendue par / myMethodName

Trouvé une solution sur ce site

Tout ce dont vous avez besoin est d'ajouter ce qui suit à votre web.config

<configuration>
  <system.web>
    <webServices>
      <protocols>
        <add name="HttpGet"/>
        <add name="HttpPost"/>
      </protocols>
    </webServices>
  </system.web>
</configuration>

Plus d'informations de Microsoft

Malgré 90% de toutes les informations que j'ai trouvées (en essayant de trouver une solution à cette erreur) me disant d'ajouter le HttpGetet HttpPostà la configuration, cela n'a pas fonctionné pour moi ... et n'a pas de sens pour moi de toute façon.

Mon application fonctionne sur de nombreux serveurs (30+) et je n'ai jamais eu à ajouter cette configuration pour aucun d'entre 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, bon type de contenu et 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>

Il fonctionne bien sur le serveur car les appels sont directement passés à la fonction de service Web - mais échouera si vous exécutez le service directement à partir de .Net dans l'environnement de débogage et que vous souhaitez tester l'exécution manuelle de la fonction.

Pour mémoire, j'obtenais cette erreur lorsque j'ai déplacé une ancienne application d'un serveur à un autre. J'ai ajouté les <add name="HttpGet"/> <add name="HttpPost"/>éléments au web.config, ce qui a changé 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 sur l'autre, je ne sais pas.

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>

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 définissant 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"
            });

J'ai également eu cette erreur avec apache mod-mono. Il semble que la page de documentation du webservice ne soit pas encore implémentée sous Linux. Mais le webservice fonctionne malgré cette erreur. Vous devriez le voir en ajoutant ?WSDLà la fin de l'URL, à savoir http: //localhost/WebService1.asmx? WSDL

Dans mon cas, l'erreur s'est produite lorsque je passe de mon PC local Windows 10 à un serveur dédié avec Windows 2012. La solution était d'ajouter au web.config les lignes suivantes

<webServices>
        <protocols>
               <add name="Documentation"/>
        </protocols>
</webServices>

En html, vous devez mettre l'appel sous une forme avec un GET avec quelque chose comme

<a href="/service/servicename.asmx/FunctionName/parameter=SomeValue">label</a>

Vous pouvez également utiliser un POST avec l'action étant l'emplacement du service Web et entrer le paramètre via une balise d'entrée.

Il existe également SOAPdes classes proxy.

Dans mon cas, j'ai eu une surcharge de fonction à l'origine de cette exception, une fois que j'ai changé le nom de ma deuxième fonction, cela s'est bien passé, je suppose que le serveur Web ne prend pas en charge la surcharge de fonctions

Dans notre cas, le problème est dû au fait que le service Web a été appelé à l'aide de la méthode de demande OPTIONS (au lieu de GET ou POST).

Nous ne savons toujours pas pourquoi le problème est soudainement apparu. Le service Web fonctionnait parfaitement depuis 5 ans sur HTTP et HTTPS. Nous sommes les seuls à consommer le service Web et il utilise toujours POST.

Récemment, nous avons décidé de faire du site qui héberge uniquement le service Web SSL. Nous avons ajouté des règles de réécriture au Web.config pour convertir quoi que ce soit HTTP en HTTPS, déployé et immédiatement commencé à obtenir, en plus des requêtes GET et POST régulières, des requêtes OPTIONS. Les requêtes OPTIONS ont provoqué l'erreur discutée sur ce post.

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.

Il existe plusieurs articles (par exemple celui-ci ) expliquant comment gérer la méthode OPTIONS. Nous sommes allés traiter la demande OPTIONS directement dans le 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();
        }
    }

J'obtenais 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 sa fin. C'est une chose jQuery pour suspendre l'état prêt de la page afin que tout script dans la fonction document.ready attende cela (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>

Assurez-vous de désactiver les erreurs personnalisées. Cela peut masquer le problème d'origine dans votre code:

changement

<customErrors defaultRedirect="~/Error" mode="On">

à

<customErrors defaultRedirect="~/Error" mode="Off">

une WebMethod qui nécessite une ContextKey,

[WebMethod]
public string[] GetValues(string prefixText, int count, string contextKey)

lorsque cette clé n'est pas définie, a obtenu l'exception.

Le corriger en attribuant la clé d'AutoCompleteExtender.

ac.ContextKey = "myKey";