asp.net - Le format de la requête n'est pas reconnu pour l'URL se terminant de manière inattendue dans




jquery web-services (9)

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

Ce n'est pas une question - en l'affichant ici pour référence:

Lors de la consommation d'un WebService, j'ai l'erreur suivante:

Le format de la requête n'est pas reconnu pour l'URL se terminant de manière inattendue dans / myMethodName


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

Dans notre cas, le problème a été provoqué par 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 apparu soudainement. Le service Web fonctionne parfaitement depuis 5 ans sur HTTP et HTTPS. Nous sommes les seuls à consommer le service web et il utilise toujours le POST.

Récemment, nous avons décidé de rendre le site qui héberge le service Web SSL uniquement. Nous avons ajouté des règles de réécriture à Web.config pour convertir n'importe quel HTTP en HTTPS, déployé, et immédiatement commencé à obtenir, en plus des requêtes GET et POST, des requêtes OPTIONS. Les demandes 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'erreurs en raison de ce problème.

Il y a plusieurs articles (par exemple celui-ci ) sur comment gérer la méthode OPTIONS. Nous sommes allés pour gérer la requête OPTIONS directement dans 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();
        }
    }

En html vous devez joindre l'appel dans un formulaire 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 correspondant à l'emplacement du service Web et entrer le paramètre via une étiquette d'entrée.

Il y a aussi des classes SOAP et proxy.


J'ai 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


J'utilise la ligne de code suivante pour résoudre ce problème. Ecrivez le code suivant dans le fichier web.config

<configuration>
    <system.web.extensions>
       <scripting>
       <webServices>
       <jsonSerialization maxJsonLength="50000000"/>
      </webServices>
     </scripting>
   </system.web.extensions>
</configuration>

Malgré 90% de toutes les informations que j'ai trouvées (en essayant de trouver une solution à cette erreur) me disant d'ajouter le HttpGet et le 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 beaucoup de serveurs (30+) et je n'ai jamais eu à ajouter cette configuration pour aucun d'entre eux. Soit la version de l'application fonctionnant sous .NET 2.0 ou .NET 4.0.

La solution pour moi était de réinscrire 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

Pour l'enregistrement, 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 fichier web.config, 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 fonctionnait sans ces lignes sur un serveur web et pas l'autre je ne sais pas.


un 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 reçu l'exception.

Corrigez-le en assignant la clé AutoCompleteExtender.

ac.ContextKey = "myKey";






web-services