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]

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/fcl-web#Formating_the_HTML_and_Reading_GET_fields

http://wiki.lazarus.freepascal.org/FPC_and_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:
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

[rolandoj]

Hola Chris,

Muchas graciias por tú apoyo.

Honestamente, por tús respuestas, también me imaginé que no habías hecho este tipo de programación. De hecho, sospecho que casi nadie en el foro tiene experiencia en este tema y que incluso, a nivel mundial, es muy poco lo que se ha hecho.

Respecto a lo del Try except; yo tengo incluso, en mis programas Delphi, un manejo general de Try Except que me devuelve al cliente información de los errores. Es más, en realidad, con Indy estiy atrapando todos los errores detallados de mis programas en sí. Eso que dices de que los compilados no devuelven informacion, no es cierto en lo que se refiere al código generado por nosotros mismos. Otra cosa es el código de terceros que no siempre tiene buenos controles Try Except

Por ejemplo, lo del access violation depende de como esté programado el servidor. En mi caso, yo tengo un estilo de programación muy defensivo en el que usualmente estoy validando cualquier manejo de apuntadores Es muy raro que me salga un error de access violation; y cuando ocurre, usualmente es porque se generó en Delphi o en el Sistema operativo.

Además, casi siempre es muy facil hallarlo porque aparte de que mi cliente si lo atrapa, con Delphi depuro el servidor línea a línea como si fuera un programa normal; es más puedo depurar incluso entrando a los propios fuentes de Delphi. Tú observación cuando hablabas de analizar lo que devuelve el script al cliente me hizo pensar que no tenías experiencia con servidores Delphi porque si fuera con él, ya hubiese encontrado el problema y es casi siempre super facil.

El problema es que aquí el error no lo genera la lógica de mi programa. El evento OnRequest que responde a la petición es solamente esto:


Begin
AResponse.Content := 'Hola';
End;


No tiene sentido ponerle ahí un try except porque obviamente esa línea está bien.

Por eso te digo que el problema es alguna incompatibilidad entre la información interna del POST que manda Indy y lo que procesa el CGI. Si pudieramos depurarlo como con delphi, el problema estaría resuelto. La pregunta es como depuro ?. Será que alguién sabe ?

Bueno, de todas formas vamos a intentar lo del HTML

[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

[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/showpost.php?p=333915&postcount=7)

La siguiente petición "http://www.midominio.com/miacceso/miservidor.dll?USUARIO=Delphi&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.
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 (http://es.wikipedia.org/wiki/Hypertext_Transfer_Protocol#M.C3.A9todos_de_petici.C3.B3n). 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

[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 (http://www.midominio.com/miacceso/miservidor.dll?USUARIO=Delphi&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.

De hecho, esa diferencia de manejo es lo que te hace decir que la línea "http://www.midominio.com/miacceso/miservidor.dll?USUARIO=Delphi&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

[rolandoj]

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
Hola Chris,

Nosotros compramos en su momento Delphi 2009; pero, después de dos meses lo desechamos, principalmente porque interpreta la palabra String como una cadena UNICODE (sin hablar de otro montón de problemas). Eso genera graves conflictos con el software existente de versiones previas .

Actualmente, uso Delphi 4 (Si, Delphi 4, el de fines del siglo pasado) con Indy 8 para el cliente y Delphi 2007 para el servidor. Delphi 4, sigue siendo lo mejor para nuestras aplicaciones, que tienen un enfoque empresarial. Delphi 2007 lo usamos porque al suspenderse todo soporte de BDE tocaba usar otro mecanismo de conexión a la Base de Datos y dbExpress es el más versatil disponible. El IDE de 2007, comparado con los IDE clásicos de Delphi, retrasa el desarrollo normal; así que optamos por seguir usando Delphi 4 para el cliente

No es que este 100% satisfecho con dbExpress. Nos tocó perder bastante tiempo aprendiendole las caídas y desarrollando correcciones a ciertos problemas; pero, en general, hace mucho tiempo que lo estabilizamos y nuestros sistemas trabajan bien.

Bueno, perdón, me extendí demasiado y eso es tema de otro hilo