Отладка: IE6 + SSL + AJAX + post form = ошибка 404
Параметр:
рассматриваемая программа пытается отправить данные формы через вызов AJAX в целевую процедуру, содержащуюся в том же пакете, что и вызывающий. Это сделано для сайта, который использует безопасное соединение (HTTPS). Используемая здесь технология - PLSQL и библиотека DOJO JavaScript. Инструмент разработки - это, по сути, текстовый редактор .
Фрагмент кода:
> function testPost() {
>> dojo.xhrPost( {
url: ''dr_tm_w_0120.test_post'',
form: ''orgForm'',
load: testPostXHRCallback,
error: testPostXHRError
});
}
> function testPostXHRCallback(data,ioArgs) {
>> alert(''post callback'');
try{
dojo.byId("messageDiv").innerHTML = data;
}
catch(ex){
if(ex.name == "TypeError")
{
alert("A type error occurred.");
}
}
return data;
}
>
function testPostXHRError(data, ioArgs) {
>> alert(data);
alert(''Error when retrieving data from the server!'');
return data;
}
Проблема:
при использовании IE6 (который использует вся пользовательская база) ответ, отправленный обратно с сервера, представляет собой ошибку 404.
Наблюдения:
Программа отлично работает в Firefox.
Вызывающая процедура не может нацеливаться на какие-либо процедуры в одном пакете.
Вызывающая процедура может быть нацелена на внешние сайты (как http, так и https).
Другие вызовы AJAX в пакете, которые не являются сообщениями данных формы, работают нормально.
Я искал в Интернете и проконсультировался с высококвалифицированными членами команды и не нашел ничего, что удовлетворительно решало бы эту проблему.
* Пробовал отвечать на вопросы на форумах поддержки Dojo.
Вопросы:
какие методы устранения неполадок вы рекомендуете?
Какие инструменты устранения неполадок вы рекомендуете для анализа HTTPS?
Есть какие-нибудь гипотезы о том, в чем может быть проблема?
Есть идеи обходных путей, которые не являются полным (плохим) взломом?
Эд. Решение
lomaxx, спасибо за подсказку скрипача . Вы даже не представляете, как здорово было получить это и использовать в качестве инструмента отладки. после запуска это то, что я обнаружил и как я это исправил (по крайней мере, в краткосрочной перспективе):
> ef Fri, 8 Aug 2008 14:01:26 GMT dr_tm_w_0120.test_post: SIGNATURE (parameter names) MISMATCH VARIABLES IN FORM NOT IN PROCEDURE: SO1_DISPLAYED_,PO1_DISPLAYED_,RWA2_DISPLAYED_,DD1_DISPLAYED_ NON-DEFAULT VARIABLES IN PROCEDURE NOT IN FORM: 0
Увидев это сообщение с сервера, я еще немного побродил по Fiddler, чтобы посмотреть, что еще я мог бы узнать из него. Обнаружено, что есть вкладка WebForms, которая показывает значения в веб-форме. Разве вы не знали, xxx_DISPLAYED_
поля " " выше были в нем.
Я еще не совсем понимаю, почему эти поля существуют, потому что я не создавал их явно в веб- PLSQL
коде. Но теперь я понимаю, что целевая процедура должна включать их в качестве параметров для правильной работы. Опять же, это только в случае со IE6
мной, поскольку Firefox работал нормально.
Хорошо, что краткосрочный ответ и хакерство, чтобы это исправить. Надеюсь, немного больше работы в этой области приведет к лучшему пониманию основных принципов, происходящих здесь.
Ответов (1)1
Первый порт вызова - запустить Fiddler и проанализировать данные, поступающие в браузер и из него.
Взгляните на заголовки, фактически вызываемый URL-адрес и параметры (если есть), передаваемые в метод AJAX, и посмотрите, все ли это выглядит хорошо, прежде чем попасть на сервер.
Если все выглядит нормально, есть ли способ проверить, действительно ли он попадает на сервер, через ведение журнала или трассировку с помощью метода AJAX?
ed: еще одна вещь, которую я бы попробовал, - это настроить тестовую страницу для вызова метода AJAX на сервере с использованием вызова, отличного от ajax, и проанализировать трафик в fiddler и сравнить их.