Format żądania jest nierozpoznany dla adresu URL nieoczekiwanie kończącego się na

Pomimo 90% wszystkich informacji, które znalazłem (próbując znaleźć rozwiązanie tego błędu) mówiących mi, aby dodać HttpGet i HttpPost do konfiguracji, to nie działa dla mnie... i to nie miało dla mnie sensu.

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

Rozwiązaniem dla mnie było ponowne zarejestrowanie ASP.NET przeciw 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: Post / Get, właściwy typ treści i właściwe 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); }
})

Super.

Przypadek 2-gdzie może pojawić się ten sam problem) w moim przypadku problem wynikał z następującej linijki:

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

Działa dobrze na serwerze, ponieważ połączenia są wykonywane bezpośrednio do funkcji webservice - jednak nie powiedzie się, jeśli uruchomisz usługę bezpośrednio z. Net w środowisku debugowania i chcesz przetestować uruchomienie funkcji ręcznie.

Dla przypomnienia otrzymywałem ten błąd, gdy przenosiłem starą aplikację z jednego serwera na drugi. Dodałem <add name="HttpGet"/> <add name="HttpPost"/> elementy do sieci.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 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 to działało bez tych linii na jednym serwerze WWW, a nie na drugim Nie wiem.

Używam poniższej linii kodu, aby rozwiązać ten problem. Napisz poniższy kod w web.plik konfiguracyjny

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

Nie miałem problemu podczas tworzenia w localhost. Jednak gdy opublikowałem na serwerze internetowym, webservice zwracał 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 umieszczał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"
            });

W html musisz załączyć wywołanie w formie A Z GET z czymś takim jak

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

Można również użyć POST, gdzie akcja jest lokalizacją usługi internetowej i wprowadzić parametr za pomocą znacznika wejściowego.

Istnieją również klasy SOAP i proxy.

W moim przypadku miałem przeciążenie funkcji, które powodowało ten wyjątek, po zmianie nazwy mojej drugiej funkcji działało ok, chyba web server nie obsługuje przeciążania funkcji

Mam też ten błąd z apache mod-mono. Wygląda na to, że strona dokumentacji dla webservice nie jest jeszcze zaimplementowana w Linuksie. Ale webservice działa pomimo tego błędu. Powinieneś go zobaczyć dodając ?WSDL na końcu adresu url, czyli http://localhost/WebService1.asmx?WSDL

W naszym przypadku problem był spowodowany wywołaniem usługi internetowej przy użyciu metody request (zamiast GET lub POST).

Niedawno zdecydowaliśmy się na stronę, która hostuje tylko SSL usługi internetowej. Dodaliśmy reguły przepisywania do sieci.config to Konwertuj wszystko HTTP na HTTPS, wdrożone i natychmiast zaczęły otrzymywać, oprócz zwykłych żądań GET I POST, żądania opcji. Żądania opcji spowodowały błąd omówiony w tym poście.

Reszta aplikacji działała doskonale. Ale ciągle otrzymywaliśmy setki raportów o błędach z powodu tego problemu.

Jest kilka postów (np. Ten) omawiających sposób obsługi metody OPTIONS. Udaliśmy się do obsługi żądania opcji 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();
        }
    }

W moim przypadku błąd wystąpił, gdy przenoszę się z mojego lokalnego komputera z systemem Windows 10 na serwer dedykowany z systemem Windows 2012. Rozwiązaniem było dodanie do sieci.config następujące linie

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

Upewnij się, że wyłączyłeś błędy niestandardowe. Może to zamaskować oryginalny problem w kodzie:

Zmień

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

Do

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

[[2]}WebMethod, który wymaga ContextKey,

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

Gdy ten klucz nie jest ustawiony, otrzymujemy wyjątek.

Naprawianie go przez przypisanie klucza AutoCompleteExtender.

ac.ContextKey = "myKey";