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

A pesar de que el 90% de toda la información que encontré (mientras intentaba encontrar una solución a este error) me decía que agregara HttpGet y HttpPost a la configuración, eso no funcionó para mí... y no tenía sentido para mí de todos modos.

Mi aplicación se está ejecutando 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 registrarse ASP.NET votos en contra IIS.

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

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

Asegúrate de usar el método correcto: Post/Get, tipo de contenido correcto y parámetros correctos (datos).

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

Excelente.

Caso 2-donde el mismo problema puede arrise) 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 webservice; 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, estaba recibiendo este error cuando moví una aplicación antigua de un servidor a otro. He añadido los elementos <add name="HttpGet"/> <add name="HttpPost"/> a la 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 de 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>

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

Utilizo la siguiente línea de código para solucionar este problema. Escriba el siguiente código en la web.archivo de configuración

<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é estableciendo mi ajax ContentType 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"
            });

En html tienes que incluir la llamada en un formulario a con un GET con algo como

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

También puede usar un POST con la acción siendo la ubicación del servicio web e introducir el parámetro a través de una etiqueta de entrada.

También hay SOAP y clases 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 se ejecutó bien, supongo que el servidor web no soporta la sobrecarga de funciones

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

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

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

Recientemente decidimos hacer que el sitio que aloja el servicio web SSL solamente. Agregamos reglas de reescritura a la Web.config to convierta cualquier cosa HTTP en HTTPS, implementada e inmediatamente comenzó a recibir, además de las solicitudes GET y POST regulares, solicitudes DE OPCIONES. Las solicitudes de OPCIONES 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 varios posts (por ejemplo, este) discutiendo cómo manejar el método OPTIONS. Fuimos para manejar la solicitud de OPCIONES directamente en el Global.asax. Esto hizo desaparecer el 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();
        }
    }

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

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

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

Cambiar

<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á establecida, obtiene la excepción.

Fijándolo asignando la llave de AutoCompleteExtender.

ac.ContextKey = "myKey";