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

[[Chris]]

Bueno, lo del EAccessViolation era solo un ejemplo. No quise decir que ese era el problema que tenía tu controlador. En el mismo sentido, cuando te digo que los compilados no devuelven mucha información de una excepción, lo mantengo. Talvez no me dí a entender bien. Lo que quería decir es que, al natural y silvestre no te la dan, a menos claro, que escribas un controlador para la excepción y tú manualmente brindes esa información a la salida.

Por otro lado, yo primero auditaría el código de TFPWebModule. Puede ser, que inclusive esté generando un EAccessViolation, aunque solo tengas una línea de código. Esa línea de código que has puesto puede generar excepciones y es necesario que las manejes con Try/Except. ¿En que casos puede generar una excepción? En el caso que la propiedad Content no sea construida cuando la petición es llamada por POST (por un bug de los componentes). Es por esa razón te sugiero que primero auditorices el código de TFPWebModule antes que el del cliente. Y además encierres, inclusive esa línea dentro de un Try/Except. Moraleja: Nunca des nada por sentado!

Saludos,
Chris

[rolandoj]

Hola Chris,

Ok. Tienes razón en que la línea podría estar arrojando un access violation.

Quizás no me expliqué bien. Content es una propiedad y por tanto, por debajo puede tener código que arroje errores; pero, la línea, a nivel de mi programa está bien. Otra cosa es que a nivel de fpweb se manifieste un error en ese punto; eso es a lo que siempre me he referido :

Al usar POST en Lazarus, hay algo diferente que debo hacer, sea que hay que inicializar una variable, que el fpweb tenga un error, o hay que llamar un método, o que el POST debe incluir un parámetro distinto, cualquier cosa.

El problema es que es el error lo arroja es el fpweb, no mi código. Hay tres soluciones :

1. Encontrar alguna documentación que diga como usar POST
2. Que alguién nos informe al respecto
3. En últimas tocaría depurar para ver donde se produce; pero, como depurar ?

Por el momento, lo que estoy haciendo es revisar el código fuente de fpweb. Por ejemplo, y para seguir tu planteamiento, revisé la propiedad Content de TResponse. Esa propiedad en últimas guarda el valor en la propiedad Contents que es una lista de strings, así que efectivamente en teoría podría generar un access violation; pero, la lista está correctamente inicializada en el Create del TResponse, así que el problema no es por ahí, a menos que otra rutina lo coloque en Nil; pero, seguiría siendo un problema de fpweb.

Como sea, eso es dar palos de ciego.

Respecto a la diferencia entre GET y POST, y la teoría que indicas, no, no me molesto por eso. Lo que pasa es que para el tipo de programación que yo uso es un tema que no tiene ninguna importancia; eso es relevante en otro tipo de entornos.

En mi caso, el análisis de diferencias lo hice cuando estaba empezando y resultó que el POST me sirve de manera totalmente genérica. Como te expliqué, llevo años desarrollando aplicaciones enormes y nunca he necesitado nada diferente a esa llamada de POST. Entiendo que te suene raro porque tú lo manejas en un entorno en que si te es relevante; pero, para mi no lo es. El que me sirve es POST y para efectos prácticos los demás es como si no existieran. Ahí si tendría que explicarte más como trabaja la programación que hago.

De hecho, esa diferencia de manejo es lo que te hace decir que la línea http://www.midominio.com/miacceso/mi...hi&CLAVE=Pedro que ponía en mi ejemplo es un GET. Verás, cuando lo hago desde Indy, ese es el parámetro principal que se pasa al método POST que aplico en Indy; pero, también podría pasarselo a un método GET. El que al servidor le llegue un POST o un GET depende es del método que yo llame en Indy. Cada método, por debajo, lo que construye es cadena http, prefijada por POST o GET, según el caso, e incluye ese parámetro que es el que realmente manejamos usualmente en el programa, más otros muchos que se construyen automáticamente por Indy, más uno que otro que yo defino globalmnte. Como en mi caso manejo solo POST, lo que afirmé en aquel hilo es correcto, dentro de su contexto.

Sería tema de otro hilo. Si quieres, hago una explicación detallada; pero, dejame que supere este y otros inconvenientes (como el caso de los componentes Zeos que tampoco me están trabajando) porque me es prioritario poner a funcionar mis aplicativos bajo Linux.

Mañana probaremos los del HTML

[[Chris]]

Entiendo tu punto. Quisiera saber (con código) un ejemplo de cómo lees los parámetros y valores que le son pasados a tu controlador por el cliente.

Empezado por rolandoj

