Aplicaciones Apache-PHP

Dirección General Corporativa 26/11/13 REVISADO: Director General Corporativo (PO) APROBADO: Presidente (PO) Director General Corporativo (POG) Director de Expansión y Procesos Corporativos (POG) Director de la Dirección Organizativa FECHA: 11, 2013 FECHA: mes, año Paseo de La Habana, 138 28036 Madrid. España Tel.: +34 91 452 12 00 Fax: +34 91 452 13 00 www.ineco.es

ÍNDICE 1 OBJETO... 4 2 ALCANCE... 4 3 ESPECIFICACIONES TÉCNICAS... 4 3.1 Datos Técnicos... 4 3.1.1 Entorno... 4 3.2 Buenas Prácticas... 5 3.3 Elementos de Configuración... 5 3.3.1 Archivo de Configuración... 5 3.4 Seguridad... 6 3.5 Acceso a la Base de Datos...7 3.6 Gestión de Trazas...7 3.7 Servicio de Mail... 8 3.8 Almacenamiento... 8 4 DIAGRAMA... 8 4.1 Estructura en Alta Disponibilidad... 8 5 SOLICITUD DE NUEVA APLICACIÓN... 9 6 DESPLIEGUE Y ACTUALIZACIONES...10 6.1 Servidor de Aplicaciones... 10 6.2 Base de Datos... 12 6.3 Ciclo de Vida... 13 6.4 Horarios... 13 7 MONITORIZACIÓN... 13 8 ANEJOS... 13 8.1 Anejo 1: Reseña de modificaciones... 14 8.2 Anejo 2: Ejemplos de codificación... 14 8.2.1 Configuración...14 2 26/11/13

8.2.2 Conexión a base de datos...15 8.2.3 Directorios y archivos de registros...16 8.2.4 Envío de correos...16 8.2.5 Monitorización...17 3 26/11/13

1 OBJETO Este documento sólo es aplicable en aplicaciones Web desarrolladas que tienen como fin ser desplegadas en un servidor de aplicaciones Apache-PHP corporativo. Se contempla la posibilidad de acceder a bases de datos de MySQL o Microsoft SQL Server. Se ha de tener en cuenta que aquellas aplicaciones que hagan uso de librerías no estándar o recursos hardware especiales, deberán ser estudiadas por el Área de Sistemas y Comunicaciones de la Subdirección de Desarrollo y Sistemas Corporativos y que pertenece a la Dirección de Expansión y Procesos Corporativos dentro de la Dirección General Corporativa, para evitar posibles incompatibilidades o errores inesperados. 2 ALCANCE Aplica a todas las aplicaciones desarrolladas en php que se desplieguen en los servidores corporativos de Ineco. 3 ESPECIFICACIONES TÉCNICAS 3.1 DATOS TÉCNICOS 3.1.1 ENTORNO Las especificaciones técnicas de las versiones de los distintos entornos corporativos son las siguientes: Sistema Operativo: Versión de Apache: Linux 2.6.32 64-bits Apache/2.2.3 Versión de Php: 5.3.3 Versión del Conector de MySQL: 5.0.77 Versión del Conector de MS-SQL: FreeTDS 0.82 MS-SQL Server 2008 SP2 MySQL 5.1.37 4 26/11/13

