Как мне запустить асинхронный вызов в asp classic и проигнорировать ответ?

Question

Вот суть:

У меня есть звонок, который я хочу сделать в asp, и мне наплевать на ответ. Я просто хочу сделать звонок и не хочу, чтобы страница ждала ответа. Согласно документации, это должно выглядеть примерно так:

dim xmlhttp : set xmlhttp = Server.CreateObject("MSXML2.ServerXMLHTTP")
xmlhttp.Open "POST", url, true '' setting the 'asynchronous' option to 'true'
xmlhttp.setRequestHeader "Content-Type", "application/soap+xml; charset=utf-8"
xmlhttp.setRequestHeader "Content-Length", Len(XMLData)
xmlhttp.send XMLData

Это работает замечательно при синхронном вызове, но когда я переключаю асинхронную опцию на 'true', ничего не срабатывает. Что я могу извлечь из Интернета, так это то, что пользователи делают что-то вроде следующего:

While xmlhttp.readyState <> 4
    xmlhttp.waitForResponse 1000
Wend

Неужели я схожу с ума от того, что это больше не похоже на асинхронный вызов, если вы ждете ответа?

установка строки xmlhttp.waitForResponse 1 сразу после отправки вызовет запрос, но, опять же, я не хочу ждать секунду.

Есть мысли?

Answer 1

Сегодня я получил ту же проблему. Я решил это с помощью объекта "Microsoft.XMLHTTP".

dim xmlhttp 
set xmlhttp = Server.CreateObject("Microsoft.XMLHTTP")
xmlhttp.Open "POST", url, true 
xmlhttp.Send ""

И теперь запрос отправляется асинхронно, и целевой URL был достигнут. Надеюсь, это поможет.

Answer 2

Ключевая проблема здесь в том, что если вы не ждете, и ваш скрипт завершает работу, компонент ServerXMLHTTP уничтожает себя и в процессе прерывает невыполненный запрос. У вас нет возможности гарантировать, куда попал запрос в то время.

Например, если ваш сервер не успел выполнить выдачу на сервер назначения, он увидит, что он больше не нужен, и не беспокоит.

Даже если было установлено соединение с сервером назначения, запрос, возможно, еще не был передан обработчику. Часто веб-сервер проверяет, что клиент все еще подключен, прежде чем выделять ресурсы для выполнения запроса. Если он обнаружит, что ваше соединение разорвано, он не потрудится завершить запрос.

Другими словами, в классическом ASP нет надежного способа выполнить эту операцию асинхронно, просто он не предназначен для такого рода вещей. Лучшее, что вы можете получить, - это делать что-то другое, пока ваш сценарий работает с чем-то другим (если у вас есть что-то еще, с чем можно столкнуться), однако, я бы даже не рекомендовал этого, поскольку асинхронный WinHTTP внутри ASP является нестабильным.

Answer 3

Мы используем async XMLRequest для регистрации ошибок в Fogbugz на наших сайтах ASP. Поскольку это всего лишь сообщение об ошибке, мы не хотим, чтобы наши пользователи зависали в ожидании завершения работы нашего кода, поэтому мы делаем это асинхронно. Это может быть что угодно, от отсутствующего файла конфигурации, тайм-аута БД, отсутствия поиска в файле конфигурации и т. Д. Не всегда критические вещи, но полезно знать. В этих случаях асинхронная работа приносит удовольствие, а если нет, то это не конец света для нас, но у нас не было с этим проблем. Мы использовали этот скрипт, который мы создали и разместили в другом вопросе:

System.Net.HttpWebRequest в классическом asp?

Как говорит Энтони, хотя и не гарантировано, что он пройдёт на 100%. В качестве возможного исправления вы можете указать Response.Buffer = true, передать все свои выходные данные пользователю, вызвать Response.Flush, а затем выполнить вызов waitForResponse. Пользователь увидит всю страницу и сможет взаимодействовать с ней без задержки, и это даст вашему асинхронному вызову немного больше времени для завершения.

Answer 4

Другой вариант, если вы все еще хотите использовать объект ServerXMLHTTP (а не клиентский компонент, упомянутый выше Антоном, см. FAQ # 4 в http://support.microsoft.com/kb/290761), - создать класс VBScript. Создайте экземпляр класса. Установите a Свойство класса для объекта HTTP. Затем вызовите метод для запуска запроса.

Никогда не разрушайте экземпляр класса - он будет автоматически уничтожен, когда страница ASP завершится. Сделайте так, чтобы метод уничтожения класса освободил объект HTTP - это должно дать ему достаточно времени для запуска запроса до его уничтожения.