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

283

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

romano m
fuente
44
Para que sea más fácil para Google, la traducción al alemán del mensaje de error dice " Unbekanntes Anforderungsformat für eine URL, die unerwartet mit '/ _myMethodName' endet ".
Uwe Keim
Y la traducción al chino: " 無法 辨認 要求 格式 , 因為 URL 未 預期 地 以 / myMethodName 結束。 "
Ignacio

Respuestas:

515

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

romano m
fuente
3
Creo que todo lo que necesita hacer es cambiar <system.web> a <system.webserver>
roman m
Lo guardé como está y por ahora el error parece haber desaparecido. Si vuelvo a ver el error, moveré las configuraciones de los servicios web a la sección del servidor web.
Daniel Brink
1
¿Y qué pasa si este error se produce sin regularidad, solo algunas veces? ¿Estas llamadas dependen de alguna configuración de cliente / navegador?
Vladislav
2
En un Win2012srv con IIS8 era necesario. En un Win8 con IIS8 no era necesario. No conozco otras discrepancias en la configuración.
LosManos
1
@SaurabhRai yo también. ¿Qué hizo esto? Los enlaces proporcionados en la respuesta están rotos.
Rod
18

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
Freefaller
fuente
Esto solucionó mi problema. Estaba recibiendo el mismo error que OP; en lo que antes había sido un sitio de trabajo. Resulta que alguien habilitó .NET 3.5 a través de características de Windows (por razones no relacionadas) que rompieron mi sitio. aspnet_regiis -iaunque lo arregló.
Nate
16

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); }
})
HasanG
fuente
1
mi paso del valor del parámetro tuvo un problema debido al tipo de datos y los valores faltantes, que terminan en 500 error. ahora está resuelto.
Pranesh Janarthanan
Add también content-type: application/jsonresolvió este problema para mí.
Delphi.Boy
10

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.

Kalpesh Popat
fuente
Se agregó esa lógica a web.config para evitar que se muestre la definición al navegar al servicio .asmx. Aparentemente eso rompió ActiveReports. Me alegra saber que es probable que sea un síntoma de pruebas locales y funcionará en el servidor. Gracias.
Jacob Barnes
2

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.

Sprintstar
fuente
1

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>
pankaj prajapati
fuente
1

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"
            });
Jason Williams
fuente
1

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

l0pan
fuente
1

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>
Ruby Kousinovali
fuente
0

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.

Dave
fuente
0

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

Amir Shrestha
fuente
0

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

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>
bestinamir
fuente
-1

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">
Milan de Jong
fuente
-1

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