3.2 BUENAS PRÁCTICAS A la hora de desplegar código dentro de la infraestructura de Ineco, se asume una concienciación del desarrollo en base a unas buenas prácticas en distintos aspectos. El registro de variables globales, es decir, aquellas variables externas que vienen del entorno, o vía GET, POST, Cookie y Server, queda desactivado a través de la directiva de configuración (php.ini) register_globals, ya que de esta forma los contextos de las diferentes aplicaciones de un mismo servidor mantienen su propio ámbito para sus variables de forma independiente, e impediría a un supuesto atacante que inyecte sus propias variables con alcance global. Estos valores no son ya accesibles para el script como lo son las variables internas, sino como valores de array, lo que obliga a chequear mínimamente su origen, filtrando los datos enviados al script desde fuera, y así tener clasificadas estas variables externas atendiendo a su origen (get, post, cookie, etc). Cambiar el valor de la directiva register_globals es posible dinámicamente con la función init_set(), pero no sirve de nada, ya que la directiva incluida en php.ini es la que se aplica al tiempo de ejecución del script. En caso de detectar que algún aplicativo haga uso de fuentes externas a los scripts directamente, se solicitará a los responsables su eliminación o transformación al empleo de $_GET o $_POST, según el sistema previsto de envío, cómo método de acceso. El uso de etiquetas cortas <??> no está permitido, y es necesario hacer uso de su versión larga, es decir <?php?>. También hay que tener en mente ciertos aspectos de seguridad básicos, recogidos en el punto 3.4, en los diseños de desarrollo. Dependiendo de cada uno de los parámetros que se necesiten, deberán ser introducidos tal y como se indican los puntos siguientes, y cualquier otro parámetro que no esté recogido en este documento y que necesite la aplicación, deberá ser igualmente introducido como un parámetro de configuración. 3.3 ELEMENTOS DE CONFIGURACIÓN 3.3.1 ARCHIVO DE CONFIGURACIÓN Todos los parámetros que puedan ser configurables en la aplicación deben encontrase en el archivo de configuración de la aplicación. Este archivo se encuentra en la siguiente ruta y su nombre debe ser config.php: /var/www/<nombreaplicacion>/config.php En este fichero es obligatorio recoger todos parámetros que sean referenciados en el aplicativo y que sean dependientes del entorno: El nombre de aplicativo y el directorio de despliegue no son obligatorios, sólo en caso de que se hagan referencia dentro del código. 5 26/11/13

La cadena de conexión a base de datos sólo es obligatoria en caso de que se use un esquema de datos. El directorio de datos es obligatorio en caso de que la aplicación use contenido que no esté en base de datos, ni sea ejecutable. Este directorio tendrá permisos de escritura, alta disponibilidad, backup y optimización de rendimiento. El archivo de registro o log no es obligatorio, pero es aconsejable. 3.3.1.1 Directorio raíz Es el directorio base donde cuelgan todos los scripts php relacionados con un aplicativo concreto y donde se dan los permisos sólo de lectura y ejecución. En este nivel es donde debe estar el fichero de configuración config.php del aplicativo. Si es necesario realizar alguna escritura en disco, no hay que hacerlo directamente en este directorio, sino en el siguiente, el directorio de datos, que es el directorio con permisos de escritura 3.3.1.2 Archivo de registros Es recomendable que un aplicativo haga uso de un archivo de registros o log, aparte de los configurados por defecto a nivel de servidor apache-php (accesos/errores). Si se solicitara acceso a los logs, nosotros los publicaríamos vía HTTP. 3.4 SEGURIDAD Los servidores están configurados teniendo en cuenta ciertos aspectos de seguridad, que deberían ser transparentes, pero aún así es posible que parte de la funcionalidad se vea afectada, ya que algunas funciones están deshabilitadas, en ese caso se habilitarían. La lista de funciones deshabilitadas es la siguiente: apache_child_terminate, apache_setenv, define_syslog_variables, escapeshellarg, escapeshellcmd, eval, exec, fp, fput, ftp_connect, ftp_exec, ftp_get, ftp_login, ftp_nb_fput, ftp_put, ftp_raw, ftp_rawlist, highlight_file, ini_alter, ini_get_all, ini_restore, inject_code, mysql_pconnect, openlog, passthru, php_uname, phpads_remoteinfo, phpads_xmlrpc, phpads_xmlrpcdecode, phpads_xmlrpcencode, popen, posix_getpwuid, posix_kill, posix_mkfifo, posix_setpgid, posix_setsid, posix_setuid, posix_setuid, posix_uname, proc_close, proc_get_status, proc_nice, proc_open, proc_terminate, shell_exec, show_source, syslog, system, xmlrpc_entity_decode. El intérprete php está limitado para lectura/escritura en el directorio de datos, y de lectura en el directorio de despliegue. En el primero es donde se ubican los datos del aplicativo y el segundo es donde se ubican los scripts php, por lo que no es necesario escribir dentro del directorio de despliegues. Es recomendable conocer los posibles fallos de seguridad y vulnerabilidades de un aplicativo php, publicados en el Php Security Consortium: http://phpsec.org/projects/guide/ 6 26/11/13

