[[Al González]]

¡Hola a todos!

Gracias por esa herramienta Domingo. Será muy interesante echarle un vistazo.

Actualizo el caso:

--------------------------------------------------------------------------
Prueba del componente TIdHTTP
Informe #1

Cargué en un navegador la página dada por la URL https://login.yahoo.com/config/mail?.intl=us, la cual es el punto de entrada al correo electrónico de Yahoo para cuentas de Estados Unidos. Esta página solicita los típicos nombre de usuario y contraseña de cualquier sistema de correo. Tomé su código fuente HTML guardándolo localmente como CorreoYahoo.htm. Al explorar su contenido con el bloc de notas, encontré que, como habría de esperarse, el método de envío de datos que utiliza es el Post:

<form method="post"...

Como ya sabemos, cuando el método es Get, los datos de captura son enviados al servidor Web como parte de la cadena URL; mientras que con el método Post, los datos son enviados de forma interna o “no visible”.

Me despertó curiosidad el saber cómo se comportaría la página y el servidor de Yahoo, si cambiara la palabra post por get. Lo hice y guardé el archivo como CorreoYahooGet.htm. Al ejecutar esa página Web, capturando la clave de usuario y contraseña que solicita, vi como estos dos datos aparecieron, junto con otros valores, en la barra de direcciones del navegador (como parámetros en la URL), lo cual era de esperarse. Lo interesante fue ver que el sistema de corro de Yahoo permitió el ingreso, a pesar de haber enviado los datos de esta manera.

Me llamó la atención otro detalle de la línea

<form method="post" action="https://login.yahoo.com/config/login?"

Entiendo que el atributo Action de la etiqueta Form indica la URL que el sistema deberá ejecutar al someter (submit) los datos, y que el signo de interrogación (“?”) se utiliza para dar inicio a los parámetros enviados en la misma URL cuando se utiliza el método Get. Mi pregunta entonces es ¿por qué aparece ahí el signo de interrogación si el método que utiliza la página es Post y no Get?

Sobre el útilmente sobrecargado método TIdHTTP.Post, la documentación dice algo que me pareció lógico y a la vez interesante:

When ASource is a TStrings instance, Post will replace all occurrences of
the End-Of-Line (EOL) character in ASource with the value '&' prior to
transfer to the HTTP server. When ASource is a TStream instance, no
preprocessing of the stream content is performed.

El símbolo ampersand (“&”) se utiliza para separar los parámetros entre sí en la URL cuando se utiliza el método Get. Es útil que cuando los parámetros son proporcionados como una lista TStrings, el método Post haga la sustitución de saltos de línea por dicho símbolo. Cuando los parámetros son indicados mediante un flujo TStream, éste es tomado tal cual esté, por lo que deberá contener ya los separadores & que sean necesarios.

De ahí que Tefots, incluya tales símbolos en el ejemplo que tan amablemente nos proporciona en el mensaje 12. Pero coincido con Román en que resulta más práctico usar una lista TStrings (el método TIdHTTP.Post también acepta ese formato). Por cierto, recuerdo haber visto un par de muy acertadas intervenciones de Román en este hilo, pero ya no están aquí. ¿Alguna razón especial por la que hayan desaparecido?

El siguiente es el código fuente de la prueba inicial:

Código Delphi [-]
procedure TForm1.Button1Click(Sender: TObject);
Var
  Parametros :TStringList;
begin
  Parametros := TStringList.Create;

  Try
    Parametros.Add ('login=debefuncionar');
    Parametros.Add ('passwd=xxxxxxxxxxxxx');

    Try
      Memo1.Text := IdHTTP1.Post ('https://login.yahoo.com/config/login?',
        Parametros);
    Except
      On E :Exception Do
        ShowMessage (E.Message);
    End;
  Finally
    Parametros.Free;
  End;
end;

La llamada al método IdHTTP1.Post me arroja una excepción EIdIOHandlerPropInvalid con el mensaje «IOHandler value is not valid».

Debe considerarse lo siguiente:

La URL comienza con https y no http. Cuando el protocolo es HTTPS, el componente TIdHTTP exige el uso de un componente adicional TIdSSLIOHandlerSocket asignado a su propiedad IOHandler, como puede observarse en este extracto del código de IDHTTP.pas (Delphi 7):

Código Delphi [-]
if AnsiSameText(URL.Protocol, 'HTTPS') then
begin
  // Just check can we do SSL
  if not Assigned(IOHandler) or (not (IOHandler is TIdSSLIOHandlerSocket)) then
    raise EIdIOHandlerPropInvalid.Create(RSIOHandlerPropInvalid)

Esto es algo importante a considerar, ahora que suelen verse en la Red muchos sitios que son «https://…».

Para cumplir con este requisito, hago uso de un componente TIdSSLIOHandlerSocket. Aún cuando los sitios a los que deseo acceder después de este aprendizaje sean de protocolo HTTP y no HTTPS, me interesa lograr hacer pruebas exitosas con HTTPS también. Aclaro que la excepción elevada que menciono ocurre por otras causas.

Depurando paso a paso el código de las unidades involucradas (con la opción Use Debug DCUs, que permite que uno pueda meterse hasta la cocina), encontré que la causa de este error se origina en el hecho de que la función Load de la unidad IdSSLOpenSSLHeaders.pas no logra cargar correctamente algunas DLLs.

Según este enlace de Borland:
http://support.borland.com/entry.jsp...externalID=406, se requiere un software llamado OpenSSL, específicamente los archivos libeay32.dll y ssleay32.dll para poder usar los componentes Indy con SSL (Secure Socket Layer), que es la especificación utilizada por una página HTTPS.

El sitio oficial de OpenSSL es http://www.openssl.org/, sin embargo no encontré en él un instalador que proporcione de manera fácil las dos DLLs que necesito. Así que descargué OpenSSL 0.9.8d para Win32 del sitio http://www.slproweb.com/products/Win32OpenSSL.html y lo instalé.

Pero aún así la excepción mencionada sigue apareciendo al intentar hacer la llamada al método Post. Haciendo un examen más minucioso de la citada función Load, descubrí que las DLLs sí logran cargarse, más no las funciones IdSslCtxSetInfoCallback, IdSslX509StoreCtxGetAppData, IdSslSessionGetId, IdSslSessionGetIdCtx, IdSslCtxGetVersion, IdSslCtxSetOptions, IdSslX509GetNotBefore, IdSslX509GetNotAfter, iddes_set_odd_parity, iddes_set_key e iddes_ecb_encrypt, que probablemente pertenecen a esas DLLs.

Ante esto, sospecho que debo utilizar otra versión de OpenSSL (no la 0.9.8d) para conseguir que tales funciones se carguen correctamente y con ello poder utilizar el componente TIdHTTP con sitios que utilizan Secure Socket Layer (HTTPS).
--------------------------------------------------------------------------

Les agradezo de antemano su ayuda.

Un abrazo neófito.

Al González.