Problema con el POST de HTTP para TFPWebModule en un CGI con Apache bajo Linux

[rolandoj]

Hola,

Alguién ha podifo enviar un comando POST de HTTP por medio de Indy a un aplicativo CGI construído con Lazarus usando TFPWebModule y ejecutandose bajo el servidor Apache 2.2 en Linux Ubuntu ?

Me explico:

Empezamos por desarrollar como prueba un CGI en las condiciones dadas. Nuestras primeras pruebas fueron desde navegadores Web; es decir, enviando solo comandos GET. Cuando hicimos eso, el sistema devolvió adecuadamente las respuestas.

El paso siguiente fué probar si procesaba bien comandos POST. Para ello, escribimos un programa cliente en Windows que utiliza componentes Indy. Este programa lo verificamos primero usandolo contra DLLs ISAPI de Windows escritas en Delphi 2007 con TWebModule, y funciona perfectamente. Por tanto, el cliente funciona bien.

Cuando usamos ese mismo mismo programa contra el CGI, el sistema no devuelve nada. El Log de Apache muestra lo siguiente:

192.168.73.119 - - [29/Aug/2011:17:48:11 -0500] "POST /bin-cgi/PruebaCGI/Vertodo HTTP/1.0" 500 834 "-" "Mozilla/3.0 (compatible; Indy Library)

Suponemos que algo falta para procesar un POST; pero que ?.

Ahora, si bien es claro que la petición llega al Apache, no estamos seguros si ejecuta a nuestro programa.

Podría alguirn indicarnos como podemos depurar el programa CGI ?

Por cierto, podrían confirmarnos si puede depurarse usando Lazarus ?. Hemos enconmtrado algunas referencias a programación; pero, hablan de instalar otras herramientas y la verdad sea dicha, no parecen para opciones amigables.

Hay una parte en Lazarus que habla de una aplicación anfitrion. Por analogía con las depuraciones de DLLs ISAPI en Windows, suponemos que ahi se debe indicar el ejecutable principal de Apache; pero, cual es ?. Es cierta esa suposición ?

[[Chris]]

Lo primero que yo haría es hacer las pruebas con el explorador Web y páginas HTML antes que con un cliente de Indy. Al hacer las pruebas así por lo menos el navegador te puede brindar más información que la brindada por Indy (que es nula realmente).

Tu aplicativo CGI está teniendo un problema. Es por eso del número 500 (código HTTP reservado para los errores). Por eso es que te digo que hagas mejor las pruebas con páginas HTML.

En segundo lugar, busca los registros de apache. La mayoría de los problemas se pueden resolver utilizando este log. La ubicación del log depende del S.O. que estés utilizando. Pero generalmente el archivo se llama Apache.log o Apache2.log

Saludos,
Chris

[rolandoj]

Empezado por Chris

Lo primero que yo haría es hacer las pruebas con el explorador Web y páginas HTML antes que con un cliente de Indy. Al hacer las pruebas así por lo menos el navegador te puede brindar más información que la brindada por Indy (que es nula realmente).

Tu aplicativo CGI está teniendo un problema. Es por eso del número 500 (código HTTP reservado para los errores). Por eso es que te digo que hagas mejor las pruebas con páginas HTML.

En segundo lugar, busca los registros de apache. La mayoría de los problemas se pueden resolver utilizando este log. La ubicación del log depende del S.O. que estés utilizando. Pero generalmente el archivo se llama Apache.log o Apache2.log

Saludos,
Chris

Hola Chris,

Muchas gracias por contestar.

Si te entiendo bien, sugieres que desarrolle un programa con páginas Web para probar el Post ?. Estás seguro que a un navegador se le envía más información respecto al error ?. Hasta donde yo sé, el procolo HTTP es un standard y por tanto la información devuelta depende solo de los datos que enviemos en una petición; debe ser la misma respuesta de errores independientemente del programa que haga la petición, siempre y cuando la cadena http sea igual.

Indy posee varios mecanismos que muestran los códigos de error devueltos; pero, en este caso, no aclaran mucho.

Por otro lado, la solución que propones implica aprender a manejar un POST en HTML, y no tenemos esa experiencia, así que estaríamos saltando a otro campo que tampoco dominamos. Es algo que intentaría solo como último recurso.

En cuanto a lo del log de errores, solo vimos el log de donde sacamos lo que mostré aquí y creo que se llama apache2.log (Mañana miro en la oficina). Será que para que muestre detalles de errores hay que activar esa característica mediante un comando o una configuración ?. Miraremos eso mañana; pero, te agradezco si puedes indicarnos algo al respecto

Ahora, la lógica del programa es demasiado sencilla. Un evento OnRequest con una sola línea del tipo :