3.5 ACCESO A LA BASE DE DATOS Las aplicaciones desplegadas en los distintos entornos podrán acceder a bases de datos alojadas en nuestros servidores corporativos. Los motores de bases de datos que se encuentran disponibles para estos esquemas son MySQL 5 y Microsoft SQL Server 2008. Para que las aplicaciones puedan acceder a sus tablas, se configurará en el archivo de configuración de cada aplicación un recurso de acceso a estas bases de datos. Ejemplo:... static $dbtype = 'mysql'; static $dbhost = 'mysqlhost:3306'; static $dbname = 'testdb'; static $dbuser = 'usr_testdb'; static $dbpass = 'xxxxxx'; static $dbprefix = ''; static $dbpersist = false; static $dblibrary = 'native'; static $appname... = 'TestDB'; Nombre de la aplicación: TestDB Tipo de Base de datos: Mysql Nombre del servidor de la base de datos: MysqlHost Para consultar ejemplos de conexión a base de datos, ir al punt0 8.2.2 dentro del anejo 2. 3.6 GESTIÓN DE TRAZAS Las aplicaciones desplegadas en estos entornos dispondrán de una gestión de trazas agrupada por aplicación, donde se redirigirá tanto los posibles mensajes de error y acceso, como todas las trazas capturadas por el código a un archivo o archivos dentro de un único directorio específico por cada aplicación. En dicho directorio se creará un archivo <nombre-aplicación>.log, así como cada uno de los.log de las trazas que se gestionen internamente en cada aplicación. Este directorio será exportado para que pueda ser consultado por cada grupo responsable de la aplicación. La ruta de acceso a los logs será según el nodo: http://<dominio>/logs1 y http://<dominio>/logs2 Por tanto, en cada aplicación se deberán configurar correctamente las salidas de los Loggers internos para que utilicen este único directorio, definido en la configuración como ruta base a través del parámetro logroot : $log = config::$logroot. '<NombreAplicacion>.log'; 7 26/11/13

Para consultar ejemplos de configuración de directorios y archivos de registro, ir al punt0 8.2.3 dentro del anejo 2. 3.7 SERVICIO DE MAIL Las aplicaciones desplegadas en estos entornos en caso de implementar funcionalidades de envío de correo electrónico deberán hacerlo con autenticación. Todas aquellas aplicaciones que soporten el envío de emails y no lo implementen con autenticación no funcionarán correctamente, ya que se rechazarán todas las peticiones de envío que realicen. Para la correcta autenticación se deberá utilizar un usuario, password y servidor que vendrán definidos de forma específica para cada aplicación a través de parámetros de configuración. Para consultar ejemplos de envío de correos, ir al punt0 8.2.4 dentro del anejo 2. 3.8 ALMACENAMIENTO Es muy importante indicar este parámetro dataroot en caso de necesitar la aplicación generar o acceder a algún dato externo del propio aplicativo, ya que no se tendrá permisos de escritura más que a este directorio. Cualquier aplicativo que intente crear archivos en el propio directorio donde sea desplegado generará errores, pues sólo se tendrá permisos de lectura en dichos directorios. Para consultar ejemplos de configuración de directorios y archivos de registro, ir al punt0 8.2.3 dentro del anejo 2. 4 DIAGRAMA En este punto se presenta el diagrama de arquitectura con los distintos entornos donde se desplegarán las aplicaciones apache-php. 4.1 ESTRUCTURA EN ALTA DISPONIBILIDAD Las aplicaciones desplegadas en estos entornos dispondrán de alta disponibilidad siempre que la aplicación lo permita. Para que las aplicaciones puedan ser desplegadas en alta disponibilidad estas deberán tener en cuenta: Es posible la pérdida de sesión por la caída de alguno de los nodos. Los directorios de datos de las aplicaciones deben ser configurables para ser introducidos en directorios compartidos por los servidores. 8 26/11/13

Las rutas de los enlaces han de ser relativas y obtener la información del nombre del dominio y el puerto por el que se encuentra escuchando el servicio preguntando al servidor de aplicaciones. La aplicación puede ser ejecutada en cualquiera de los nodos de los que compone el clúster. El esquema muestra cuatro entornos, dos en la red de ineco y dos accesibles desde internet, con producción y preproducción en cada uno de ellos. 5 SOLICITUD DE NUEVA APLICACIÓN Para solicitar el alojamiento de una aplicación dentro de los servidores apache-php de Ineco se ha de enviar un Formulario de Servicio de Red, que se puede encontrar en la inet en el apartado Personal > Servicios > Formularios, al Área de Sistemas y Comunicaciones, de la Subdirección de Desarrollo y Sistemas Corporativos y que pertenece a la Dirección de Expansión y Procesos Corporativos dentro de la Dirección General Corporativa. En él se ha de indicar la siguiente información: Nombre de la aplicación. Si necesita acceso externo. Nombre del dominio que se desea. 9 26/11/13

