Format żądania nie został rozpoznany, ponieważ adres URL niespodziewanie kończy się na

To nie jest pytanie - opublikowanie go tutaj w celach informacyjnych:

Podczas korzystania z usługi WebService wystąpił następujący błąd:

Format żądania nie został rozpoznany dla adresu URL nieoczekiwanie kończącego się na / myMethodName

Znalazłem rozwiązanie na tej stronie

Wystarczy dodać następujące elementy do pliku web.config

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

Więcej informacji od Microsoft

Pomimo 90% wszystkich informacji, które znalazłem (podczas próby znalezienia rozwiązania tego błędu) mówiących mi o dodaniu HttpGeti HttpPostdo konfiguracji, które nie działały dla mnie ... i nie miały dla mnie sensu.

Moja aplikacja działa na wielu serwerach (30+) i nigdy nie musiałem dodawać tej konfiguracji dla żadnego z nich. Wersja aplikacji działająca pod .NET 2.0 lub .NET 4.0.

Rozwiązaniem było dla mnie ponowne zarejestrowanie ASP.NET w IIS.

Użyłem następującego wiersza poleceń, aby to osiągnąć ...

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

Upewnij się, że używasz właściwej metody: Wyślij / Pobierz, odpowiedni typ treści i odpowiednie parametry (dane).

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

Wspaniały.

Przypadek 2 - gdzie może wystąpić ten sam problem) w moim przypadku problem był spowodowany następującą linią:

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

Działa dobrze na serwerze, ponieważ wywołania są wykonywane bezpośrednio do funkcji usługi WWW - jednak zakończy się niepowodzeniem, jeśli uruchomisz usługę bezpośrednio z .Net w środowisku debugowania i chcesz przetestować uruchomienie funkcji ręcznie.

Dla przypomnienia otrzymałem ten błąd, kiedy przeniosłem starą aplikację z jednego serwera na inny. Dodałem <add name="HttpGet"/> <add name="HttpPost"/>elementy do pliku web.config, który zmienił błąd na:

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)

Aby naprawić ten błąd, musiałem dodać linie ScriptHandlerFactory do pliku 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>

Dlaczego działało bez tych linii na jednym serwerze WWW, a nie na drugim, nie wiem.

Używam następującego wiersza kodu, aby naprawić ten problem. Wpisz następujący kod w pliku web.config

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

Nie miałem problemu podczas programowania w localhost. Jednak po opublikowaniu na serwerze internetowym usługa zwróciła pusty (pusty) wynik i widziałem błąd w moich dziennikach.

Naprawiłem to, ustawiając mój ajax contentType na:

"application/json; charset=utf-8"

i używając:

JSON.stringify()

na obiekcie, który publikowałem.

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

Ten błąd również dostałem w przypadku apache mod-mono. Wygląda na to, że strona dokumentacji dla serwisu WWW nie jest jeszcze zaimplementowana w systemie Linux. Ale usługa internetowa działa pomimo tego błędu. Powinieneś to zobaczyć, dodając ?WSDLna końcu adresu URL, tj. Http: //localhost/WebService1.asmx? WSDL

W moim przypadku błąd wystąpił, gdy przeniosłem się z lokalnego komputera z systemem Windows 10 na serwer dedykowany z systemem Windows 2012. Rozwiązaniem było dodanie do pliku web.config następujących linii

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

W html musisz załączyć połączenie w formie GET z czymś podobnym

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

Możesz także użyć POST z akcją będącą lokalizacją usługi internetowej i wprowadzić parametr za pomocą znacznika wejściowego.

Istnieją również SOAPklasy proxy.

W moim przypadku miałem przeciążenie funkcji, które powodowało ten wyjątek, kiedy zmieniłem nazwę mojej drugiej funkcji, działała ona poprawnie, zgaduję, że serwer sieciowy nie obsługuje przeciążania funkcji

W naszym przypadku problem został wywołany przez wywołanie usługi internetowej za pomocą metody żądania OPTIONS (zamiast GET lub POST).

Nadal nie wiemy, dlaczego problem nagle się pojawił. Usługa internetowa działała doskonale przez 5 lat zarówno przez HTTP, jak i HTTPS. Jesteśmy jedynymi, którzy korzystają z usługi internetowej i zawsze korzysta z POST.

Niedawno postanowiliśmy stworzyć witrynę, która będzie hostować wyłącznie usługę sieciową SSL. Dodaliśmy reguły przepisywania do Web.config, aby przekonwertować dowolny HTTP na HTTPS, wdrożyliśmy i natychmiast zaczęliśmy otrzymywać, oprócz zwykłych żądań GET i POST, żądania OPCJE. Żądania OPTIONS spowodowały błąd omówiony w tym poście.

Reszta aplikacji działała idealnie. Ale wciąż otrzymywaliśmy setki raportów o błędach z powodu tego problemu.

Istnieje kilka postów (np. Ten ) omawiających sposób obsługi metody OPTIONS. Poszliśmy do obsługi żądania OPCJE bezpośrednio w Global.asax. To sprawiło, że problem zniknął.

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

Otrzymywałem ten błąd, dopóki nie dodałem (jak pokazano w poniższym kodzie) $ .holdReady (true) na początku mojego wywołania usługi internetowej i $ .holdReady (false) po jego zakończeniu. Jest to jQuery, aby zawiesić stan gotowości strony, aby każdy skrypt w funkcji document.ready czekał na to (wśród innych możliwych, ale nieznanych mi rzeczy).

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

Pamiętaj, aby wyłączyć niestandardowe błędy. Może to maskować oryginalny problem w kodzie:

zmiana

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

do

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

WebMethod wymagający ContextKey,

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

gdy ten klucz nie jest ustawiony, dostał wyjątek.

Napraw go poprzez przypisanie klucza AutoCompleteExtender.

ac.ContextKey = "myKey";