(источник из здесь .)
Обозначение квадратной скобки позволяет использовать символы, которые нельзя использовать с точечной нотацией:
blockquote>var foo = myForm.foo[]; // incorrect syntax var foo = myForm["foo[]"]; // correct syntax
Во-вторых, обозначения квадратной скобки полезны при работе с именами свойств, которые меняются предсказуемым образом:
blockquote>for (var i = 0; i < 10; i++) { someFunction(myForm["myControlNumber" + i]); }
Roundup:
blockquote>
- Точечная запись быстрее записывается и читается.
- Обозначение квадратной скобки позволяет получить доступ к свойствам, содержащим специальные символы и выбор свойств с использованием переменных
Другим примером символов, которые нельзя использовать с точечной нотацией, являются имена свойств , которые сами содержат точку .
Например, Ответ json может содержать свойство, называемое
bar.Baz
.var foo = myResponse.bar.Baz; // incorrect syntax var foo = myResponse["bar.Baz"]; // correct syntax
Найден решение на этом веб-сайте
Все, что вам нужно, это добавить следующее к вашему web.config
<configuration>
<system.web>
<webServices>
<protocols>
<add name="HttpGet"/>
<add name="HttpPost"/>
</protocols>
</webServices>
</system.web>
</configuration>
Дополнительная информация с Microsoft
В моем случае у меня была перегрузка функции, которая вызывала это исключение, как только я изменил имя моей второй функции, она прошла нормально, угадайте, что веб-сервер не поддерживает перегрузку функции
В нашем случае проблема была вызвана вызовом веб-службы с использованием метода запроса OPTIONS (вместо GET или POST).
Мы все еще не знаем, почему проблема внезапно появилась. Веб-служба работала в течение 5 лет отлично по HTTP и HTTPS. Мы единственные, кто потребляет веб-сервис, и он всегда использует POST.
Недавно мы решили сделать сайт, на котором размещен только веб-сервис SSL. Мы добавили правила перезаписи в Web.config, чтобы конвертировать что-либо HTTP в HTTPS, развернуто и сразу же начали получать, помимо обычных запросов GET и POST, запросов OPTIONS. Запросы OPTIONS вызвали ошибку, обсуждаемую на этом посту.
Остальная часть приложения работала отлично. Из-за этой проблемы мы продолжаем получать сотни сообщений об ошибках.
Существует несколько сообщений (например, this ), в которых обсуждается, как обращаться с методом 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();
}
}
Несмотря на 90% всей информации, которую я нашел (пытаясь найти решение этой ошибки), я сказал, чтобы добавить HttpGet
и HttpPost
в конфигурацию, которая не сработала для меня ... и didn Мне все равно.
Мое приложение работает на множестве серверов (30+), и мне никогда не приходилось добавлять эту конфигурацию для любого из них. Либо версия приложения, работающего под .NET 2.0, либо .NET 4.0.
Для меня было реорганизацией ASP.NET для IIS.
Я использовал следующую команду для достижения этой цели ...
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet_regiis.exe -i
aspnet_regiis -i
исправил это.
– Nate
15 July 2015 в 22:14
У меня не было проблемы при разработке в localhost. Однако, как только я опубликовал веб-сервер, веб-сервис возвращал пустой (пустой) результат, и я видел ошибку в своих журналах.
Я установил его, установив my 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"
});
Превосходно
Случай 2 - в том случае, когда одна и та же проблема может возникнуть), в моем случае проблема была вызвана следующей строкой:
<webServices>
<protocols>
<remove name="Documentation"/>
</protocols>
</webServices>
Это хорошо работает на сервере как вызовы выполняются непосредственно с помощью функции webservice - однако это не сработает, если вы запустите службу непосредственно из .Net в среде отладки и хотите протестировать запуск функции вручную.
Я также получил эту ошибку с mod-mona apache. Похоже, что страница документации для webservice еще не реализована в Linux. Но webservice работает, несмотря на эту ошибку. Вы должны увидеть это, добавив ?WSDL
в конец URL-адреса, т. Е. http: //localhost/WebService1.asmx? WSDL
Убедитесь, что вы отключили пользовательские ошибки. Это может замаскировать исходную проблему в вашем коде:
изменить
<customErrors defaultRedirect="~/Error" mode="On">
на
<customErrors defaultRedirect="~/Error" mode="Off">
Я использую следующую строку кода, чтобы исправить эту проблему. Напишите следующий код в файле web.config
<configuration>
<system.web.extensions>
<scripting>
<webServices>
<jsonSerialization maxJsonLength="50000000"/>
</webServices>
</scripting>
</system.web.extensions>
</configuration>
a WebMethod, который требует ContextKey,
[WebMethod]
public string[] GetValues(string prefixText, int count, string contextKey)
, когда этот ключ не установлен, получил исключение.
Исправление, назначая ключ автозаполненияExtender.
ac.ContextKey = "myKey";
В моем случае ошибка произошла, когда я перешел с локального ПК Windows 10 на выделенный сервер с Windows 2012. Решением было добавить в web.config следующие строки
<webServices>
<protocols>
<add name="Documentation"/>
</protocols>
</webServices>
Для записи я получал эту ошибку, когда я переместил старое приложение с одного сервера на другой. Я добавил элементы <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>
Почему он работал без этих строк на одном веб-сервере, а не на другом, которого я не знаю.
В html вы должны заключить вызов в форме aa с помощью GET с чем-то вроде
<a href="/service/servicename.asmx/FunctionName/parameter=SomeValue">label</a>
. Вы также можете использовать POST
, действие которого заключается в местоположении веб-службы и ввода параметр через входной тег.
Существуют также SOAP
и прокси-классы.
Убедитесь, что вы используете правильный метод: 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); }
})