O formato da solicitação não é reconhecido para o URL que termina inesperadamente em

Esta não é uma pergunta - publique-a aqui para referência:

Ao consumir um WebService, recebi o seguinte erro:

O formato da solicitação não é reconhecido para o URL que termina inesperadamente em / myMethodName

Encontrei uma solução neste site

Tudo que você precisa é adicionar o seguinte ao seu web.config

<configuration>
  <system.web>
    <webServices>
      <protocols>
        <add name="HttpGet"/>
        <add name="HttpPost"/>
      </protocols>
    </webServices>
  </system.web>
</configuration>

Mais informações da Microsoft

Apesar de 90% de todas as informações que encontrei (enquanto tentava encontrar uma solução para esse erro) me dizendo para adicionar o HttpGeteHttpPost à configuração, que não funcionou para mim ... e não faz sentido para mim de qualquer maneira.

Meu aplicativo está sendo executado em muitos servidores (mais de 30 anos) e nunca precisei adicionar essa configuração a nenhum deles. A versão do aplicativo em execução no .NET 2.0 ou .NET 4.0.

A solução para mim foi registrar novamente o ASP.NET no IIS.

Eu usei a seguinte linha de comando para conseguir isso ...

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

Verifique se você está usando o método certo: Post / Get, tipo de conteúdo certo e parâmetros certos (dados).

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

Soberbo.

Caso 2 - onde o mesmo problema pode surgir) no meu caso, o problema ocorreu devido à seguinte linha:

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

Funciona bem no servidor, pois as chamadas são feitas diretamente para a função de serviço da web - no entanto, falhará se você executar o serviço diretamente de .Net no ambiente de depuração e desejar testar a execução manual da função.

Para o registro, eu estava recebendo esse erro quando movi um aplicativo antigo de um servidor para outro. Adicionei os <add name="HttpGet"/> <add name="HttpPost"/>elementos ao web.config, que alterou o erro para:

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 corrigir esse erro, tive que adicionar as linhas ScriptHandlerFactory ao 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 que funcionou sem essas linhas em um servidor web e não no outro eu não sei.

Eu uso a seguinte linha de código para corrigir esse problema. Escreva o seguinte código no arquivo web.config

<configuration>
    <system.web.extensions>
       <scripting>
       <webServices>
       <jsonSerialization maxJsonLength="50000000"/>
      </webServices>
     </scripting>
   </system.web.extensions>
</configuration>

Eu não tive o problema ao desenvolver no localhost. No entanto, depois que publiquei em um servidor Web, o serviço Web retornava um resultado vazio (em branco) e eu estava vendo o erro nos meus logs.

Corrigi-o definindo meu conteúdo ajax para:

"application/json; charset=utf-8"

e usando:

JSON.stringify()

no objeto que eu estava postando.

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"
            });

Eu também recebi esse erro com o apache mod-mono. Parece que a página de documentação do webservice ainda não foi implementada no linux. Mas o serviço da web está funcionando apesar desse erro. Você deve vê-lo adicionando ?WSDLno final do URL, ou seja, http: //localhost/WebService1.asmx? WSDL

No meu caso, o erro ocorreu quando mudo do meu PC local Windows 10 para um servidor dedicado com Windows 2012. A solução para foi adicionar ao web.config as seguintes linhas

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

No html, você deve anexar a chamada em um formulário com um GET com algo como

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

Você também pode usar a POSTcom a ação sendo o local do serviço da web e inserir o parâmetro por meio de uma tag de entrada.

Existem também SOAPclasses proxy.

No meu caso, eu tinha uma sobrecarga de função que estava causando essa exceção, uma vez que mudei o nome da minha segunda função, ela funcionou ok, acho que o servidor da Web não suporta sobrecarga de função

No nosso caso, o problema foi causado pela chamada do serviço da Web usando o método de solicitação OPTIONS (em vez de GET ou POST).

Ainda não sabemos por que o problema apareceu de repente. O serviço da web estava em execução há 5 anos perfeitamente bem em HTTP e HTTPS. Somos os únicos que consomem o serviço da web e ele está sempre usando o POST.

Recentemente, decidimos tornar o site que hospeda apenas o serviço Web SSL. Adicionamos regras de reescrita ao Web.config para converter qualquer coisa HTTP em HTTPS, implantadas e imediatamente começamos a receber, além das solicitações regulares GET e POST, solicitações OPTIONS. As solicitações OPTIONS causaram o erro discutido nesta postagem.

O restante do aplicativo funcionou perfeitamente bem. Mas continuamos recebendo centenas de relatórios de erros devido a esse problema.

Existem vários posts (por exemplo, este ) discutindo como lidar com o método OPTIONS. Fomos lidar com a solicitação OPTIONS diretamente no Global.asax. Isso fez o problema desaparecer.

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

Eu estava recebendo esse erro até adicionar (como mostrado no código abaixo) $ .holdReady (true) no início da minha chamada de serviço da web e $ .holdReady (false) após o término. Isso é coisa do jQuery para suspender o estado pronto da página, para que qualquer script dentro da função document.ready esteja esperando por isso (entre outras coisas possíveis, mas desconhecidas para mim).

<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>

Certifique-se de desativar os erros personalizados. Isso pode mascarar o problema original no seu código:

mudança

<customErrors defaultRedirect="~/Error" mode="On">

para

<customErrors defaultRedirect="~/Error" mode="Off">

um WebMethod que requer um ContextKey,

[WebMethod]
public string[] GetValues(string prefixText, int count, string contextKey)

quando essa chave não está definida, obtém a exceção.

Corrigindo-o atribuindo a chave do AutoCompleteExtender.

ac.ContextKey = "myKey";