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

283

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

Roman m
źródło
4
Aby ułatwić Google, niemieckie tłumaczenie komunikatu o błędzie brzmi „ Unbekanntes Anforderungsformat für eine URL, die unerwartet mit '/ _myMethodName' endet. ”.
Uwe Keim
I chińskie tłumaczenie: „ 無法 辨認 要求 格式 , 因為 URL 未 預期 地 以 / myMethodName 結束。
Ignatius

Odpowiedzi:

515

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

Roman m
źródło
3
MYŚLĘ, że wszystko, co musisz zrobić, to przełączyć <system.web> na <system.webserver>
roman m
Zachowałem go tak, jak jest i na razie błąd wydaje się zniknąć. jeśli ponownie zobaczę błąd, przeniosę konfiguracje usług internetowych do sekcji serwera WWW.
Daniel Brink,
1
A co, jeśli ten błąd zostanie zgłoszony bez żadnej regularności, tylko czasami? Czy takie połączenia zależą od konfiguracji klienta / przeglądarki !?
Vladislav
2
W Win2012srv z IIS8 było to potrzebne. W Win8 z IIS8 nie było to potrzebne. Żadnych innych rozbieżności w konfiguracji, o której wiem.
LosManos
1
@SaurabhRai ja też. Co to zrobiło? Linki podane w odpowiedzi są zepsute.
Rod
18

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
freefaller
źródło
To naprawiło mój problem. Otrzymałem ten sam błąd co OP; na wcześniej działającej stronie. Okazuje się, że ktoś włączył .NET 3.5 przez funkcje systemu Windows (z niepowiązanych powodów), które zepsuły moją stronę. aspnet_regiis -inaprawiłem to.
Nate
16

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); }
})
HasanG
źródło
1
mój przekazanie wartości parametru wystąpił problem z powodu typu danych i brakujących wartości, które kończą się błędem 500. teraz jest rozwiązany.
Pranesh Janarthanan
Add również content-type: application/jsonrozwiązał ten problem.
Delphi.Boy
10

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.

Kalpesh Popat
źródło
Dodano tę logikę do pliku web.config, aby uniemożliwić wyświetlanie definicji podczas przeglądania usługi .asmx. Najwyraźniej zepsuło ActiveReports. Cieszę się, że jest to objaw testowania lokalnego i będzie działał na serwerze. Dzięki.
Jacob Barnes,
2

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.

Sprintstar
źródło
1

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>
pankaj prajapati
źródło
1

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"
            });
Jason Williams
źródło
1

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

L0pan
źródło
1

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>
Ruby Kousinovali
źródło
0

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.

Dave
źródło
0

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

Amir Shrestha
źródło
0

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();
        }
    }
cockipup
źródło
0

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>
bestinamir
źródło
-1

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">
Milan de Jong
źródło
-1

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";
Rm558
źródło