AResponse.Content := 'algún texto';

Y funciona bien con GET. Además, el cliente está bien porque funciona con DLLs ISAPI. Hay que descartar errores de lógica en el programa o en el cliente. Tiene que ser algún parámetro, unidad o alguna otra cosa que tenga que incluirse en el aplicativo servidor y que no conocemos.

Preguntas claves :

1. Tú has hecho algún servidor CGI con TFPWebModule bajo Linux-Apache 2.2 que responda a peticiones POST ?.

2. Podrías mostrar el código de ejemplo ?

3. Alguién ha hecho un programa así ?.

Tengo una sospecha :

En Delphi, cada accion atiende en un solo evento (OnAction) cualquier tipo de petición (PUT, POST; GET) y un parámetro permite indicar el tipo de petición que puede atender. En Lazarus, aparentemente es casi igual : una acción recibe cualquier petición y la atiende en un solo evento (OnRequest) ; pero, no hay un parámetro para diferenciar el tipo de petición atendible. Será que en Lazarus las peticiones POST se reciben en otro evento, o con un mecanismo totalmente diferente ?. Alguién sabe ?

[[Chris]]

Rolando, no es necesario hacer un cliente completo en HTML. Un simple archivo HTML te puede servir. Cómo hacerlo, simplemente declara un formulario con la etiqueta form. Este formulario enviará los campos que necesites en tu respectivo Request.

Por qué te digo lo de hacerlo en HTML y no utilizar Indy? Porque el explorador te mostrará la respuesta literal del servidor, mientras los Indy no lo harán. Simplemente te devolverán el código del error -en tu caso el 500-.

No soy muy ducho en lo que respecta a la configuración de Apache. Pero creo recordar que existe un parámetro que determina el nivel de detalle de la bitácora de error. Sin embargo, hay que ser conscientes que lo que guarda en este registro, en realidad es determinado por el Script que procesa la petición. En tu caso sería la biblioteca ¿DLL? si esta biblioteca no devuelve suficiente información del error, entonces por mucho que juegues con la configuración de Apache, no tendrás mucha información para depurar.

Tengo una idea en la cabeza, discúlpame si me equivoco. Pero siento que no estás muy claro de los propósitos de cada tipo de petición y cómo se procesan, ya sea GET, POST, etc. Quisiera saber si alguna vez has programado aplicaciones web con lenguajes de Script (PHP, Perl, Python, Ruby, etc.)?

No te olvides que el error no está en el cliente, sino en la biblioteca que CGI que has realizado.

Saludos,
Chris

[rolandoj]

Hola Chris,

Gracias por la colaboración.

Ya encontramos el archivo del log de errores; pero, no ayuda mayor cosa. Lo que dice es que se trata de una terminación prematura del procesamiento del header de la petición; lo que puede ser por un monton de causas, empezando por permisos. O sea, en el fondo es lo que ya sospechabamos : Una incompatibilidad en la forma como se están procesando los campos de la petición.

Esta mañana estuvimos intentando diversas consideraciones que encontramos en Internet para la terminación prematura; pero, ningunoi funcionó.

Tienes razón en lo de que no hemos programado con lenguajes script. En mi caso particular, he programado en más de 30 lenguajes, incluyendo assembler; pero, ninguno de los tipo script. De html si trabajamos algo; pero, muy elemental. Ni siquiera recuerdo como se atrapan los resultados devueltos por el servidor. Tengo además que ver como está construyendo Indy la línea del POST porque este va acompañado de un conjunto de parámetros y eso es relevante. Si mal no recuerdo, toca depurar los fuentes Indy del cliente para ver eso. De todas formas intentaré hacer lo que me dices.

En lo que si tenemos años de experiencia es en el uso de ISAPI bajo Windows. Entre otros proyectos, tenemos actualmente desarrollada una aplicación enorme donde el servidor son DLLs ISAPI escritas con delphi 2007 y el cliente son programas Delphi que envian peticiones POST al servidor usando Indy 8. De hecho, es por eso que no me preocupo de las diferencias GET, POST y PUT. En nuestros aplicativos, todo es POST; ya que, al no ser los clientes páginas WEB, el tema me resulta transparente; absolutamente todo lo puedo hacer con POST.

Ahora, te devuelvo la pregunta, reiterando la de mi nota anterior. Tienes experiencia programando CGI con Lazarus bajo Linux y usando Apache ?

No es solo porque me llama la atención que no menciones nada especial que se requiera para procesar un POST en el CGI. Es también porque sospecho que tendremos que depurar el servidor; pero, me preocupa que, de acuerdo a lo que he leído hasta ahora, que no es muy claro, parece que aunque si hay mecanismos para depurar, no contamos con las facilidades de depuración disponibles en Delphi. Digo, en delphi, depurar un ISAPI es tan facil como depurar un programa normal; es decir, línea a línea en vivo y pudiendo inspeccionar en todo momento las variables del entorno en el que vas avanzando.

