Формат запроса не распознается для 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

Убедитесь, что вы используете правильный метод: Post / Get, правильный тип контента и правильные параметры (данные).

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

Superb.

Случай 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 вы должны заключить вызов в форме с GET с чем-то вроде

<a href="/service/servicename.asmx/FunctionName/parameter=SomeValue">label</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 (true) в начале вызова веб-службы и $ .holdReady (false) после его завершения. Это 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";