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

Questa non è una domanda – pubblicandola qui per riferimento:

Quando si utilizza un servizio Web, ho ricevuto 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ò di cui hai bisogno è aggiungere quanto segue al tuo web.config

          

Maggiori informazioni da Microsoft

Nonostante il 90% di tutte le informazioni che ho trovato (cercando di trovare una soluzione a questo errore) mi dicesse di aggiungere HttpGet e HttpPost alla configurazione, che non ha funzionato per me … e comunque non aveva 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. O la versione dell’applicazione in esecuzione in .NET 2.0 o .NET 4.0.

La soluzione per me era di ri-registrare ASP.NET contro 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: Posta / Ricevi, giusto tipo di contenuto e parametri giusti (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 lo stesso problema può essere risolto) nel mio caso il problema era dovuto alla seguente riga:

      

Funziona bene sul server poiché le chiamate vengono fatte direttamente alla funzione webservice, tuttavia fallirà se si esegue il servizio direttamente da .Net nell’ambiente di debug e si desidera testare l’esecuzione manuale della funzione.

Per la cronaca stavo ricevendo questo errore quando ho spostato una vecchia app da un server all’altro. Ho aggiunto gli elementi al web.config, che ha cambiato 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 linee ScriptHandlerFactory a web.config:

        

Perché ha funzionato senza queste righe su un server web e non l’altro non lo so.

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

          

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

L’ho risolto impostando il mio ajax contentType su:

 "application/json; charset=utf-8" 

e usando:

 JSON.stringify() 

sull’object che stavo pubblicando.

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

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

 label 

È inoltre ansible utilizzare un POST con l’azione come posizione del servizio Web e immettere il parametro tramite un tag di input.

Esistono anche classi SOAP e proxy.

Nel mio caso ho avuto un sovraccarico di funzione che stava causando questa eccezione, una volta che ho cambiato il nome della mia seconda funzione è andato bene, suppongo che il web server non supporta il sovraccarico delle funzioni

Ho anche ricevuto questo errore con apache mod-mono. Sembra che la pagina di documentazione per il webservice non sia ancora implementata in linux. Ma il webservice funziona nonostante questo errore. Dovresti vederlo aggiungendo ?WSDL alla fine dell’URL, cioè http: //localhost/WebService1.asmx? WSDL

Nel nostro caso il problema è stato causato dal fatto che il servizio web è stato chiamato utilizzando il metodo di richiesta OPTIONS (anziché GET o POST).

Non sappiamo ancora perché il problema sia apparso all’improvviso. Il servizio web funzionava da 5 anni perfettamente bene sia su HTTP che su HTTPS. Siamo gli unici a consumare il servizio Web e utilizza sempre il POST.

Recentemente abbiamo deciso di rendere il sito che ospita solo il servizio Web SSL. Abbiamo aggiunto le regole di riscrittura a Web.config per convertire qualsiasi cosa HTTP in HTTPS, implementato e 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.

Ci sono diversi post (ad esempio questo ) che trattano come gestire il metodo OPTIONS. Siamo andati a gestire la richiesta OPTIONS direttamente nel Global.asax. Ciò ha fatto scomparire 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(); } } 

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

      

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

modificare

  

a

  

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