De hecho, esa diferencia de manejo es lo que te hace decir que la línea "http://www.midominio.com/miacceso/mi...hi&CLAVE=Pedro" que ponía en mi ejemplo es un GET. Verás, cuando lo hago desde Indy, ese es el parámetro principal que se pasa al método POST que aplico en Indy; pero, también podría pasarselo a un método GET. El que al servidor le llegue un POST o un GET depende es del método que yo llame en Indy. Cada método, por debajo, lo que construye es cadena http, prefijada por POST o GET, según el caso, e incluye ese parámetro que es el que realmente manejamos usualmente en el programa, más otros muchos que se construyen automáticamente por Indy, más uno que otro que yo defino globalmnte. Como en mi caso manejo solo POST, lo que afirmé en aquel hilo es correcto, dentro de su contexto.

No es correcto! lo que pasa es que estás manejando mal el método. No es que quiera ser yo un puritano del manejo del protocolo. Sino que estás mal utilizandolo. Primero, Indy no contruye una cadena HTTP dependiendo del método que utilices. De hecho, Indy en ningún caso modifica la petición URL. Eso lo haces tú utilizando Format por ejemplo.

En todo caso, a pesar de que tengas varios años de experiencia, deberías de profundizar más al respecto en la diferencia de estos métodos. Talvez es el mal manejo que le has dado es el origen de tus problemas e incompatibilidades.

Saludos,
Chris

[rolandoj]

Hola Chris (y cualquiera quew haya estado leyendo este hilo),

Bueno, ya encontramos el problema.

Se trata de un limitante, con sabor a error, de FPWeb con CGI. Resulta que solo está soportando dos valores en el campo ContentType. Muy raro; incluso text/html no es uno de ellos !!.

Como tengo otras prioridades, no he investigado la razón de esto; ni siquiera he probado para ver si se extiende a otras situaciones.

Lo que hicimos fué cambiar el ContentType enviando APPLICATION/FORM-DATA, y ya trabajó bien.

Vale aclarar que CGI no es la tecnología que queremos aplicar, realmente pensamos en módulos Apache; pero, hemos probado primero con CGI porque, aparentemente, era más facil de configurar, y el trabajo con TFPWebModule se supone que es el mismo.

El error lo encontramos sin hacer la prueba en HTML. No fué necesario porque pensé que si con navegadores Web despliega una página de errores HTML, ella debía venir en alguno de los parámetros Indy. Efectivamente, así es. Pudimos desplegar la página directamente con los Indy, sin recurrir a HTML. De todas formas, eso no ayudó porque muestra la misma información que ya teníamos.

Lo que hicimos fué una depuración manual sobre el CGI porque aún no sabemos bien como usar las herramientas que están disponibles para Lazarus; pero, nuestro método funcionó rápido.

Chris, te agradezco el interés, y en cuanto a darte ejemplos de mi metodología, lo haré en otro hilo; me parece que es necesario porque tú vienes de un entorno completamente distinto y no entiendes bien como funciona el asunto aquí. Lo visualizas de una manera teórica muy purista asimilandolo a lo que manejas, y las cosas aquí son muy distintas. Una cosa es que no les dé el uso "normal", y otra cosa es que lo esté usando mal. Yo me atengo a la especificación http; solo empleo lo que está disponible y eso de ninguna forma puede considerarse un mal uso. Creo que el Domingo tendré tiempo. Por ahora, voy a lidiar con el problema de los ZeosDB

[[Chris]]

Me alegro que lo hayas podido solucionar Rolando!

Pero quisiera que me compartieras cómo haces para que Indy te despliegue información del error que ha ocurrido en el servidor. Es que cuando a mí me sucede, tengo que recurrir a pruebas con HTML para que el explorador si me brinde la información del error enviada por el servidor.

Saludos,
Chris

[rolandoj]

Hola Chris,

Pués se devuelve en el mismo parámetro del resultado normal; o sea, en la propiedad DataString del parámetro Response. Lo que pasa es que, por el control de errores en Delphi, cuando este se produce, yo estaba manejando los códigos de error devueltos, que son los mensajes de error asociados, e ignoraba el DataString porque ese el que te devuelve el resultado normal, así que deberìa venir vacío; y como no uso HTML no había analizado lo de las páginas de error.

Cuando tú planteaste la idea, analicé que en algún lado tenía que devolverse la página HTML y era lógico que Indy la recibiera en algún parámetro; así que revisé los valores devueltos y están usando DataString para devolver la página HTML de error.

Moraleja: En todas partes se cuecen habas. Aquí también hay falta de puritanismo porque están usando una misma propiedad para dos propósitos distintos.

Ahora, como te dije, la información es la misma que obtengo de los códigos de error. La única diferencia es que en Datastring llega formateada en una página HTML con presentación más agradable a un usuario final.

Saludos

[[Chris]]

Tienes suerte amigo! porque en mi caso, utilizando la versión de Indy incluida con D2009, el parámetro que mencionas me aparece vacío cuando el resultado es distinto a 20(x). Es por eso, que cuando necesito depurar mi servidor de aplicaciones, en ocasiones tengo que recurrir a hacer pruebas con el explorador.

Quién sabe, tendré que indagar más en el tema. Igual no tengo conocimientos profundos de Indy porque relativamente desde hace poco los utilizo.

Saludos,
Chris