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


Esto no es una pregunta - publicarlo aquí para referencia:

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

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


249
2018-03-18 08:05


origen


Respuestas:


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


459
2018-03-18 08:05



A pesar del 90% de toda la información que encontré (al tratar de encontrar una solución a este error) diciéndome que agregue el 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 ejecuta en muchos servidores (más de 30) y nunca he tenido que agregar esta configuración para ninguno de ellos. O 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

16
2017-11-19 11:31



Asegúrese de estar utilizando el método correcto: Publicar / Obtener, 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); }
})

13
2018-01-26 18:28



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 ejecutar la función de forma manual.


7
2018-02-05 06:26



Para el registro, recibí este error cuando moví una aplicación antigua de un servidor a otro. Añadí el <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 solucionar 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>

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


2
2018-04-01 11:22



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>

1
2018-04-26 10:39



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

Lo arreglé estableciendo my 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"
            });

1
2017-10-26 18:08



En html, debe adjuntar la llamada en un formulario con un GET con algo así como

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

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

También hay SOAP y clases de proxy.


0
2018-06-04 14:18



En mi caso, tuve una sobrecarga de funciones que causaba 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


0
2018-04-13 05:25



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ías verlo agregando ?WSDL al final de la url, es decir http: //localhost/WebService1.asmx? WSDL


0
2017-12-18 22:05



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

Todavía no sabemos por qué el problema apareció de repente. El servicio web se estuvo ejecutando durante 5 años perfectamente sobre HTTP y HTTPS. Somos los únicos que consumimos el servicio web y siempre estamos usando POST.

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

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

Hay varias publicaciones (p. éste) discutiendo cómo manejar el método OPTIONS. Fuimos a gestionar la solicitud OPTIONS 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();
        }
    }

0
2018-04-12 23:38