El formato de solicitud no se reconoce para la URL que termina inesperadamente en

Esta no es una pregunta, publíquela aquí como referencia:

Al consumir un servicio web, recibí el siguiente error:

El formato de solicitud no se reconoce para la URL que termina inesperadamente en / myMethodName

Encontré una solución en este sitio web

Todo lo que necesita es agregar lo siguiente a su web.config

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

Más información de Microsoft

A pesar del 90% de toda la información que he encontrado (al tratar de encontrar una solución a este error) me decía que añadir el HttpGety HttpPostcon la configuración, que no funcionó para mí ... y no tenía sentido para mí de todos modos.

Mi aplicación se ejecuta en muchos servidores (más de 30) y nunca he tenido que agregar esta configuración para ninguno de ellos. La versión de la aplicación que se ejecuta en .NET 2.0 o .NET 4.0.

La solución para mí fue volver a registrar ASP.NET contra IIS.

Usé la siguiente línea de comando para lograr esto ...

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

Asegúrese de estar utilizando el método correcto: Publicar / Obtener, tipo de contenido correcto y parámetros (datos) correctos.

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

Magnífico.

Caso 2 - donde puede surgir el mismo problema) en mi caso el problema se debió a la siguiente línea:

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

Funciona bien en el servidor ya que las llamadas se realizan directamente a la función de servicio web; sin embargo, fallará si ejecuta el servicio directamente desde .Net en el entorno de depuración y desea probar la ejecución de la función manualmente.

Para el registro, recibí este error cuando moví una aplicación anterior de un servidor a otro. Agregué los <add name="HttpGet"/> <add name="HttpPost"/>elementos a web.config, que cambió el error a:

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)

Para corregir este error, tuve que agregar las líneas 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>

No sé por qué funcionó sin estas líneas en un servidor web y no en el otro.

Yo uso la siguiente línea de código para solucionar este problema. Escriba el siguiente código en el archivo web.config

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

No tuve el problema al desarrollar en localhost. Sin embargo, una vez que publiqué en un servidor web, el servicio web estaba devolviendo un resultado vacío (en blanco) y estaba viendo el error en mis registros.

Lo arreglé configurando mi tipo de contenido ajax en:

"application/json; charset=utf-8"

y usando:

JSON.stringify()

en el objeto que estaba publicando.

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

También recibí este error con apache mod-mono. Parece que la página de documentación para el servicio web aún no está implementada en Linux. Pero el servicio web funciona a pesar de este error. Debería verlo agregando ?WSDLal final de la url, es decir, http: //localhost/WebService1.asmx? WSDL

En mi caso, el error ocurrió cuando me mudé de mi PC local Windows 10 a un servidor dedicado con Windows 2012. La solución fue agregar a la web.config las siguientes líneas

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

En html tienes que encerrar la llamada en una forma con un GET con algo como

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

También puedes usar un POST con la acción que es la ubicación del servicio web e ingresar el parámetro a través de una etiqueta de entrada.

También hay SOAPclases y proxy.

En mi caso, tuve una sobrecarga de función que estaba causando esta excepción, una vez que cambié el nombre de mi segunda función funcionó bien, supongo que el servidor web no admite la sobrecarga de funciones

En nuestro caso, el problema fue causado por la llamada al servicio web utilizando el método de solicitud OPTIONS (en lugar de GET o POST).

Todavía no sabemos por qué apareció el problema de repente. El servicio web había estado funcionando durante 5 años perfectamente a través de HTTP y HTTPS. Somos los únicos que consumimos el servicio web y siempre está utilizando POST.

Recientemente decidimos hacer que el sitio que aloja el servicio web sea solo SSL. Agregamos reglas de reescritura a la configuración Web.config para convertir cualquier cosa HTTP en HTTPS, implementamos e inmediatamente comenzamos a obtener, además de las solicitudes GET y POST normales, solicitudes OPTIONS. Las solicitudes de OPTIONS causaron el error discutido en esta publicación.

El resto de la aplicación funcionó perfectamente bien. Pero seguimos recibiendo cientos de informes de errores debido a este problema.

Hay varias publicaciones (por ejemplo, esta ) que discuten cómo manejar el método OPTIONS. Fuimos a manejar la solicitud de OPCIONES directamente en Global.asax. Esto hizo que el problema desapareciera.

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

Recibí este error hasta que agregué (como se muestra en el código a continuación) $ .holdReady (verdadero) al comienzo de mi llamada al servicio web y $ .holdReady (falso) después de que finaliza. Esto es una cuestión de jQuery para suspender el estado listo de la página para que cualquier script dentro de la función document.ready esté esperando esto (entre otras cosas posibles pero desconocidas para mí).

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

Asegúrese de deshabilitar los errores personalizados. Esto puede enmascarar el problema original en su código:

cambio

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

a

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

un WebMethod que requiere una ContextKey,

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

cuando esta clave no está configurada, se obtiene la excepción.

Solucionándolo asignando la clave de AutoCompleteExtender.

ac.ContextKey = "myKey";