Il formato della richiesta non è riconosciuto per l'URL che termina inaspettatamente

Questa non è una domanda: pubblicala qui come riferimento:

Durante l'utilizzo di un servizio Web, ho riscontrato il seguente errore:

Il formato della richiesta non è riconosciuto per l'URL che termina inaspettatamente in / myMethodName

Ho trovato una soluzione su questo sito

Tutto ciò che serve è aggiungere quanto segue al tuo web.config

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

Ulteriori informazioni da Microsoft

Nonostante il 90% di tutte le informazioni che ho trovato (mentre cercavo di trovare una soluzione a questo errore) mi dicesse di aggiungere il HttpGete HttpPostalla configurazione, ciò non ha funzionato per me ... e comunque non ha avuto senso per me.

La mia applicazione è in esecuzione su molti server (oltre 30) e non ho mai dovuto aggiungere questa configurazione per nessuno di essi. La versione dell'applicazione in esecuzione in .NET 2.0 o .NET 4.0.

La soluzione per me era quella di registrare nuovamente ASP.NET su IIS.

Ho usato la seguente riga di comando per ottenere questo ...

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

Assicurati di utilizzare il metodo giusto: Pubblica / Ricevi, giusto tipo di contenuto e parametri corretti (dati).

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

Superba.

Caso 2 - dove può risolvere lo stesso problema) nel mio caso il problema era dovuto alla seguente riga:

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

Funziona bene nel server poiché le chiamate vengono effettuate direttamente alla funzione webservice - tuttavia non funzionerà se si esegue il servizio direttamente da .Net nell'ambiente di debug e si desidera testare l'esecuzione manuale della funzione.

Per la cronaca, ho riscontrato questo errore quando ho spostato una vecchia app da un server a un altro. Ho aggiunto gli <add name="HttpGet"/> <add name="HttpPost"/>elementi a web.config, che ha modificato l'errore 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)

Per correggere questo errore ho dovuto aggiungere le righe ScriptHandlerFactory a 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>

Perché non ha funzionato senza queste linee su un web server e non sull'altro non lo so.

Uso la seguente riga di codice per risolvere questo problema. Scrivi il seguente codice nel file web.config

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

Non ho avuto il problema durante lo sviluppo in localhost. Tuttavia, una volta pubblicato su un server Web, il servizio web stava restituendo un risultato vuoto (vuoto) e vedevo l'errore nei miei registri.

L'ho risolto impostando il mio contenuto AjaxType su:

"application/json; charset=utf-8"

e usando:

JSON.stringify()

sull'oggetto che stavo postando.

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

Ho anche riscontrato questo errore con apache mod-mono. Sembra che la pagina della documentazione per webservice non sia ancora implementata in Linux. Ma il servizio web funziona nonostante questo errore. Dovresti vederlo aggiungendo ?WSDLalla fine di url, ovvero http: //localhost/WebService1.asmx? WSDL

Nel mio caso l'errore si è verificato quando mi sono spostato dal mio PC locale Windows 10 a un server dedicato con Windows 2012. La soluzione era aggiungere al web.config le seguenti righe

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

In html devi racchiudere la chiamata in un modulo con un GET con qualcosa di simile

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

Puoi anche usare a POST con l'azione come posizione del servizio Web e immettere il parametro tramite un tag di input.

Esistono anche SOAPclassi proxy.

Nel mio caso ho avuto un sovraccarico di funzione che stava causando questa eccezione, una volta cambiato il nome della mia seconda funzione ha funzionato bene, suppongo che il server Web non supporti il ​​sovraccarico della funzione

Nel nostro caso il problema è stato causato dalla chiamata del servizio Web tramite il metodo di richiesta OPTIONS (anziché GET o POST).

Non sappiamo ancora perché il problema sia apparso all'improvviso. Il servizio Web è in esecuzione da 5 anni perfettamente su HTTP e HTTPS. Siamo gli unici che consumano il servizio web e utilizza sempre POST.

Di recente abbiamo deciso di rendere SSL solo il sito che ospita il servizio web. Abbiamo aggiunto regole di riscrittura a Web.config per convertire qualsiasi cosa HTTP in HTTPS, distribuito e abbiamo immediatamente iniziato a ricevere, oltre alle normali richieste GET e POST, le richieste OPTIONS. Le richieste OPTIONS hanno causato l'errore discusso in questo post.

Il resto dell'applicazione ha funzionato perfettamente. Ma abbiamo continuato a ricevere centinaia di segnalazioni di errori a causa di questo problema.

Esistono diversi post (ad esempio, questo ) che discutono su come gestire il metodo OPTIONS. Siamo andati a gestire la richiesta OPTIONS direttamente in Global.asax. Questo ha fatto sparire il problema.

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

Stavo ricevendo questo errore fino a quando non ho aggiunto (come mostrato nel codice seguente) $ .holdReady (true) all'inizio della mia chiamata al servizio web e $ .holdReady (false) al termine. Questa è la cosa di jQuery per sospendere lo stato pronto della pagina in modo che qualsiasi script all'interno di document.ready funzioni sia in attesa di questo (tra le altre cose possibili ma a me sconosciute).

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

Assicurati di disabilitare gli errori personalizzati. Questo può mascherare il problema originale nel tuo codice:

modificare

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

per

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

un WebMethod che richiede un ContextKey,

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

quando questa chiave non è impostata, ha ottenuto l'eccezione.

Risolvendolo assegnando la chiave AutoCompleteExtender.

ac.ContextKey = "myKey";