Podrías indicarnos como depurar el CGI ?

[[Chris]]

Sinceramente nunca he programado este tipo de modulos, mucho menos con Lazarus. Pero estuve revisando documentación, he encontrado esto que talvez te puede ayudar:
http://wiki.lazarus.freepascal.org/f...ing_GET_fields

http://wiki.lazarus.freepascal.org/F...Apache_Modules

Con la información encontrada en el enlace que te proporcioné, considero que un código similar a este te podría ayudar a depurar tu servidor:

Código Delphi [-]
try
    ... Acá todo el código que procesa la petición ...
except on E: Exception do
    AResponse.Content := Format('ERROR: Tipo: "%s" Mensaje: %s', [E.ClassName, E.Message]);

Por lo menos ese sería el código para Delphi. Sé que Free Pascal tiene algunas diferencias en su sintaxis con respecto a Delphi. Pero la clave está en devolver el tipo de excepción generado y el mensaje de ésta al explorador.

Nuevamente, requerirás que la petición POST se haga por medio del explorador. Hasta dónde llega mi experiencia con Indy, sé que cuando la petición genera un error (código 500), Indy descarta la respuesta, por lo que no podrás ver la información del error devuelta por el controlador que estás desarrollando.

El código para devolver información del error es simplemente lo que hacen los lenguages Script. Éstos, cuando hay un error en el código, simplemente escupen toda la información del error a la salida, en este caso la respuesta a una petición. Esto no es cierto para los lenguaje compilados, pues a como sabrás, lo típico que ellos devuelven es, por ejemplo: EAccessViolantion at address 0x000000..... Y no necesariamente a la salida.

Saludos,
Chris

[[Chris]]

Fíjate que aún me queda la duda si realmente comprendes la difencia entre POST y GET. Estaba leyendo un viejo post tuyo y no pude dejar de poner mi atención a una entrada que escribiste hace más de dos años. (http://www.clubdelphi.com/foros/show...15&postcount=7)

La siguiente petición "http://www.midominio.com/miacceso/mi...hi&CLAVE=Pedro" la consideras una petición POST, pero en realidad es una petición GET, la llames desde dónde la llames (Explorador, Indy, etc.). Sé que eso fue hace más de un dos años y talvez ya no estés confundido en este aspecto.

Pero aún así, sigo teniendo la duda -disculpame si te ofendo- sobre si tienes claro las diferencias entre POST y GET.

Empezado por rolandoj

Empezamos por desarrollar como prueba un CGI en las condiciones dadas. Nuestras primeras pruebas fueron desde navegadores Web; es decir, enviando solo comandos GET. Cuando hicimos eso, el sistema devolvió adecuadamente las respuestas.

El paso siguiente fué probar si procesaba bien comandos POST. Para ello, escribimos un programa cliente en Windows que utiliza componentes Indy. Este programa lo verificamos primero usandolo contra DLLs ISAPI de Windows escritas en Delphi 2007 con TWebModule, y funciona perfectamente. Por tanto, el cliente funciona bien.

Este es parte de tu mensaje original. Primero, no son "Comandos GET/POST", son métodos. Esto te lo digo porque uno puede confundir su propósito al llamarlos comandos.

Realmente se pueden hacer pruebas con métodos POST desde el explorador. Es sumamente sencillo. Cualquier página web que tenga formularios utiliza POST (las barras de búsqueda son una común excepción). Puedes encontrar ejemplos en cualquier formulario disponible en la Web. En los formularios veras una propiedad llamada "method", es allí dónde se indica si el método a utilizar será POST o GET. La propiedad "action" indica la URL del controlador que procesará la petición y normalmente los datos del formulario.

Me parece que tienes la idea que GET es exclusivo para los exploradores y POST para otro tipo de clientes, como los componentes Indy. Pero en realidad, ambos métodos están disponibles para todos y ambos los utilizan indistintamente dependiendo del caso.

Te comparto una experiencia. En una ocasión, en una clase de sitios dinámicos, un alumno le preguntó al profesor cuál era la diferencia de POST y GET. El profesor simplemente dijo: "Son lo mismo!" lamentablemente este alumno quedó en la ignorancia de tan importante tema. No sé si el profesor contestó esto por simplicidad o es que realmente desconocía las diferencias.

Que quede claro que no he querido aseverar que desconozcas las diferencias entre los métodos, sino que simplemente, tengo la impresión en el aire que los confundes. Discúlpame si te ofendo. Te aseguro que no es mi intención.

Saludos,
Chris