Формат запиту не розпізнається для URL-адреси, який несподівано закінчується

Це не питання - розмістити його тут для довідки:

Під час використання WebService я отримав таку помилку:

Формат запиту не розпізнається для URL-адреси, який несподівано закінчується в / myMethodName

Знайшли рішення на цьому веб-сайті

Все, що вам потрібно, це додати наступне до свого web.config

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

Більше інформації від Microsoft

Незважаючи на 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

Переконайтеся, що ви використовуєте правильний метод: Опублікувати / Отримати, правильний тип вмісту та правильні параметри (дані).

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

Прекрасно.

Випадок 2 - коли може виникнути те саме питання) у моєму випадку проблема була пов'язана з наступним рядком:

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

Він добре працює на сервері, оскільки дзвінки здійснюються безпосередньо до функції веб-сервісу - однак, це не вдасться, якщо ви запускаєте службу безпосередньо з .Net в середовищі налагодження і хочете перевірити запуск функції вручну.

Для запису я отримував цю помилку, коли переходив старий додаток з одного сервера на інший. Я додав <add name="HttpGet"/> <add name="HttpPost"/>елементи до web.config, які змінили помилку на:

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)

Щоб виправити цю помилку, мені довелося додати рядки ScriptHandlerFactory до 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>

Чому він працював без цих рядків на одному веб-сервері, а не на іншому, я не знаю.

Я використовую наступний рядок коду, щоб вирішити цю проблему. Введіть наступний код у файл web.config

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

У мене не було проблеми при розробці в localhost. Однак, коли я опублікував веб-сервер, веб-сервіс повертав порожній (порожній) результат, і я помічав помилку в своїх журналах.

Я виправив це, встановивши свій 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"
            });

Я також отримав цю помилку з apache mod-mono. Схоже, сторінка документації для веб-сервісу ще не реалізована в Linux. Але веб-служба працює, незважаючи на цю помилку. Ви повинні побачити це, додавши ?WSDLв кінці URL-адреси, тобто http: //localhost/WebService1.asmx? WSDL

У моєму випадку помилка сталася під час переходу з мого локального ПК Windows 10 на спеціальний сервер із Windows 2012. Рішенням було додати до web.config наступні рядки

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

У html ви повинні укласти виклик у формі aa з GET з чимось подібним

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

Ви також можете скористатися символом a, POSTв якому знаходиться місце розташування веб-служби, і введіть параметр через тег введення.

Є також SOAPі проксі-класи.

У моєму випадку у мене було перевантаження функції, яка спричиняла цей Виняток, як тільки я змінив ім'я своєї другої функції, вона працювала нормально, думаю, веб-сервер не підтримує функцію перевантаження

У нашому випадку проблема була викликана викликом веб-служби за допомогою методу запиту OPTIONS (замість GET або POST).

Ми досі не знаємо, чому проблема несподівано з’явилася. Веб-сервіс вже 5 років працює на HTTP та HTTPS. Ми єдині, хто споживає веб-сервіс, і він завжди використовує POST.

Нещодавно ми вирішили зробити сайт, на якому розміщується тільки веб-сервіс SSL. Ми додали правила перезапису до Web.config для перетворення будь-якого HTTP у HTTPS, розгорнутого та негайно почали отримувати, крім звичайних GET та POST запитів, OPTIONS запитів. Запити OPTIONS спричинили помилку, обговорену в цій публікації.

Решта програми працювали на відмінно. Але ми постійно отримували сотні повідомлень про помилки через цю проблему.

Є кілька дописів (наприклад, цей ), де обговорюється спосіб поводження з методом OPTIONS. Ми звернулися до обробки запиту OPTIONS безпосередньо в Global.asax. Це призвело до зникнення проблеми.

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

Я отримував цю помилку, поки не додав (як показано в коді нижче) $ .holdReady (справжній) на початку мого виклику веб-служби та $ .holdReady (помилковий) після його закінчення. Це jQuery, щоб призупинити стан готової сторінки, щоб будь-який скрипт у функції document.ready чекав цього (серед інших можливих, але невідомих мені речей).

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

Переконайтеся, що ви відключили власні помилки. Це може приховати початкову проблему у вашому коді:

змінити

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

до

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

WebMethod, який вимагає ContextKey,

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

коли цей ключ не встановлений, отримали виняток.

Виправити це за допомогою призначення ключа AutoCompleteExtender.

ac.ContextKey = "myKey";