Necesidad de certificado o no. Información necesaria para poder verificar que la aplicación está funcionando correctamente. Manual de instalación. En caso de requerir notificación de fallo en tiempo real cumplimentar el webtest.php y facilitar las personas que deban ser notificadas. 6 DESPLIEGUE Y ACTUALIZACIONES 6.1 SERVIDOR DE APLICACIONES El despliegue de una nueva aplicación se hará siguiendo los pasos indicados en el apartado anterior y para siguientes entregas mediante un mail a la dirección Plataforma.Sistemas@ineco.es. El proceso de despliegue o actualización de la aplicación se describe en los puntos los siguientes: El equipo de desarrollo una vez tenga preparado el código de la entrega, lo ubicará en un directorio de su equipo local que se compartirá (por samba o CIFs) dando permisos de lectura y escritura al usuario servicios.aplic. En él deberán estar los scripts que serán desplegados en el servidor de aplicaciones, por ejemplo en un directorio llamado despliegues_<nombreaplicación> donde quedaría el contenido del aplicativo. Para dar los permisos a la carpeta despliegues_<nombreaplicación>: botón derecho compartir y seguridad compartir esta carpeta, indicando en recurso compartido el nombre elegido, despliegues_<nombreaplicación>. Luego en permisos, quitar Todos y agregar al usuario servicios.aplic, pinchar en comprobar nombres y aceptar, dándole los permisos de leer, cambiar y control total. A continuación en la pestaña de seguridad se vuelve a agregar al usuario servicios.aplic y se le da los tres permisos de leer, modificar y control total y se acepta. Por último en seguridad opciones avanzadas activar: Reemplazar las entradas de permisos en todos los objetos secundarios con aquellas entradas incluidas aquí y que sean relativas a los objetos secundarios. Enviar una solicitud al equipo de sistemas y comunicaciones (Plataforma.Sistemas@ineco.es), que contenga la siguiente información: Nombre de la aplicación. 10 26/11/13

Dirección compartida por red (ejemplo: \\X081204899.ineco.es\despliegues_<NombreAplicación>). Información necesaria para poder verificar que la aplicación está funcionando correctamente. El equipo de sistemas y comunicaciones realizará remotamente el commit, garantizando que sólo se suben al svn aquellos archivos que hayan cambiado, se hayan añadido o se hayan eliminado, optimizando así sobre todo los casos de re-entregas masivas de ficheros sin cambios. Una vez realizado el commit se desplegará la aplicación, contestaremos al mail indicando el número de revisión generado, y se verificará con ayuda del equipo de desarrollo el correcto funcionamiento. El despliegue del aplicativo en el servidor se realizará evitando, en la medida de lo posible, la parada del servicio. Este despliegue consta de los siguientes pasos: Si no hay modificaciones en Base de Datos: - Se dejará de dar servicio desde la máquina 1 del clúster. - Se desplegará la aplicación sobre la máquina 1. - Se verificará que la aplicación funciona correctamente, con la colaboración por el equipo de desarrollo y de los usuarios funcionales de la aplicación, en la máquina 1. - Se parará la aplicación en la máquina 2 del clúster. - Se activará la máquina 1 donde se encuentra desplegada la nueva versión de la aplicación. - Se desplegará la aplicación sobre la máquina 2. - Se verificará que la aplicación funciona correctamente, con la colaboración por el equipo de desarrollo y de los usuarios funcionales de la aplicación, en la máquina 2. - Se activará la máquina 2 donde se encuentra desplegada la nueva versión de la aplicación. Si hay modificaciones en Base de Datos: - Se parará la aplicación en todas las máquinas del clúster. - Se ejecutará el script de modificación de la base de datos. 11 26/11/13

