asp.net - tesis - El formato de solicitud no se reconoce para la URL que termina inesperadamente en
tesis sobre youtube pdf (14)
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
A pesar del 90% de toda la información que encontré (mientras trataba de encontrar una solución a este error) me decía que agregue HttpGet y HttpPost a la configuración, eso no me funcionó ... y no tenía sentido para mí de todos modos .
Mi aplicación se ejecuta en muchos servidores (30+) y nunca tuve que agregar esta configuración para ninguno de ellos. Ya sea 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.
Utilicé la siguiente línea de comando para lograr esto ...
C:/Windows/Microsoft.NET/Framework64/v4.0.30319/aspnet_regiis.exe -i
Asegúrate 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">
Asegúrese de que está utilizando el método correcto: Post / Get, 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); }
})
En html tiene que encerrar la llamada en un formulario con un GET con algo como
"application/json; charset=utf-8"
También puede usar un POST la acción es la ubicación del servicio web e ingresar el parámetro a través de una etiqueta de entrada.
También hay clases de SOAP y proxy.
En mi caso, el error ocurrió cuando me mudo de mi PC local Windows 10 a un servidor dedicado con Windows 2012. La solución fue agregar a web.config las siguientes líneas
<webServices>
<protocols>
<add name="Documentation"/>
</protocols>
</webServices>
En mi caso, tuve una sobrecarga de la 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 se debió a que se llamó al servicio web utilizando el método de solicitud de OPCIONES (en lugar de GET o POST).
Todavía no sabemos por qué el problema apareció de repente. El servicio web llevaba funcionando 5 años perfectamente bien tanto en HTTP como en 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 solo sea SSL. Agregamos reglas de reescritura al Web.config para convertir cualquier HTTP a HTTPS, implementamos e inmediatamente comenzamos a obtener, además de las solicitudes GET y POST regulares, las 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 varias publicaciones (por ejemplo, esta ) que discuten cómo manejar el método de OPCIONES. 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();
}
}
Encontré una solución en este sitio web
Todo lo que necesitas es agregar lo siguiente a tu web.config
<configuration>
<system.web>
<webServices>
<protocols>
<add name="HttpGet"/>
<add name="HttpPost"/>
</protocols>
</webServices>
</system.web>
</configuration>
Más información de Microsoft
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.
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:
JSON.stringify()
y usando:
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 el objeto que estaba publicando.
<a href="/service/servicename.asmx/FunctionName/parameter=SomeValue">label</a>
Para el registro, recibí este error cuando moví una aplicación antigua de un servidor a otro. <add name="HttpGet"/> <add name="HttpPost"/> los elementos <add name="HttpGet"/> <add name="HttpPost"/> 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 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é.
También tengo 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 está funcionando a pesar de este error. Debería verlo agregando ?WSDL al final de la url, es decir, http://localhost/WebService1.asmx?WSDL
Yo uso la siguiente línea de código para solucionar este problema. Escribe el siguiente código en el archivo web.config
<configuration>
<system.web.extensions>
<scripting>
<webServices>
<jsonSerialization maxJsonLength="50000000"/>
</webServices>
</scripting>
</system.web.extensions>
</configuration>
un WebMethod que requiere una ContextKey,
[WebMethod]
public string[] GetValues(string prefixText, int count, string contextKey)
Cuando esta clave no está establecida, obtuve la excepción.
Arreglarlo asignando la clave AutoCompleteExtender.
ac.ContextKey = "myKey";