Das Anforderungsformat wird für URLs, die unerwartet auf enden, nicht erkannt

Dies ist keine Frage - hier als Referenz posten:

Beim Konsumieren eines WebService wurde folgende Fehlermeldung angezeigt:

Das Anforderungsformat wird für URLs, die unerwartet mit / myMethodName enden, nicht erkannt

Auf dieser Website eine Lösung gefunden

Sie müssen lediglich Folgendes zu Ihrer web.config hinzufügen

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

Weitere Infos von Microsoft

Trotz 90% aller Informationen, die ich gefunden habe (während ich versuchte, eine Lösung für diesen Fehler zu finden), die mich aufforderten, das HttpGetund HttpPostzur Konfiguration hinzuzufügen , funktionierte das für mich nicht ... und ergab für mich sowieso keinen Sinn.

Meine Anwendung läuft auf vielen Servern (30+) und ich musste diese Konfiguration für keinen von ihnen hinzufügen. Entweder die Version der Anwendung, die unter .NET 2.0 oder .NET 4.0 ausgeführt wird.

Die Lösung für mich bestand darin, ASP.NET erneut für IIS zu registrieren.

Ich habe die folgende Befehlszeile verwendet, um dies zu erreichen ...

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_regiis.exe -i

Stellen Sie sicher, dass Sie die richtige Methode verwenden: Post / Get, den richtigen Inhaltstyp und die richtigen Parameter (Daten).

$.ajax({
    type: "POST",
    url: "/ajax.asmx/GetNews",
    data: "{Lang:'tr'}",
    contentType: "application/json; charset=utf-8",
    dataType: "json",
    success: function (msg) { generateNews(msg); }
})

Hervorragend.

Fall 2 - wo das gleiche Problem auftreten kann) In meinem Fall war das Problem auf die folgende Zeile zurückzuführen:

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

Es funktioniert gut auf dem Server, da die Webservice-Funktion direkt aufgerufen wird. Dies schlägt jedoch fehl, wenn Sie den Dienst direkt über .Net in der Debug-Umgebung ausführen und die manuelle Ausführung der Funktion testen möchten.

Ich habe diesen Fehler erhalten, als ich eine alte App von einem Server auf einen anderen verschoben habe. Ich habe die <add name="HttpGet"/> <add name="HttpPost"/>Elemente zur web.config hinzugefügt, wodurch der Fehler geändert wurde in:

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)

Um diesen Fehler zu beheben, musste ich die ScriptHandlerFactory-Zeilen zu web.config hinzufügen:

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

Warum es ohne diese Zeilen auf einem Webserver und nicht auf dem anderen funktioniert hat, weiß ich nicht.

Ich verwende die folgende Codezeile, um dieses Problem zu beheben. Schreiben Sie den folgenden Code in die Datei web.config

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

Ich hatte das Problem nicht, als ich in localhost entwickelte. Sobald ich jedoch auf einem Webserver veröffentlicht habe, gab der Webservice ein leeres (leeres) Ergebnis zurück und ich sah den Fehler in meinen Protokollen.

Ich habe das Problem behoben, indem ich meinen Ajax-Inhaltstyp auf Folgendes gesetzt habe:

"application/json; charset=utf-8"

und mit:

JSON.stringify()

auf dem Objekt, das ich gepostet habe.

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

Ich habe diesen Fehler auch mit Apache Mod-Mono bekommen. Es sieht so aus, als ob die Dokumentationsseite für den Webservice unter Linux noch nicht implementiert ist. Trotz dieses Fehlers funktioniert der Webservice. Sie sollten es sehen, indem Sie ?WSDLam Ende der URL hinzufügen , dh http: //localhost/WebService1.asmx? WSDL

In meinem Fall trat der Fehler auf, als ich von meinem lokalen PC Windows 10 auf einen dedizierten Server mit Windows 2012 wechselte. Die Lösung für bestand darin, der web.config die folgenden Zeilen hinzuzufügen

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

In HTML müssen Sie den Aufruf in einer Form mit einem GET mit so etwas wie einschließen

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

Sie können auch a verwenden, POSTwobei die Aktion der Speicherort des Webdienstes ist, und den Parameter über ein Eingabe-Tag eingeben.

Es gibt auch SOAPund Proxy-Klassen.

In meinem Fall hatte ich eine Funktionsüberladung, die diese Ausnahme verursachte. Nachdem ich den Namen meiner zweiten Funktion geändert hatte, lief sie in Ordnung. Vermutlich unterstützt der Webserver keine Funktionsüberladung

In unserem Fall wurde das Problem dadurch verursacht, dass der Webdienst mit der Anforderungsmethode OPTIONS (anstelle von GET oder POST) aufgerufen wurde.

Wir wissen immer noch nicht, warum das Problem plötzlich auftrat. Der Webdienst lief seit 5 Jahren perfekt über HTTP und HTTPS. Wir sind die einzigen, die den Webdienst nutzen, und er verwendet immer POST.

Kürzlich haben wir beschlossen, die Site, auf der der Webdienst gehostet wird, nur SSL zu erstellen. Wir haben der Web.config Umschreiberegeln hinzugefügt, um alles HTTP in HTTPS zu konvertieren, bereitgestellt und sofort zusätzlich zu den regulären GET- und POST-Anforderungen OPTIONS-Anforderungen abgerufen. Die OPTIONS-Anforderungen haben den in diesem Beitrag beschriebenen Fehler verursacht.

Der Rest der Anwendung hat einwandfrei funktioniert. Aufgrund dieses Problems erhielten wir jedoch immer wieder Hunderte von Fehlerberichten.

Es gibt mehrere Beiträge (z. B. diesen ), in denen der Umgang mit der OPTIONS-Methode erläutert wird. Wir haben die OPTIONS-Anfrage direkt in der Global.asax bearbeitet. Dies ließ das Problem verschwinden.

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

Ich habe diesen Fehler erhalten, bis ich zu Beginn meines Webdienstaufrufs $ .holdReady (true) und nach dessen Ende $ .holdReady (false) hinzugefügt habe (wie im folgenden Code gezeigt ) . Dies ist eine jQuery-Sache, um den Bereitschaftsstatus der Seite anzuhalten, damit jedes Skript in der Funktion document.ready darauf wartet (unter anderem mögliche, aber mir unbekannte Dinge).

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

Stellen Sie sicher, dass Sie benutzerdefinierte Fehler deaktivieren. Dies kann das ursprüngliche Problem in Ihrem Code maskieren:

Veränderung

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

zu

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

eine WebMethod, die einen ContextKey erfordert,

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

Wenn dieser Schlüssel nicht gesetzt ist, wurde die Ausnahme angezeigt.

Behebung durch Zuweisung des AutoCompleteExtender-Schlüssels.

ac.ContextKey = "myKey";