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


283

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


4
Pour faciliter la tâche de Google, la traduction allemande du message d'erreur indique " Unbekanntes Anforderungsformat für eine URL, die unerwartet mit '/ _myMethodName' endet. ".
Uwe Keim

Et la traduction chinoise: " 無法 辨認 要求 格式 , 因為 URL 未 預期 地 以 / myMethodName 結束。 "
Ignace

Réponses:


515

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


3
Je PENSE que tout ce que vous devez faire est de basculer <system.web> vers <system.webserver>
roman le

je l'ai gardé tel quel et pour l'instant l'erreur semble avoir disparu. si je vois à nouveau l'erreur, je déplacerai les configurations Webservices dans la section Webserver.
Daniel Brink

1
Et qu'en est-il si cette erreur est levée sans aucune régularité, juste parfois? Ces appels dépendent-ils d'une certaine configuration client / navigateur!?
Vladislav

2
Sur un Win2012srv avec IIS8, c'était nécessaire. Sur un Win8 avec IIS8, ce n'était pas nécessaire. Pas d'autres divergences dans la configuration que je connaisse.
LosManos

1
@SaurabhRai moi aussi. Qu'est-ce que cela a fait? Les liens fournis dans la réponse sont rompus.
Rod

18

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

Cela a résolu mon problème. J'obtenais la même erreur que OP; sur ce qui avait été un ancien site de travail. Il s'avère que quelqu'un a activé .NET 3.5 via les fonctionnalités de Windows (pour des raisons indépendantes) qui ont cassé mon site. aspnet_regiis -icependant corrigé.
Nate

16

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

1
mon passage de valeur de paramètre a eu un problème en raison du type de données et des valeurs manquantes, qui se terminent par une erreur de 500. maintenant c'est résolu.
Pranesh Janarthanan

Ajouter content-type: application/jsonrésolu ce problème pour moi aussi.
Delphi.Boy

10

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.


Ajout de cette logique au web.config pour empêcher la définition de s'afficher lors de la navigation vers le service .asmx. Apparemment, cela a cassé ActiveReports. Heureux de savoir qu'il s'agit probablement d'un symptôme de test local et que cela fonctionnera sur le serveur. Merci.
Jacob Barnes

2

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.


1

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>

1

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

1

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


1

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>

0

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.


0

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


0

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

0

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>

-1

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">

-1

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";
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.