Depuración: IE6+SSL+AJAX+formulario de publicación=error 404
debugging internet-explorer (1)
El primer puerto de escala sería encender Fiddler y analizar los datos que van hacia y desde el navegador.
Eche un vistazo a los encabezados, la url que realmente se llama y los parámetros (si corresponde) que se pasan al método AJAX y vea si todo se ve bien antes de llegar al servidor.
Si todo eso se ve bien, ¿hay alguna forma de que puedas verificar que está llegando al servidor mediante el registro o el método AJAX?
ed: otra cosa que probaría es armar una página de prueba para llamar al método AJAX en el servidor utilizando una llamada que no esté basada en ajax y analizar el tráfico en el violín y comparar los dos.
El ajuste:
El programa en cuestión trata de publicar datos de formulario a través de una llamada AJAX a un procedimiento de destino contenido en el mismo paquete que la persona que llama. Esto se hace para un sitio que usa una conexión segura (HTTPS). La tecnología utilizada aquí es PLSQL y la biblioteca JavaScript de DOJO . La herramienta de desarrollo es básicamente un editor de texto .
Fragmento de código:
> 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;
}
El problema:
Cuando se usa IE6 (que usa toda la base de usuarios), la respuesta enviada desde el servidor es un error 404.
Observaciones:
El programa funciona bien en Firefox.
El procedimiento de llamada no puede dirigir ningún procedimiento dentro del mismo paquete.
El procedimiento de llamada puede dirigirse a sitios externos (tanto http, https).
Las otras llamadas AJAX en el paquete que no son publicaciones de datos de formularios funcionan bien.
He buscado en los internets y he consultado con miembros del equipo altamente capacitados y no he descubierto nada que resuelva satisfactoriamente el problema.
* He intentado hacer preguntas y respuestas en los foros de soporte de Dojo.
Las preguntas:
¿Qué técnicas de solución de problemas recomiendas?
¿Qué herramientas de solución de problemas recomienda para el análisis HTTPS?
¿Alguna hipótesis sobre cuál podría ser el problema?
¿Alguna idea para las soluciones alternativas que no son total (malas) pirateos?
Ed. La solución
lomaxx, thx para la punta del violinista . no tienes idea de lo maravilloso que fue obtener eso y usarlo como una herramienta de depuración. después de iniciarlo esto es lo que encontré y cómo lo arreglé (al menos a corto plazo):
> 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
Después de ver ese mensaje del servidor, pateé un poco más a Fiddler para ver qué más podía aprender de él. Se encontró que hay una pestaña de WebForms que muestra los valores en el formulario web. No lo sabría, los campos " xxx_DISPLAYED_
" arriba estaban en él.
Todavía no entiendo por qué existen estos campos, porque no los PLSQL
explícitamente en el código web PLSQL
. Pero ahora entiendo que el procedimiento de destino debe incluirlos como parámetros para que funcionen correctamente. Una vez más, esto es solo en el caso de IE6
para mí, ya que Firefox funcionó bien.
Bueno, eso a corto plazo responde y piratea para arreglarlo. Con suerte, un poco más de trabajo en esta área conducirá a una mejor comprensión de los fundamentos que están sucediendo aquí.