当消费WebService时,我得到了以下错误:
URL意外以/myMethodName结尾,请求格式无法识别
如何解决这个问题?
当消费WebService时,我得到了以下错误:
URL意外以/myMethodName结尾,请求格式无法识别
如何解决这个问题?
当前回答
在我们的例子中,问题是由使用OPTIONS请求方法(而不是GET或POST)调用web服务引起的。
我们仍然不知道为什么问题突然出现了。该web服务已经在HTTP和HTTPS上运行了5年。我们是唯一使用web服务的人,而且它总是使用POST。
最近,我们决定让网站只托管web服务SSL。我们向Web添加了重写规则。配置,将任何HTTP转换为HTTPS,部署,并立即开始获取,在常规的GET和POST请求之上,OPTIONS请求。OPTIONS请求导致了本文中讨论的错误。
应用程序的其余部分工作得非常好。但是由于这个问题,我们不断收到数百个错误报告。
有几篇文章(例如这篇)讨论了如何处理OPTIONS方法。我们直接在Global.asax中处理OPTIONS请求。这使问题消失了。
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();
}
}
其他回答
尽管我发现90%的信息(在试图找到解决这个错误的方法时)告诉我将HttpGet和HttpPost添加到配置中,但这对我来说并不奏效…反正对我来说也说不通。
我的应用程序运行在很多服务器上(30多个),我从来没有为其中任何一个服务器添加过这个配置。在。net 2.0或。net 4.0下运行的应用程序的版本。
我的解决办法是重新注册ASP。NET对抗IIS。
我使用下面的命令行来实现这一点…
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_regiis.exe -i
我也得到这个错误与apache mod-mono。看起来webservice的文档页在linux中还没有实现。但是尽管出现了这个错误,web服务仍然正常工作。您应该通过在url的末尾添加?WSDL来看到它,即http://localhost/WebService1.asmx?WSDL
极好的。
情况2 -同样的问题可以出现)在我的情况下,问题是由于以下一行:
<webServices>
<protocols>
<remove name="Documentation"/>
</protocols>
</webServices>
它在服务器上工作得很好,因为直接调用webservice函数——但是如果你在调试环境中直接从。net运行服务,并且想要手动测试运行该函数,则会失败。
我在本地主机开发时没有这个问题。然而,一旦我发布到一个web服务器,web服务返回一个空(空白)的结果,我看到我的日志中的错误。
我通过设置我的ajax contentType来修复它:
"application/json; charset=utf-8"
并使用:
JSON.stringify()
在我张贴的物体上。
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"
});
在我的情况下,我有一个重载的函数,导致这个异常,一旦我改变了我的第二个函数的名称,它运行正常,猜web服务器不支持函数重载