- Se desplegará la aplicación sobre la máquina 1. - Se verificará que la aplicación funciona correctamente, con la colaboración por el equipo de desarrollo y de los usuarios funcionales de la aplicación, en el máquina 1. - Se activará la máquina 1 donde se encuentra desplegada la nueva versión de la aplicación. - Se desplegará la aplicación sobre la máquina 2. - Se verificará que la aplicación funciona correctamente, con la colaboración por el equipo de desarrollo y de los usuarios funcionales de la aplicación, en la máquina 2. - Se activará la máquina 2 donde se encuentra desplegada la nueva versión de la aplicación. Tras haber verificado el correcto funcionamiento se podrá hacer una nueva solicitud al equipo de sistemas y comunicaciones (Plataforma.Sistemas@ineco.es), que contenga la siguiente información: Nombre de la aplicación. Revisión de la aplicación. Servidor al que desplegar. En posteriores entregas se eliminaría todo el contenido del directorio local despliegues_<nombreaplicación>, se copiaría el nuevo proyecto y se volvería a seguir el procedimiento anterior. 6.2 BASE DE DATOS Para el despliegue o modificación de la base de datos es necesario que el equipo de desarrollo proporcione al equipo de sistemas la siguiente información: Nombre de la base de datos y entorno. Script de creación o modificación de la base de datos. Script de vuelta atrás para revertir el cambio en caso de que se desee volver a la situación anterior. 12 26/11/13

6.3 CICLO DE VIDA Todas las aplicaciones para su utilización dentro de esta plataforma, primero serán desplegadas sobre el entorno de preproducción donde se harán todas las pruebas pertinentes para comprobar que todo funciona de forma correcta. Una vez verificado todo será desplegado en el entorno de Producción. 6.4 HORARIOS Las nuevas versiones de las aplicaciones se subirán de 7-9 de la mañana y deberán haber sido probadas correctamente en el entorno de preproducción. El equipo de sistemas debe recibir la confirmación de que todo funciona correctamente en el entorno de preproducción, al menos 24 horas antes de poder ser subida a producción. 7 MONITORIZACIÓN Los servidores de aplicaciones se encuentran monitorizados y se envían avisos por mail pertinentes en caso de error. En caso de desear que se monitorice una aplicación en concreto es necesario que se proporcione una URL que verifique la aplicación y en caso de error devuelva un código de respuesta HTTP diferente al 200. Dicha URL básicamente será la llamada a un php: http://<dominio>/webtest.php que permite verificar el correcto acceso a todos los recursos de la aplicación, como el directorio de datos, la base de datos y a posibles accesos web. También es necesario que se proporcionen las direcciones de correo de las personas que han de ser avisadas en caso de producirse alguna incidencia en el servicio. El servicio de monitorización está activo las 24h del día pero entra en modo mantenimiento de 2h a 6h de la madrugada, de forma que durante este periodo no se podrán notificar posibles caídas. Para consultar ejemplos de configuración de directorios y archivos de registro, ir al punt0 8.2.5 dentro del anejo 2. 8 ANEJOS Anejo 1: Anejo 2: Reseña de modificaciones. Ejemplos de codificación. 13 26/11/13

8.1 ANEJO 1: RESEÑA DE MODIFICACIONES EDICIÓN DEL SERVICIO MODIFICACIONES Nº Fecha 01 26/11/13 Edición inicial. 8.2 ANEJO 2: EJEMPLOS DE CODIFICACIÓN 8.2.1 CONFIGURACIÓN Un ejemplo de cómo quedaría un archivo de configuración, podría ser algo parecido a lo siguiente: 14 26/11/13

<?php /** * Define la clase 'config' de configuración de la aplicación */ class config { static $appname = ''; static $dbtype = ''; // 'mysql' o 'mssql'. static $dbhost = ''; static $dbname = ''; static $dbuser = ''; static $dbpass = ''; static $dbprefix = ''; // prefijo para usar en los nombres de tablas. static $charset = ''; static $dbpersist = false; static $dblibrary = 'native'; static $dirroot = ''; static $dataroot = ''; static $logroot = ''; static $wwwroot = '';?> 8.2.2 CONEXIÓN A BASE DE DATOS Un ejemplo de conexión podría ser el siguiente: <?php require_once(dirname( FILE ). '/config.php');... $link = mysql_connect(config::$dbhost, config::$dbuser, config::$dbpass); if (!$link) { die('no pudo conectarse: '. mysql_error()); echo 'Conectado satisfactoriamente'; mysql_close($link);...?> Otro ejemplo de conexión, usando adodb, podría ser el siguiente: <? include('adodb.inc.php'); require_once(dirname( FILE ). '/config.php'); $conn = &ADONewConnection(config::$dbtype); $conn->connect(config::$dbhost, config::$dbuser, config::$dbpass); $query = "select * from usuario"; $query.= "where nombre like '%$nombre%'"; $datos = &$conn->execute($query); $nfila = $datos->recordcount(); if (!$recordset){ print "No se realizó la conexión"; print $conn->errormsg(); else { 15 26/11/13

while (!$recordset->eof) { print $datos->fields[0].' '.$datos->fields[1].'<br>'; $datos->movenext(); $datos->close(); $conn->close();?> Para cargar el archivo de configuración, el código necesario para hacer la llamada podría ser el siguiente: require_once(dirname( FILE ). '/config.php'); 8.2.3 DIRECTORIOS Y ARCHIVOS DE REGISTROS Por ejemplo, si necesitáramos indicar cuál es directorio donde se han de grabar los datos, esto se indicaría con un parámetro, llamado dataroot de la siguiente forma:... static $dirroot = '/var/www/<nombreaplicacion>/'; static $dataroot = '/var/datos/<nombreaplicacion>/'; static $logroot = '/var/log/httpd/<dominioaplicacion>/';... 8.2.4 ENVÍO DE CORREOS Un posible ejemplo de código que implementa la funcionalidad de envío de emails con soporte de autenticación es el siguiente, empleando la utilidad Mail.php: <?php require_once "Mail.php"; require_once(dirname( FILE ). '/config.php'); $to = "Ramon <ramon@ejemplo.com>"; $subject = "Hola!!!"; $body = "Hola,\n\nQue tal?"; $headers = array ('From' => config::$smtpfrom, 'To' => $to, 'Subject' => $subject); $smtp = Mail::factory('smtp', array ('host' => config::$smtphost, 'auth' => true, 'username' => config::$smtpuser, 'password' => config::$smtppass)); $mail = $smtp->send($to, $headers, $body); if (PEAR::isError($mail)) { echo("<p>". $mail->getmessage(). "</p>"); else { echo("<p>mensaje enviado!</p>");... 16 26/11/13

Siendo la configuración para este ejemplo de la aplicación la siguiente:... static $smtphost = 'mail_prod'; static $smtpuser = 'miusuario'; static $smtppass = 'miclave'; static $smtpfrom = 'miusuario@ineco.com';... 8.2.5 MONITORIZACIÓN Se facilita un ejemplo orientativo de esta funcionalidad en el siguiente código que deberá ser completada con los datos correspondientes del aplicativo: <?php require_once('config.php'); // Define el recurso a la base de datos $link = mysql_connect(config::$dbhost, config::$dbuser, config::$dbpass); // Define el archivo a testear $archivo = config::$dataroot. 'webtest.txt'; // Define el acceso URL a testear $url = config::$wwwroot; // Testea el acceso al path definido try { if ($resource = fopen($archivo, 'w')) { if (fwrite($resource, 'Ok') == FALSE) { header("http/1.1 500 No pudo acceder al path de datos: No pudo escribir."); else { header("http/1.1 500 No pudo acceder al path de datos: No pudo abrir"); fclose($resource); catch (Exception $e) { header("http/1.1 500 No pudo acceder al path de datos: ". $e->getmessage()); // Testea el acceso a base de datos try { if (!$link) { header("http/1.1 500 No pudo conectarse a la base de datos: ". mysql_error()); mysql_close($link); catch (Exception $e) { header("http/1.1 500 No pudo conectarse a la base de datos: ". $e- >getmessage()); // Testea el acceso URL try { $handle = curl_init($url); if ($handle) { if (curl_setopt($handle, CURLOPT_RETURNTRANSFER, TRUE)) { if (curl_getinfo($handle)!= 200) { header("http/1.1". curl_getinfo($handle). "No pudo conectarse a la url: El valor de retorno es distinto de 200"); 17 26/11/13

else { header("http/1.1 500 No pudo conectarse a la url: No pudo establecer opciones de sesion");?> else { header("http/1.1 500 No pudo conectarse a la url: No pudo iniciar sesion"); curl_close($handle); catch (Exception $e) { header("http/1.1 500 No pudo conectarse a la url: ". $e->getmessage()); 18 26/11/13