Instituto Tecnolgico de Hermosillo

Servicio y Administracin de Redes

Servidor Apache

Corral Gadea Jos Fernando

Ing. Sistemas Computacionales

Hermosillo, Sonora. A Jueves 06 de Octubre del 2011.

Directivas de configuracin en el fichero httpd.conf El archivo de configuracin del servidor Web Apache es /etc/httpd/conf/httpd.conf. El archivo httpd.conf est bien comentado y es bastante autoexplicativo. La configuracin predeterminada de secure Web server funciona para los ordenadores de la mayora de los usuarios, as que probablemente no necesitar cambiar ninguna de las directivas en el fichero httpd.conf. Sin embargo, quizs quiera conocer el resto de las opciones de configuracin ms importantes. Los ficheros vacos srm.conf y access.conf se encuentran en el directorio /etc/httpd/conf. Precisamente estos ficheros junto con el fichero httpd.conf se utilizaron anteriormente como ficheros de configuracin de Apache. Si necesita configurar Apache slo tiene que modificar el fichero httpd.conf y despus recargar o bien apagar y arrancar el proceso del comando httpd. Para mayor informacin consulte la la seccin de nombre Arranque y apagado del httpd. Antes de modificar el fichero httpd.conf debe de copiar el fichero original dndole por ejemplo, el nombre httpd.confold u otro cualquiera. Si comete un error mientras est modificando el fichero de configuracin, no se preocupe porque siempre dispone de una copia de seguridad. Si comete un error y su servidor de web no funciona correctamente, el primer sitio donde acudir es lo que acaba de modificar en httpd.conf. Asegrese de no haber cometido ningn gazapo. Despus consulte el fichero de conexin de error (/var/log/httpd/error_log). Este puede ser difcil de interpretar, todo depende del nivel de experiencia. Si acaba de tener problemas, de todas formas, las ltimas entradas deberan de ayudarle a saber lo que ha pasado. Las siguientes secciones dan breves descripciones de las directivas includas en el fichero httpd.conf, ordenadas segn se encuentran en l. Las descripciones no son exhaustivas. Si necesita ms informacin, consulte la documentacin de Apache en formato HTML en http://your_domain/manual/ o en la documentacin del grupo Apache en http://www.apache.org/docs/. Para ms informacin sobre las directivas mod_ssl, consulte la documentacin includa en formato HTML en http://your_domain/manual/mod/mod_ssl/, o vea el mod_ssl en el Manual del usuario en http://www.modssl.org/docs/2.7/. ServerType El comando ServerType puede ser tanto inetd como standalone. El servidor de web tiene como comando predeterminado el ServerType standalone. Dicho comando, el ServerType standalone significa que el servidor arranca cuando se han llevado a cabo todas las conexiones. Por otro lado,el comandoServerType inetd quiere decir que arranca una nueva instancia cada vez que se produzca una conexin HTTP. Cada una de las instancias del servidor contiene la conexin y aunque acabe conexin sigue existiendo. Como puede imaginarse, la utilizacin del comando inetd no sirve para mucho. Otro problema que se presenta con este comando es que puede no funcionar correctamente segn el grupo Apache. Por ltimo, debido a que tanto Red Hat Linux y 7.1 utilizan dicho comando se necesitara aadir otra configuracin para que el comando xinetd arrancase el servidor. Por ello, para evitar estos problemas le aconsejamos que el comandoServerType sea standalone. ServerRoot

El comando ServerRoot es el directorio principal donde se encuentran todos los ficheros del servidor. Tanto el servidor seguro como el no seguro utilizan un comando ServerRoot del /etc/httpd. LockFile El comando LockFile configura el path al fichero de bloqueo utilizado por el servidor Apache cuando se compila con USE_FCNTL_SERIALIZED_ACCEPT oUSE_FLOCK_SERIALIZED_ACCEPT. No se debera de cambiar el valor predeterminado del comando LockFile. PidFile El comando PidFile nombra el archivo en el que el servidor graba su ID de proceso (pid). secure Web server est configurado para grabar su pid en/var/run/httpd.pid. ScoreBoardFile El comando ScoreBoardFile almacena informacin interna sobre el proceso del servidor que se utiliza para comunicar el proceso padre con los procesos hijos. secure Web server's El comando ScoreBoardFile se encuentra en /var/run/httpd.scoreboard.. ResourceConfig La directiva ResourceConfig instruye al servidor a que lea el fichero ResourceConfig para buscar ms directivas de configuracin. La directiva ResourceConfigest comentada porque el servidor slo usa httpd.conf para directivas de configuracin. AccessConfig La directiva AccessConfig instruye al servidor a leer el fichero AccessConfig para buscar ms directivas de configuracin, tras haber ledo el ficheroResourceConfig. Dicha directiva est comentada porque el servidor slo usa httpd.conf para directivas de configuracin. Timeout El comando Timeout define, en segundos, el tiempo que el servidor esperar para recibir y enviar peticiones durante la comunicacin. Especficamente, el comandoTimeout define cunto esperar el servidor para recibir peticiones GET, cunto esperar para recibir paquetes TCP en una peticin POST o PUT y cunto esperar entre una ACK y otra respondiendo a paquetes TCP. El comando Timeout est ajustado a 300 segundos, que es el tiempo apropiado para la mayora de las situaciones. KeepAlive El comando KeepAlive determina si el servidor permitir varias conexiones a la vez (p.e., ms de una peticin por conexin). KeepAlive puede usarse para impedir que un cliente consuma muchos recursos del servidor. El comando KeepAlive aparece ya en on por defecto, lo que significa que se permiten varias conexiones a la vez. Puede ponerse en off para desactivarlas. Consulte la seccin de nombre MaxKeepAliveRequests para conocer un mtodo alternativo para limitar las peticiones. MaxKeepAliveRequests

Esta directiva establece el nmero mximo de peticiones permitidas por cada conexin que se produzca a la vez. El Grupo Apache recomienda un valor alto, lo que mejorara el rendimiento. El valor predeterminado del comando MaxKeepAliveRequests es de 100 que debera bastar en la mayora de los casos. KeepAliveTimeout La directiva KeepAliveTimeout establece el nmero de segundos que el servidor esperar a la siguiente peticin, tras haber dado servicio a una peticin, antes de cerrar la conexin. Una vez recibida la peticin, aplica la directiva Timeout en su lugar. MinSpareServers y MaxSpareServers El servidor Web Apache se adapta dinmicamente a la carga percibida manteniendo un nmero apropiado de servidores libres basado en el trfico. El servidor comprueba el nmero de servidores que esperan peticiones y elimina algunos si el nmero es ms alto que MaxSpareServers o crea algunos si el nmero de servidores es menor que MinSpareServers. El valor predeterminado de MinSpareServers es 5 y el de MaxSpareServers es 20. Estos valores predeterminados son suficientes en la mayora de los casos. El nmero de MinSpareServers no debera de ser elevado ya que crear una gran carga incluso cuando el trfico fuese bajo. StartServers StartServers establece cuntos procesos sern creados al arrancar. Ya que el servidor Web crea y elimina dinmicamente servidores segn el trfico, no se necesitar cambiar este parmetro. El servidor est configurado para arrancar ocho procesos al arrancar. MaxClients El comando MaxClients establece un lmite al total de los procesos del servidor (es decir, clientes conectados simultneamente) que se ejecutan a la vez. Debe mantener el comando MaxClients a un valor alto (el valor por defecto es 150), porque no se permitirn nuevas conexiones una vez que se alcance el nmero mximo de clientes simultneamente conectados. El valor del comando MaxClients no puede superar el 256 sin que se haya recompilado Apache. La principal razn de tener el parmetro MaxClients es evitar que un servidor errtico vuelva inestable al sistema operativo. MaxRequestsPerChild El comando MaxRequestsPerChild establece el nmero mximo de peticiones que cada proceso hijo procesa antes de morir. La principal razn para tener el comando MaxRequestsPerChild es evitar que procesos de larga vida pierdan memoria. El valor predeterminado de MaxRequestsPerChild para el servidor es de 100. Listen El comando Listen establece los puertos en los que secure Web server acepta las peticiones entrantes. secure Web server est configurado para escuchar en el puerto 80 para comunicaciones no seguras y (en mquinas virtuales que define el servidor seguro) en el puerto 443 para comunicaciones seguras.

Para puertos por debajo de 1024, el comando httpd deber ser ejecutado como root. Para el puerto 1024 y superiores, el comando httpd puede ser ejecutado como si se fuera un usuario cualquiera. El comando Listen tambin se puede usar para especificar direcciones IP especficas en las cuales aceptar conexiones el servidor. BindAddress BindAddress es un modo de especificar en qu direcciones IP el servidor escuchar. Debera usarse la directiva Listen en su lugar si se necesita esta funcionalidad. El servidor no usa el comando BindAddress el cual ya aparece comentado en httpd.conf. LoadModule El comando LoadModule se usa para cargar mdulos Dynamic Shared Object(DSO). Para ms informacin sobre el soprte de los DSOs de Apache y cmo usar la directiva LoadModule, lea la seccin de nombre Aadir mdulos a su servidor. Ntese que el orden de los mdulos es importante, as que mejor no tocarlo. IfDefine Las etiquetas <IfDefine> y </IfDefine> rodean a directivas de configuracin que son aplicadas si el test aplicado a la etiqueta <IfDefine> resulta verdadero; las directivas no se tienen en cuenta si el test es falso. Dicho test aplicado a la etiqueta <IfDefine> es un nombre de un parmetro (p.ej., HAVE_PERL). Si el parmetro est definido,es decir, si se da como argumento al comando de arranque del servidor, entonces el test es verdadero. En este caso, cuando se arranca el secure Web server el test es verdadero y se aplican las directivas contenidas en las etiquetas IfDefine. Por defecto, las etiquetas <IfDefine HAVE_SSL> rodean las etiquetas de la mquina virtual del servidor seguro. Las etiquetas <IfDefine HAVE_SSL> tambin rodean a las directivas LoadModule y a las AddModule para ssl_module. ClearModuleList El comando ClearModuleList se encuentra justo antes de la larga lista de directivas AddModule. ClearModuleList borra la lista interna de mdulos del servidor. La lista de directivas AddModule recrea la lista, justo despus de ClearModuleList. AddModule AddModule es la directiva usada para crear una lista completa de mdulos disponibles. Se usa la directiva AddModule para aadir mdulos como DSO. Para ms informacin sobre cmo usar el comando AddModule para el soporte DSO, vea la seccin de nombre Aadir mdulos a su servidor. ExtendedStatus La directiva ExtendedStatus controla si Apache genera informacin de estado bsico (off) o detallada (on), cuando se llama al gestor server-status. Se llama al gestor Server-

status utilizando la etiqueta Location; Para mayor informacin sobre cmo llamar al serverstatus consulte la la seccin de nombre Location Port Normalmente, el comando Port define el puerto en el que escucha el servidor. secure Web server, sin embargo, escucha en ms de un puerto por defecto, ya que la directiva Listen tambin se usa. Cuando la directiva Listen est en uso, el servidor escucha en todos esos puertos. Consulte la descripcin de Listen para ms informacin sobre el comando Listen. El comando Port tambin se usa para especificar el nmero de puerto usado para crear el nombre cannico para el servidor. Consulte la la seccin de nombreUseCanonicalName para ms informacin sobre el nombre cannico del servidor. User La directiva User establece el userid usado por el servidor para responder a peticiones. El valor de User determina el acceso al servidor. Cualquier fichero al que no pueda acceder este usuario ser tambin inaccesible al visitante de la web. El comando predeterminado para User es apache. User debera slo tener privilegios de tal manera que slo puediera acceder a ficheros que se supone que todo el mundo puede ver. El comando User tambin es dueo del cualquier proceso CGI que arranque el servidor.Al comando User no se le debera permitir ejecutar ningn cdigo que no est pensado para responder peticiones HTTP. Nota A menos que sepa exactamente lo que est haciendo, no utilice el comando User como si fuese root. Usar root para User crear grandes problemas de seguridad en secure Web server. El proceso httpd padre se ejecuta como root durante operaciones normales, pero pasa al usuario apache inmediatamente. El servidor debe arrancar como root porque necesita un puerto por debajo de 1024 (El puerto predeterminado para comunicaciones seguras es 443; el puerto por defecto para comunicaciones no seguras es el puerto 80). Los puertos por debajo de 1024 estn reservados para el sistema, as que slo se pueden usar si se es root. Una vez que el servidor se ha conectado al puerto, pasa el proceso a User antes de aceptar peticiones. Group El comando Group es similar a User. Group establece el grupo en el que el servidor responde a las peticiones. El valor predeterminado del comando Grouptambin es apache. ServerAdmin ServerAdmin debera ser la direccin de correo del administrador del secure Web server. Esta direccin de correo aparecer en los mensajes de error generados por el servidor para pginas web,de tal manera que los usuarios pueden comunicar errores enviando correo al administrador. El comando ServerAdmin ya se encuentra en la direccin root@localhost.

Una forma buena y tpica de configurar ServerAdmin es situarlo en la direccin webmaster@your_domain.com. Despus cree un alias del webmaster para la persona responsable del servidor en /etc/aliases. Finalmente, ejecute /usr/bin/newaliases para aadir el nuevo alias. ServerName El comando ServerName puede usarse para establecer el nombre de la mquina del servidor diferente al nombre real de mquina como por ejemplo, usar www.your_domain.com aunque el nombre real del servidor sea foo.your_domain.com. Ntese que ServerName debe ser un nombre "Domain Name Service" (DNS) vlido que se tenga derecho a usar (no basta con inventar uno). Si se especifica ServerName, hay que asegurarse de incluir la pareja nombre-direccin IP en el fichero /etc/hosts. DocumentRoot DocumentRootes el directorio que contiene la mayora de los archivos HTML que se entregarn en respuesta a peticiones. El directorio predeterminadoDocumentRoot para servidores seguros y no seguros es /var/www/html. Por ejemplo, el servidor puede recibir una peticin para el siguiente documento: http://your_domain/foo.html El servidor buscar el fichero en el siguiente directorio por defecto: /var/www/html/foo.html

Si se quiere cambiar DocumentRoot para que no lo compartan los servidores seguros y no seguros, vea la seccin de nombre Utilizacin de mquinas virtuales. Directory Las etiquetas <Directory /path/to/directory> y </Directory> se usan para agrupar directivas de configuracin que slo se aplican a ese directorio y sus subdirectorios. Cualquier directiva aplicable a un directorio puede usarse en las etiquetas <Directory>. Las etiquetas <File> pueden aplicarse de la misma forma a un fichero especfico. Por defecto,se aplican parmetros muy restrictivos al directorio raz, utilizando Options (vea la la seccin de nombre Options) y AllowOverride (vea la la seccin de nombre AllowOverride). Con esta configuracin, cualquier directorio del sistema que necesite valores ms permisivos ha de ser configurado explcitamente. La utilizacin de las etiquetas Location, permite al comando DocumentRoot (referido a "/") tener parmetros menos rgidos para que el servidor sirva las peticiones HTTP. El directorio cgi-bin est configurado para permitir la ejecucin de scripts CGI, con la opcin ExecCGI. Si se necesita ejecutar un script CGI en cualquier otro directorio, habr que configurar ExecCGI para ese directorio. Por ejemplo, si cgi-bin es /var/www/cgi-bin, pero se quiere ejecutar scripts CGI desde/home/my_cgi_directory, aadir una

directiva ExecCGI a un par de directivas Directory como las siguientes al fichero httpd.conf: <Directory /home/my_cgi_directory> Options +ExecCGI </Directory> Para permitir la ejecucin de scripts CGI en /home/my_cgi_directory, habr que llevar a cabo pasos extra aparte de configurar ExecCGI. Tambin necesitar anular el comentario de la directiva AddHandler para identificar ficheros con extensin .cgi como scripts CGI. Vea la la seccin de nombre AddHandler para saber cmo configurar el comando AddHandler. El valor de los permisos para scripts CGI y el recorrido entero a los scripts, debe ser de 0755. Adems, el dueo del script y del directorio deben ser el mismo. Options La directiva Options controla caractersticas del servidor que estn disponibles en un directorio en particular. Por ejemplo, en los parmetros restrictivos especificados para el directorio raz, el comando Options slo permite FollowSymLinks. No hay caractersticas permitidas, salvo que el servidor pueda seguir enlaces simblicos en el directorio raz. Por defecto, en el directorio DocumentRoot, Options est configurado para incluir los comandos Indexes, Includes y FollowSymLinks. Indexes permite al servidor generar un listado de un directorio si no se especifica el DirectoryIndex (index.html, etc.). Includes implica que se permiten inclusiones en el servidor y el comando FollowSymLinks permite al servidor seguir enlaces simblicos en ese directorio. Tambin se tienen que incluir declaraciones del comando Options para los directorios que estn dentro de directivas de mquinas virtuales, si se quiere que stas reconozcan esas Options. Por ejemplo, la inclusin en el servidor est activada en el directorio /var/www/html en la lnea Options Includes dentro de la seccin Location "/". Sin embargo, si se quiere que una mquina virtual reconozca que se permite realizar la inclusin desde el servidor en /var/www/html, habr que incluir una seccin como la siguiente desde dentro de las etiquetas de las mqinas virtuales: <Directory /var/www/html> Options Includes </Directory> AllowOverride AllowOverride establece qu directivas Options puede obviar un archivo .htaccess. Por defecto, tanto el directorio raz como DocumentRoot estn configurados para no permitir la prevalencia de .htaccess. Order Order simplemente controla el orden en que allow y deny se evaluan. El servidor est configurado para evaluar Allow antes que deny para el directorioDocumentRoot. Allow

Allow especifica qu peticionario puede acceder un directorio dado. El peticionario puede ser all, un nombre de dominio, una direccin IP, una direccin IP parcial, un par red/mscara de red, etc. El directorio DocumentRoot est configurado para permitir peticiones de all (cualquiera). Deny Deny funciona como allow, pero especifica a quin se niega el acceso. DocumentRoot no est configurado para rechazar peticiones de nadie. UserDir UserDir es el nombre del subdirectorio dentro del directorio de cada usuario dnde estarn los archivos HTML que sern servidos. Por defecto, el subdirectorio espublic_html. Por ejemplo, el servidor podra recibir la siguiente peticin: http://your_domain/~username/foo.html

El servidor buscara el fichero: /home/username/public_html/foo.html

En el ejemplo, /home/username es el directorio del usuario (ntese que la ruta predeterminada a los directorios de los usuarios puede variar entre sistemas). Hay que asegurarse que los permisos de los directorios de usuario sean correctos. El valor de los permisos deben ser de 0755. Los bits de lectura (r) y ejecucin (x) deben estar activados en el directorio del usuario public_html (0755 valdr). El valor de los permisos con que se servirn los ficheros desde public_html debe ser 0644 por lo menos. DirectoryIndex DirectoryIndex es la pgina por defecto que entrega el servidor cuando hay una peticin de ndice de un directorio especificado con una barra (/) al final del nombre del directorio. Por ejemplo, cuando un usuario pide la pgina http://your_domain/this_directory/, recibe la pgina DirectoryIndex si existe, o un listado generado por el servidor. El valor por defecto para DirectoryIndex es index.html, index.htm index.shtml e index.cgi. El servidor intentar encontrar cualquiera de estos cuatro, y entregar el primero que encuentre. Si no encuentra ninguno y si Options Indexes se encuentra en el directorio, el servidor generar un listado, en formato HTML, de los subdirectorios y archivos del directorio. AccessFileName AccessFileName denomina el archivo que el servidor utilizar para controlar el acceso en cada directorio. Por defecto, el servidor utilizar .htaccess, si existe, para controlar el acceso en cada directorio.

Justo tras AccessFileName,el comando Files controla el acceso a cualquier archivo que empiece con .ht. Estas directivas niegan acceso a todo tipo de archivo.htaccess (u otros archivos que empiecen .ht) por razones de seguridad. CacheNegotiatedDocs Por defecto, secure Web server requiere a los "proxies" que no hagan cach de los documentos que se negocian en base al contenido ( pueden cambiar en el tiempo o segn los datos del peticionario). Si se anula el comentario del comando CacheNegotiatedDocs, se desactiva la funcin y los "proxies" podrn hacer cach de los documentos. UseCanonicalName UseCanonicalName ya aparece en on. El comando UseCanonicalName permite que los URLs contengan sus propias referencias utilizando los comandosServerName y Port. Cuando el servidor se refiere a si mismo en respuesta a peticiones de clientes, usa este URL. Si el UseCanonicalName est en off, el servidor utilizar el valor que vino en la peticin del cliente para referirse a si mismo. TypesConfig TypesConfig denomina el fichero que establece la lista predeterminada de mapeado de tipos MIME (extensiones de ficheros a tipos de contenido). El fichero predeterminado TypesConfig es /etc/mime.types. En vez de modificar el /etc/mime.types, se recomienda aadir mapeados de tipos MIMEs con AddType. DefaultType DefaultType establece el contenido por defecto que el servidor utilizar para documentos cuyos tipos MIME no puedan ser determinados. El servidor predispone el texto para cualquier fichero con un tipo de contenido indeterminado. IfModule <IfModule> y </IfModule> envuelven a directivas que son condicionales. Las directivas contenidas dentro de IfModule son procesadas si se cumple una de las dos condiciones. Las directivas son procesadas si el mdulo contenido en la etiqueta <IfModule> est compilado en el servidor Apache. O, si una "!" (exclamacin) aparece antes del nombre; las directivas son procesadas slo si el mdulo en la etiqueta <IfModule> no est compilado. El fichero mod_mime_magic.c est includo en IfModule. El mdulo mod_mime_magic puede compararse al comando UNIX file, que examina los primeros bytes de un fichero, y usa "nmeros mgicos" y otros trucos para decidir el tipo MIME del fichero. Si el mdulo mod_mime_magic est compilado en Apache, estas etiquetas IfModule le dicen al mdulo mod_mime_magic module donde est el fichero de los trucos: share/magic en este caso. El mdulo mod_mime_magic module no est compilado por defecto. Si se quier usar, vea la la seccin de nombre Aadir mdulos a su servidor, para saber cmo aadir mdulos al servidor. HostnameLookups

HostnameLookups puede aparecer en on o en off. Si el servidor permite la directiva HostnameLookups (ponindolo en on), el servidor resolver automticamente la direccin IP de cada conexin que pida un documento del servidor. Resolver la direccin IP implica que el servidor har una o ms conexiones al DNS para averiguar qu nombre de mquina se corresponde con una direccin IP. Generalmente, debera dejarse HostnameLookups en off porque las peticiones de DNS aanden carga al servidor y pueden ralentizarlo. Si el servidor tiene carga, los efectos de HostnameLookups pueden ser considerables. HostnameLookups influye tambin en Internet en general. Cada conexin individual provoca una sobrecarga en el servidor. Por ello, por beneficio del servidor y de Internet en general, debera dejarse HostnameLookups en off. ErrorLog ErrorLog nombra el fichero donde se guardan los errores del servidor.Como viene indicado, el fichero de error del servidor es /var/log/httpd/error_log. El log de errores es un buen sitio para ver si el servidor genera errores y no se sabe muy bien qu pas. LogLevel LogLevel establece cmo sern de abundantes los logs de error. Los niveles de error del LogLevel (de menor a mayor) son emerg, alert, crit, error, warn,notice, info or debug. El LogLevel de secure Web server est en warn (nivel medio). LogFormat LogFormat pone el formato para los mensajes en el log de acceso; afortunadamente, el formato har que el log de acceso sea ms legible. CustomLog CustomLog identifica el log y el formato de log. La configuracin por defecto de CustomLog de secure Web server, define el log en el que se guardan los accesos al servidor /var/log/httpd/access_log. Habr que saber la localizacin de este archivo si se quieren generar estadsticas de rendimiento del servidor. CustomLog pone el formato comn para el archivo. El formato comn de log es de la siguiente forma: remotehost rfc931 authuser [date] "request" status bytes remotehost El nombre de la mquina: Si el nombre no est disponible en el DNS, o s HostnameLookups est en Off, entonces remotehost ser la direccin IP de la mquina remota. rfc931 No utilizado: Se ver un - en el log en su lugar.

authuser Si se requiri la autenticacin, este es el usuario con el que el usuario se identific. Generalmente, no se usa, as que se ver un - en su lugar. [date] Fecha y hora de la peticin. "request" Cadena de texto de la peticin segn vino del cliente. status Cdigo de estado HTTP que se devolvi al cliente. bytes Tamao del documento. El comando CustomLog puede utilizarse para configurar logs especficos para registrar referencias(el URL que hizo el enlace al servidor) y/o agentes (navegadores utilizados para pedir pginas al servidor). Las lneas relevantes del CustomLog estn comentadas, como se muestra, pero se debera de anular el comentario si se quieren los dos archivos de log: #CustomLog /var/log/httpd/referer_log referer #CustomLog /var/log/httpd/agent_log agent Alternativamente, se puede poner la directiva CommonLog para que use un log combinado sin el comentario en la siguiente lnea: #CustomLog /var/log/httpd/access_log combined Un fichero de log combined aadir los campos agente y referer al final de cada lnea. Si desea utilizar un fichero de log combined elimine el comentario que aparece en CustomLog. ServerSignature El comando ServerSignature aade una lnea que contiene la versin del servidor Apache y el ServerName de la mquina a los documentos generados por el servidor (p.ej, mensajes de error devueltos a clientes). ServerSignature ya aparece en on. Se puede cambiar a off para no aadir nada, o se puede cambiar aEMail. EMail aadir una etiqueta HTML mailto:ServerAdmin a la lnea de firma. Alias El comando Alias permite que haya directorios fuera del DocumentRoot a los que puede acceder el servidor. Cualquier URL que termine en un alias ser automticamente traducido por el recorrido del alias. Por defecto, ya existe un alias configurado. El servidor puede acceder al directorio icons pero el directorio no est en DocumentRoot. icons , un alias, est en /var/www/icons/, y no en /var/www/html/icons/.

ScriptAlias El comando ScriptAlias define dnde pueden encontrarse los scripts CGI (u otros scripts). Normalmente, no se ponen los scripts CGI dentro de DocumentRoot. Si los scripts CGI se encontrasen en DocumentRoot, podran , potencialmente, ser considerados como documentos de texto. Incluso si no preocupa que la gente vea (y use) los scripts CGI, mostrar cmo funcionan crea oportunidades a la gente sin escrpulos que quiera explotar dichos agujeros en el script, y puede crear un agujero de seguridad en el servidor. Por defecto, el directorio cgibin es un ScriptAlias de /cgi-bin/, y se encuentra situado /var/www/cgi-bin/. El directorio /var/www/cgi-bin tiene activada la directiva Options ExecCGI, lo que implica que se permite la ejecucin de scripts CGI en el directorio. Vea la la seccin de nombre AddHandler y la la seccin de nombre Directory para saber cmo ejecutar scripts CGI en otros directorios aparte de cgi-bin. Redirect Cuando se cambia una pgina de sitio, el comando Redirect se puede usar para pasar del viejo URL al nuevo URL. El formato es como sigue: Redirect /path/foo.html http://new_domain/path/foo.html As que si se recibe una peticin HTTP para un pgina que sola estar en http://your_domain/path/foo.html, el servidor devolver el nuevo URL (http://new_domain/path/foo.html) al cliente, que tratar de coger el documento desde el nuevo URL. IndexOptions El comando IndexOptions controla la apariencia de los listados generados por el servidor, al aadir iconos y texto descriptivo, etc. Si Options Indexes aparece como en (vase la seccin de nombre Options),el servidor podr generar el listado de un directorio al recibir una peticin HTTP como la que sigue: http://your_domain/this_directory/ Primero el servidor busca en el directorio un fichero de los de la lista de DirectoryIndex (p.ej., index.html). Si el servidor no encuentra ninguno de los ficheros, genera un listado del directorio en HTML. Se puede modificar la apariencia del listado utilizando ciertas directivas en httpd.conf, entre las que se encuentraIndexOptions. La configuracin predeterminada activa es FancyIndexing. Si se activa FancyIndexing, al hacer click en la cabecera de las columnas del listado, el listado se ordena segn esa columna. Otro click en la misma cabecera cambiar el orden de ascendente a descendente y viceversa. FancyIndexing tambin muestra distintos iconos para distintos ficheros, segn la extensin. Si se usa la directiva AddDescription y se activa FancyIndexing, se aade una pequea descripcin para el fichero en el listado generado. IndexOptions tiene otros parmetros que pueden activarse para controlar la apariencia de los listados. Los parmetros incluyen IconHeight e IconWidth, para hacer que el servidor incluya

etiquetas HEIGHT y WIDTH para los iconos; el comando IconsAreLinks, hace que los iconos formen parte del enlace HTML junto con el nombre del fichero, y otros. AddIconByEncoding Esta directiva denomina qu iconos se mostrarn con los archivos segn su codificacin MIME, en los listados de directorio. Por ejemplo, por defecto, el servidor muestra el icono compressed.gif junto a archivos con codificacin MIME x-compress y x-gzip en los listados de directorio. AddIconByType Esta directiva denomina qu iconos se mostrarn con los archivos segn su codificacin MIME, en los listados del directorio. Por ejemplo, por defecto, el servidor muestra el icono text.gif junto a archivos con tipo MIME "text" en los listados del directorio. AddIcon AddIcon dice al servidor qu icono mostrar en los listados del directorio para ciertos tipos de archivos segn la extensin. Por ejemplo, el servidor muestra el iconobinary.gif para archivos con extensiones .bin o .exe. DefaultIcon El comando DefaultIcon nombra el icono de los listados del directorio que recibirn los ficheros sin un icono especfico. El fichero de imagen predeterminado para esos ficheros unknown.gif es DefaultIcon. AddDescription Se puede usar AddDescription para mostrar descripciones especficas de ficheross en los listados de los directorios (habr que activar tambin el FancyIndexingcomo una IndexOptions). Puede aplicarse a ficheros individuales, expresiones de nombre o extensiones para especificar los ficheros a los que aplicar esta directiva. Por ejemplo, podra usarse lo siguiente: AddDescription "A file that ends in .ni" .ni

En los listados del directorio, todos los ficheros con extensin .ni tendrn la descripcin Un archivo que termina en .ni tras el nombre. Ntese que necesita activarse el FancyIndexing. ReadmeName La directiva ReadmeName determina el fichero (si existe dentro del directorio) que se adjuntar a los listados de los directorios. El servidor intentar primero incluirlo como documento HTML y luego como texto. El valor predeterminado de ReadmeName es README. HeaderName

La directiva HeaderName dicta el fichero (si existe dentro del directorio) que se antepondr al comienzo de los listados de los directorios. Al igual que conReadmeName, el servidor intentar incluirlo como documento HTML si es posible, o como texto. IndexIgnore El comando IndexIgnore lista las extensiones, los nombres de los ficheros parciales, las expresiones regulares o los nombres completos. El servidor no incluir los ficheros que encajen en estos patrones en los listados de directorios. AddEncoding El comando AddEncoding dice qu extensiones especifican un tipo particular de codificacin. AddEncoding se puede usar para decirle a los navegadores (no a todos) que descompriman ciertos ficheros mientras los descargan. AddLanguage La directiva AddLanguage asocia extensiones a contenidos especficos de idiomas. Esta directiva es til para la negociacin de contenidos, cuando el servidor devuelve uno de entre varios documentos segn las preferencias de idiomas del cliente. LanguagePriority La directiva LanguagePriority permite dar la prioridad a ciertos ficheros en distintos idiomas, que entrarn en vigor si el cliente no especifica la preferencia de idioma. AddType Use la directiva AddType para definir parejas de tipos MIME y sus extensiones. Por ejemplo, si usa el PHP4, el servidor est usando AddType para que se reconozcan ficheros con extensiones PHP (.php4, .php3, .phtml .php) como tipos MIME PHP. La siguiente lnea AddType permite al servidor reconocer las extensiones .shtml (para la inclusin en el servidor): AddType text/html .shtml Se necesitar la lnea de arriba dentro de las etiquetas de mquina virtual para cuando se permita la inclusin desde el servidor. AddHandler La directiva AddHandler mapea y amplia gestores especficos. Por ejemplo, el gestor cgiscript puede usarse para hacer que la extensin .cgi automticamente sea manejada como un script CGI. Esto funciona, incluso para ficheros fuera de ScriptAlias, si se siguen las instrucciones dadas. Hay una lnea AddHandler CGI en httpd.conf como la siguiente: AddHandler cgi-script .cgi

Habr que anular el comentario de la lnea. As Apache ejecutar como scripts CGI los ficheros que terminen en .cgi, incluso si estn fuera de ScriptAlias, que por defecto se encuentra en el directorio /cgi-bin/ en /var/www/cgi-bin/. Tambin habr que activar ExecCGI como Options para cualquier directorio que contenga scripts CGI. Vea la seccin de nombre Directory para ms informacin sobre cmo configurar ExecCGI para un directorio. Adems, habr que asegurarse que los permisos sean los adecuados para los scripts CGI y los subdirectorios que contengan scripts. Los scripts CGI y todo el recorrido que conduce a ellos deben tener un valor de 0755. Finalmente, el dueo del directorio y el del script deben ser el mismo. Habr que aadir la misma lnea AddHandler a la configuracin de VirtualHost, si se usan mquinas virtuales y se quiere que se reconozcan los scripts CGI fuera de ScriptAlias. El servidor tambin usa AddHandler para procesar mapas de imgenes en HTML. Action La directiva Action permite especificar un par de tipos de contenido MIME y un script CGI, de tal forma que cuando se pida un fichero de este tipo, se ejecute un script en particular. MetaDir MetaDir especifica el nombre del directorio donde el servidor debera buscar los ficheros que contengan informacin meta (cabeceras extra de HTTP) que se deba incluir al entregar los documentos. MetaSuffix MetaSuffix especifica el sufijo para los ficheros que contienen informacin meta (cabeceras extra de HTTP), que estarn en el directorio MetaDir. ErrorDocument Por defecto, en caso de error, el servidor muestra un mensaje de error (generalmente crptico) para el cliente. En vez de usar esta opcin ya predeterminada, puede usarse ErrorDocument para devolver un mensaje de error personalizado o redireccionar al cliente a un URL local o remoto. ErrorDocument simplemente asocia un cdigo de respuesta HTTP con un mensaje o un URL que se devolver al cliente. BrowserMatch La directiva BrowserMatch permite al servidor definir variables de entorno y/o tomar acciones segn sea el campo de cabecera User-Agent, que identifica al cliente. Por defecto, el servidor usa BrowserMatch para denegar la conexin a navegadores con problemas conocidos y para desactivar "keepalives" y vaciados de cabecera de HTTP para navegadores con problemas de esas caractersticas. Location Las etiquetas <Location> y </Location> permiten controlar el acceso especfico a cada URL.

El primer uso de Location es configurar Options y proporcionar guas extra de configuracin para DocumentRoot. Estas directivas de configuracin, que se encuentran dentro de las etiquetas <Location "/"> y </Location>, son necesarias para permitir el acceso a documentos en DocumentRoot. El siguiente uso de Location es en las etiquetas IfModule mod_perl.c. Estas directivas de configuracin funcionan si el DSO mod_perl.so est cargado. Consulte la la seccin de nombre Aadir mdulos a su servidor para ms informacin sobre cmo aadir mdulos a Apache. La etiqueta Location nombra el directorio /var/www/perl (un Alias para /perl) como el directorio desde el cual se sirven scripts de Perl. Si se pide un documento con un URL que contenga /perl en el recorrido, el servidor buscar en /var/www/perl/ el script de Perl apropiado. Los comentarios de otras opciones de <Location> estn en httpd.conf. Si se quiere activar su funcionalidad, se necesitar anular el comentario de la seccin apropiada de las directivas. Justo tras las directivas de Perl discutidas anteriormente, httpd.conf incluye una seccin de directivas para activar HTTP PUT (p.ej., publicacin de Netscape Gold, que permite poner pginas web en un servidor). Si se quiere permitir HTTP PUT, habr que anular el comentario de la seccin entera: #LoadModule put_module modules/mod_put.so #AddModule mod_put.c # #Alias /upload /tmp #<Location /upload> # EnablePut On # AuthType Basic # AuthName Temporary # AuthUserFile /etc/httpd/conf/passwd # EnableDelete Off # umask 007 # <Limit PUT> # require valid-user # </Limit> #</Location> Si se quiere que las conexiones desde dentro del mismo dominio tengan acceso a los informes de estado, se debe anular el comentario de la siguiente seccin de directivas: #<Location /server-status> # SetHandler server-status # Order deny,allow # Deny from all # Allow from .your_domain.com #</Location>

Hay que poner el segundo nivel del nombre de dominio en vez de .your_domain.com.

Si se quiere dar informes de configuracin del servidor (incluyendo mdulos instalados y directivas de configuracin) o peticiones desde dentro del dominio, habr que anular el comentario de las siguientes lneas: #<Location /server-info> # SetHandler server-info # Order deny,allow # Deny from all # Allow from .your_domain.com #</Location>

Hay, por supuesto, que rellenar .your_domain.com. La siguiente seccin de directivas usa las etiquetas Location para permitir el acceso a la documentacin en /usr/share/doc (p.ej, con un URL como http://your_domain/doc/whatever.html). Estas directivas slo permiten el acceso a peticiones desde la misma mquina. Otro uso de las etiquetas Location es una seccin comentada, pensada para rastrear ataques al servidor explotando un viejo fallo de los das de pre-Apache 1.1. Si se quieren rastrear estas peticiones, anule el comentario de las siguientes lneas: #<Location /cgi-bin/phf*> # Deny from all # ErrorDocument 403 http://phf.apache.org/phf_abuse_log.cgi #</Location> Si estas lneas no estn comentadas, el servidor mandar cualquier peticin que termine en /cgi-bin/phf* a un CGI que hace log del Grupo Apache. ProxyRequests Si se anula el comentario de la directiva IfModule alrededor del ProxyRequests, el servidor Apache tambin funcionar como proxy. Tambin habr que cargar el mdulo mod_proxy. Para ms informacin sobre cmo cargar mdulos, vea la la seccin de nombre Aadir mdulos a su servidor. ProxyVia La directiva ProxyVia controla si se enva HTTP Via: junto con peticiones o respuestas que vayan va el servidor proxy Apache. Via: header mostrar el nombre de la mquina si ProxyVia aparece en On, el nombre de mquina y la versin de Apache para Full, y cualquier lnea Via: se enviar sin cambiar si est ProxyVia est en Off, y las lneas Via: sern eliminadas si est en Block. Directivas de cach Hay varias directivas de cach en las etiquetas de proxy IfModule mencionadas antes. Si se usa la funcionalidad proxy y se quiere habilitar el cach proxy, habr que anular el comentario de las directivas segn se describe. Los valores predeterminado de las directivas de cach deberan bastar para la mayora de las configuraciones.

CacheRoot pone el nombre del directorio que contiene ficheros de cach. El valor predeterminado de CacheRoot es /var/cache/httpd. CacheSize establece cunto espacio puede usar el cach, en KB. El valor predeterminado de CacheSize es 5 KB. CacheGcInterval establece el nmero de horas. Tras ese nmero se borrarn los ficheros de cach si ocupan ms de lo permitido por CacheSize. El valor por defecto de CacheGcInterval es cuatro horas. Los documentos HTML en cach se guardarn (sin una recarga desde el servidor de origen) durante el nmero mximo de horas establecido porCacheMaxExpire. El valor predeterminado es 24 horas. CacheLastModifiedFactor afecta a la fecha de caducidad para documentos que no venan con caducidad desde el servidor de origen. El valor predeterminado deCacheLastModifiedFactor es 0.1, lo que significa que la caducidad del documento ser un dcimo del tiempo total desde que se modific el documento por ltima vez. CacheDefaultExpire es la caducidad en horas para documentos recibidos va protocolos que no soportan la caducidad. El valor predeterminado es de una hora. Todo documento que provenga de una mquina y/o de un dominio que encaje en NoCache no se pondr en cach. Si conoce mquinas o dominios en los que no se quiera hacer cach de sus documentos, anule el comentario de la directiva NoCache e introduzca dominios y nombres aqu. NameVirtualHost Necesitar usar la directiva NameVirtualHost para la direccin IP (y nmero de puerto si es necesario) de algn nombre de mquinas virtuales que est estableciendo. La configuracin basada en mquinas virtuales se usa para establecer mquinas virtuales para diferentes dominios, pero no tiene (o no usa) diferentes direcciones IP para todos los dominios a los cuales su Web Server sirve documentos Nota No puede usar nombres basados en mquinas virtuales con su servidor seguro. Algunos nombres basados en mquinas virtuales que establezca trabajarn slo con conexiones HTTP no seguras y no con conexiones SSL. No puede usar nombres basados en mquinas virtuales con su servidor seguro porque el acuerdo SSL (cuando el navegador acepta el certificado de autenticacin de Web seguro) viene antes de la peticion HTTP con la cual identifica el nombre correcto de las mquinas virtuales. En otras palabras, la autenticacin viene antes de la identificacin de las mquinas virtuales. Si quiere usar mquinas virtuales con su servidor seguro necesitar usar direcciones IP basadas en mquinas virtuales. Si est usando nombres basados en mquinas virtuales, comente la directiva NameVirtualHost y aada la direccin IP correcta para su servidor despus delNameVirtualHost. Entonces aada ms informacin sobre los diferentes dominios usando el comando VirtualMachine el cual envuelve el ServerName para cada mquina virtual, ms algunas otras directivas de configuracin que son slo aplicables a la mquina virtual.

VirtualHost <VirtualHost> y </VirtualHost> envuelven directivas de configuracin que se aplican a mquinas virtuales. La mayora de las directivas de configuracin pueden usarse en etiquetas de mquina virtual, y slo se aplicarn a esa mquina virtual. Existen varias etiquetas VirtualHost que rodean a algunos modelos de directivas de configuracin as como de espacios en blanco que tendr que rellenar con informacin para configurar la mquina virtual. Consulte la la seccin de nombre Utilizacin de mquinas virtuales, para saber ms sobre mquinas virtuales. SetEnvIf La directiva de configuracin de Apache SetEnvIf se usa para desactivar HTTP keepalive y permitir a SSL cerrar las conexiones sin avisar desde el cliente. Este parmetro es necesario para clientes que no cierran bien la conexin SSL.

Proceso de Comunicacin Entre Servidor web y cliente web

En una red de ordenadores hay varios ordenadores que estn conectados entre si por un cable. A travs de dicho cable pueden transmitirse informacin. Es claro que deben estar de acuerdo en cmo transmitir esa informacin, de forma que cualquiera de ellos pueda entender lo que estn transmitiendo los otros, de la misma forma que nosotros nos ponemos de acuerdo para hablar en ingls cuando uno es italiano, el otro francs, el otro espaol y el otro alemn. Al "idioma" que utilizan los ordenadores para comunicarse cuando estn en red se le denomina protocolo. Hay muchsimos protocolos de comunicacin, entre los cuales el ms extendido es el TCP/IP. El ms extendido porque es el que se utiliza en Internet. Aunque todo esto pueda parecer complicado y que no podemos hacer mucho con ello, lo cierto es que podemos aprovecharlo para comunicar dos programas nuestros que estn corriendo en ordenadores distintos. De hecho, con C en Linux/Unix tenemos una serie de funciones que nos permiten enviar y recibir datos de otros programas, en C o en otros lenguajes de programacin, que estn corriendo en otros ordenadores de la misma red. En este artculo no se pretende dar una descripcin detallada y rigurosa del protocolo TCP/IP y lo que va alrededor de l. Simplemente se darn unas nociones bsicas de manera informal, con la intencin de que se pueda comprender un pequeo ejemplo de programacin en C. Est, por tanto, orientado a personas que tengan unos conocimientos bsicos de C en Linux y deseen o necesiten comunicar dos programas en C que corren simultneamente en dos ordenadores distintos conectados en red. El ejemplo propuesto puede servir como gua inicial que se pude complicar todo lo que se desee.

LOS SOCKETS
Una forma de conseguir que dos programas se transmitan datos, basada en el protocolo TCP/IP, es la programacin desockets. Un socket no es ms que un "canal de comunicacin" entre dos programas que corren sobre ordenadores distintos o incluso en el mismo ordenador. Desde el punto de vista de programacin, un socket no es ms que un "fichero" que se abre de una manera especial. Una vez abierto se pueden escribir y leer datos de l con las habituales funciones de read() y write() del lenguaje C. Hablaremos de todo esto con detalle ms adelante. Existen bsicamente dos tipos de "canales de comunicacin" o sockets, los orientados a conexin y los no orientados a conexin.

En el primer caso ambos programas deben conectarse entre ellos con un socket y hasta que no est establecida correctamente la conexin, ninguno de los dos puede transmitir datos. Esta es la parte TCP del protocolo TCP/IP, y garantiza que todos los datos van a llegar de un programa al otro correctamente. Se utiliza cuando la informacin a transmitir es importante, no se puede perder ningn dato y no importa que los programas se queden "bloqueados" esperando o transmitiendo datos. Si uno de los programas est atareado en otra cosa y no atiende la comunicacin, el otro quedar bloqueado hasta que el primero lea o escriba los datos. En el segundo caso, no es necesario que los programas se conecten. Cualquiera de ellos puede transmitir datos en cualquier momento, independientemente de que el otro programa est "escuchando" o no. Es el llamado protocolo UDP, y garantiza que los datos que lleguen son correctos, pero no garantiza que lleguen todos. Se utiliza cuando es muy importante que el programa no se quede bloqueado y no importa que se pierdan datos. Imaginemos, por ejemplo, un programa que est controlando la temperatura de un horno y enva dicha temperatura a un ordenador en una sala de control para que ste presente unos grficos de temperatura. Obviamente es ms importante el control del horno que el perfecto refresco de los grficos. El programa no se puede quedar bloqueado sin atender al horno simplemente porque el ordenador que muestra los grficos est ocupado en otra cosa. En el ejemplo y a partir de este momento nos referimos nicamente a sockets TCP. Los UDP son bsicamente iguales, aunque hay pequeas diferencias en la forma de abrirlos y de enviar los mensajes. Puedes ver un ejemplo de programacin de socket UDP.

ARQUITECTURA CLIENTE / SERVIDOR

A la hora de comunicar dos programas, existen varias posibilidades para establecer la conexin inicialmente. Una de ellas es la utilizada aqu. Uno de los programas debe estar arrancado y en espera de que otro quiera conectarse a l. Nunca da "el primer paso" en la conexin. Al programa que acta de esta forma se le conoce como servidor. Su nombre se debe a que normalmente es el que tiene la informacin que sea disponible y la "sirve" al que se la pida. Por ejemplo, el servidor de pginas web tiene las pginas web y se las enva al navegador que se lo solcite. El otro programa es el que da el primer paso. En el momento de arrancarlo o cuando lo necesite, intenta conectarse al servidor. Este programa se denomina cliente. Su nombre se debe a que es el que solicita informacin al servidor. El navegador de Internet pide la pgina web al servidor de Internet. En este ejemplo, el servidor de pginas web se llama servidor porque est (o debera de estar) siempre encendido y pendiente de que alguien se conecte a l y le pida una pgina. El navegador de Internet es el cliente, puesto que se arranca cuando nosotros lo

arrancamos y solicita conexin con el servidor cuando nosotros escribimos, por ejemplo,www.chuidiang.com En el juego del Quake, debe haber un servidor que es el que tiene el escenario del juego y la situacin de todos los jugadores en l. Cuando un nuevo jugador arranca el juego en su ordenador, se conecta al servidor y le pide el escenario del juego para presentarlo en la pantalla. Los movimientos que realiza el jugador se transmiten al servidor y este actualiza escenarios a todos los jugadores. Resumiendo, servidor es el programa que permanece pasivo a la espera de que alguien solicite conexin con l, normalmente, para pedirle algn dato. Cliente es el programa que solicita la conexin para, normalmente, pedir datos al servidor.

LA CONEXIN
Para poder realizar la conexin entre ambos programas son necesarias varias cosas:

Direccin IP del servidor. Cada ordenador de una red tiene asignado un nmero nico, que sirve para identificarle y distinguirle de los dems, de forma que cuando un ordenador quiere hablar con otro, manda la informacin a dicho nmero. Es similar a nuestros nmeros de telfono. Si quiero hablar con mi amigo "Josechu", primero marco su nmero de telfono y luego hablo con l. El servidor no necesita la direccin de ninguno de los dos ordenadores, al igual que nosotros, para recibir una llamada por telfono, no necesitamos saber el nmero de nadie, ni siquiera el nuestro. El cliente s necesita saber el nmero del servidor, al igual que nosotros para llamar a alguien necesitamos saber su nmero de telfono. La direccin IP es un nmero del estilo 192.100.23.4. Todos lo hemos visto en Internet!. En resumidas cuentas, el cliente debe conocer a qu ordenador desea conectarse. En nuestro navegador de Internet facilitamos la direccin IP del servidor al que queremos conectarnos a travs de su nombre (www.chuidiang.com). Obviamente este nombre hay que traducirlo a una direccin IP, pero nuestro navegador e Internet se encargan de eso por nosotros.

Servicio que queremos crear / utilizar. Si llamamos a una empresa, puede haber en ella muchas personas, cada una con su extensin de telfono propia. Normalmente la persona en concreto con la que hablemos nos da igual, lo que queremos es alguien que nos atienda y nos de un determinado "servicio", como recoger una queja, darnos una informacin, tomarnos

nota de un pedido, etc. De la misma forma, en un mismo ordenador pueden estar corriendo varios programas servidores, cada uno de ellos dando un servicio distinto. Por ejemplo, un ordenador puede tener un servidor de Quake y un servidor de pginas web corriendo a la vez. Cuando un cliente desea conectarse, debe indicar qu servicio quiere, igual que al llamar a la empresa necesitamos decir la extensin de la persona con la que queremos hablar o, al menos, decir su nombre o el departamento al que pertenece para que la telefonista nos ponga con la persona adecuada. Por ello, cada servicio dentro del ordenador debe tener un nmero nico que lo identifique (como la extensin de telfono). Estos nmeros son enteros normales y van de 1 a 65535. Los nmero bajos, desde 1 a 1023 estn reservados para servicios habituales de los sistemas operativos (www, ftp, mail, ping, etc). El resto estn a disposicin del programador y sirven para cosas como Quake. Tanto el servidor como el cliente deben conocer el nmero del servicio al que atienden o se conectan. El servidor le indica al sistema operativo qu servicio quiere atender, al igual que en una empresa el empleado recin contratado (o alguien en su lugar) debe informar a la telefonista en qu extensin se encuentra. El cliente, cuando llame a la empresa, debe dar el nmero de extensin (o nombre de empleado), de forma que la telefonista le ponga con la persona adecuada. En el caso del navegador de Internet, estamos indicando el servicio con la www en www.chuidiang.com, servicio de pginas web. Tambin es posible, por ejemplo "ftp.chuidiang.com", si chuidiang.com admite clientes ftp. Nuestro ordenador es lo suficientemente listo como para saber a qu nmero corresponden esos servicios habituales.

EL SERVIDOR
A partir de este punto comenzamos con lo que es la programacin en C de los sockets. Si no tienes unos mnimos conocimientos de C, es mejor que los adquieras antes de seguir. Con C en Unix/Linux, los pasos que debe seguir un programa servidor son los siguientes:

Apertura de un socket, mediante la funcin socket(). Esta funcin devuelve un descriptor de fichero normal, como puede devolverlo open(). La funcin socket() no hace absolutamente nada, salvo devolvernos y preparar un descriptor de fichero que el sistema posteriormente asociar a una conexin en red. Avisar al sistema operativo de que hemos abierto un socket y queremos que asocie nuestro programa a dicho socket. Se consigue mediante la funcin bind(). El sistema todava no atender a las conexiones de clientes, simplemente anota

que cuando empiece a hacerlo, tendr que avisarnos a nosotros. Es en esta

llamada cuando se debe indicar el nmero de servicio al que se quiere atender. Avisar al sistema de que comience a atender dicha conexin de red. Se consigue mediante la funcin listen(). A partir de este momento el sistema operativo anotar la conexin de cualquier cliente para pasrnosla cuando se lo pidamos. Si llegan clientes ms rpido de lo que somos capaces de atenderlos, el sistema operativo hace una "cola" con ellos y nos los ir pasando segn vayamos pidindolo. Pedir y aceptar las conexiones de clientes al sistema operativo. Para ello hacemos una llamada a la funcinaccept(). Esta funcin le indica al sistema operativo que nos d al siguiente cliente de la cola. Si no hay clientes se quedar bloqueada hasta que algn cliente se conecte. Escribir y recibir datos del cliente, por medio de las funciones write() y read(), que son exactamente las mismas que usamos para escribir o leer de un fichero. Obviamente, tanto cliente como servidor deben saber qu datos esperan recibir, qu datos deben enviar y en qu formato. Puedes ver cmo se pueden poner de acuerdo en estos mensajes en el apartado de mensajes.

Cierre de la comunicacin y del socket, por medio de la funcin close(), que es la misma que sirve para cerrar un fichero.

EL CLIENTE
Los pasos que debe seguir un programa cliente son los siguientes:

Apertura de un socket, como el servidor, por medio de la funcin socket() Solicitar conexin con el servidor por medio de la funcin connect(). Dicha funcin quedar bloqueada hasta que el servidor acepte nuestra conexin o bien si no hay servidor en el sitio indicado, saldr dando un error. En esta llamada se debe facilitar la direccin IP del servidor y el nmero de servicio que se desea. Escribir y recibir datos del servidor por medio de las funciones write() y read(). Cerrar la comunicacin por medio de close().

FICHEROS UNIX/LINUX IMPLICADOS

Para la programacin de socket no es estrictamente necesario ningn fichero. Sabiendo la direccin IP y el nmero de servicio, se ponen directamente en cdigo y todo resuelto. Sin embargo, esto no es lo ms cmodo ni lo ms portable de unos ordenadores a otros. Hay dos ficheros en Unix/Linux que nos facilitan esta tarea, aunque hay que tener permisos de root para modificarlos. Estos ficheros seran el equivalente a una agenda de telfonos, en uno tenemos apuntados el nombre de la empresa con su nmero de telfono y en el otro fichero el nombre de la persona y su extensin (EmpresaGorda, tlfn 123.456.789; JoseGordo, extensin 2245; ...)

/etc/hosts : Esta es la agenda en la que tenemos las empresas y sus nmeros de telfono. En este fichero hay una lista de nombres de ordenadores conectados en red y direccin IP de cada uno. Habitualmente en el /etc/hosts del cliente se suele colocar el nombre del servidor y su direccin IP. Luego, desde programa, se hace una llamada a la funcingethostbyname(), a la que pasndole el nombre del ordenador como una cadena de caracteres, devuelve una estructura de datos entre los que est la direccin IP. Una lnea de lo que puede aparecer en este fichero es la siguiente, en el que vemos la direccin IP y el nombre del ordenador que nos da el servicio de Quake. 192.30.10.1 Ordenador_Quake En Windows, este fichero suele encontrarse en C:\WINNT\system32\drivers\etc\hosts. /etc/services : Este fichero es el equivalente a la agenda donde tenemos apuntados los distintos departamentos/personas de la empresa y sus nmeros de extensin telefnica. En este fichero hay una lista de servicios disponibles, indicando nombre de servicio, nmero de servicio y tipo (ftp/udp). Tanto el servidor como el cliente deben tener en este fichero el servicio que estn atendiendo / solicitando con el mismo nmero y tipo de servicio. El nombre puede ser distinto, igual que cada uno en su agenda pone el nombre que quiere, pero no es lo habitual. Desde programa, tanto cliente como servidor, deben hacer una llamada a la funcin getservbyname(), a la que pasndole el nombre del servicio, devuelve una estructura de datos entre los que est el nmero de servicio y el tipo. Un ejemplo de lo que puede aparecer en un fichero /etc/services es el siguiente, en el que vemos en cada lnea nombre del servicio, nmero / tipo y un comentario opcional detrs del smbolo #. "Casualmente", se ve el servicio www, cuyo nmero de servicio conocido por todos los ordenadores de Internet, es el 80. tftp 69/udp gopher 70/tcp # Internet Gopher gopher 70/udp rje 77/tcp finger 79/tcp www 80/tcp http # Worldwide Web HTTP www 80/udp # HyperText Transfer Protocol link 87/tcp ttylink En Windows, el ficherito de marras est en C:\WINNT\system32\drivers\etc\services

EJEMPLO
Sentadas las bases de los sockets, vamos a ver un pequeo ejemplo.zip de programa servidor y cliente, realizado con C en Linux. El servidor esperar la conexin del cliente. Una vez conectados, se enviarn una cadena de texto el uno al otro y ambos escribirn en pantalla la cadena recibida. Para ejecutar el ejemplo no es necesario tener dos ordenadores. Se pude ejecutar el servidor desde una ventana y el cliente desde otra. En la ventana del servidor veremos la cadena que ha enviado el cliente y al revs.

DETALLES DEL SERVIDOR

En este apartado vamos a detallar las llamadas a las funciones del servidor que indicamos anteriormente. Explicaremos con cierto detalle qu parmetros se deben pasar y cual es el resultado de dichas llamadas. En primer lugar el servidor debe obtener el nmero del servicio al que quiere atender, haciendo la llamada agetservbyname(). Esta funcin devuelve una estructura (en realidad puntero a la estructura) en el que uno de sus campos contiene el nmero de servicio solicitado. struct servent Puerto; /* Estructura devuelta */ /* La llamada a la funcin */ Puerto = getservbyname ("Nombre_Servicio", "tcp"); Los parmetros de la funcin son dos cadenas de caracteres. La primera es el nombre del servicio, tal cual lo escribimos en el fichero /etc/services. El segundo es el tipo de protocolo que queremos usar. "tcp" o "udp", Dentro de lo que devuelve la funcin, el nmero de servicio que nos interesa est en un campo de Puerto: Puerto->s_port Ya tenemos todos los datos que necesita el servidor para abrir el socket, as que procedemos a hacerlo. El socket se abre mediante la llamada a la funcin socket() y devuelve un entero que es el descriptor de fichero o 1 si ha habido algn error. int Descriptor; Descriptor = socket (AF_INET, SOCK_STREAM, 0); if (Descriptor == -1) printf ("Error\n");

El primer parmetro es AF_INET o AF_UNIX para indicar si los clientes pueden estar en otros ordenadores distintos del servidor o van a correr en el mismo ordenador. AF_INET vale para los dos casos. AF_UNIX slo para el caso de que el cliente corra en el mismo ordenador que el servidor, pero lo implementa de forma ms eficiente. Si ponemos AF_UNIX, el resto de las funciones vara ligeramente. El segundo parmetro indica si el socket es orientado a conexin (SOCK_STREAM) o no lo es (SOCK_DGRAM). De esta forma podremos hacer sockets de red o de Unix tanto orientados a conexin como no orientados a conexin. El tercer parmetro indica el protocolo a emplear. Habitualmente se pone 0. Si se ha obtenido un descriptor correcto, se puede indicar al sistema que ya lo tenemos abierto y que vamos a atender a ese servicio. Para ello utilizamos la funcin bind(). El problema de la funcin bind() es que lleva un parmetro bastante complejo que debemos rellenar. struct sockaddr_in Direccion; Direccion.sin_family = AF_INET; Direccion.sin_port = Puerto->s_port; Direccion.sin_addr.s_addr =INADDR_ANY; if (bind (Descriptor, (struct sockaddr *)&Direccion, sizeof (Direccion)) == -1) { printf ("Error\n"); } El parmetro que necesita es una estructura sockaddr. Lleva varios campos, entre los que es obligatorio rellenar los indicados en el cdigo. sin_family es el tipo de conexin (por red o interna), igual que el primer parmetro de socket(). sin_port es el nmero correspondiente al servicio que obtuvimos con getservbyname(). El valor est en el campos_port de Puerto. Finalmente sin_addr.s_addr es la direccin del cliente al que queremos atender. Colocando en ese campo el valorINADDR_ANY, atenderemos a cualquier cliente. La llamada a bind() lleva tres parmetros:

Descriptor del socket que hemos abierto Puntero a la estructura Direccion con los datos indicados anteriormente. La estructura admitida por este parmetro es general y valida para cualquier tipo de socket y es del tipo struct sockaddr. Cada socket concreto lleva su propia

estructura. Los AF_INET como este caso llevan struct sockaddr_in, los AF_UNIX llevan la estructura struct sockaddr_un. Por eso, a la hora de pasar el parmetro, debemos hacer un "cast" al tipo struct sockaddr. La operacin cast es un pequeo truco que admite C. Cuando tenemos un dato de un determinado tipo, por ejemplo, un entero int, es posible convertirlo a otro tipo que nos venga mejor poniendo el nuevo tipo deseado entre parntesis y detrs la variable del tipo no deseado. Por ejemplo, para convertir de entero a flotante: Variable_Flotante = (float)Variable_Entera;

Esto es vlido siempre y cuando los dos tipos tengan algn tipo de relacin y sea posible convertir uno en el otro. En nuestro ejemplo las estructuras sockaddr_in y sockaddr_un pueden convertirse sin problemas al tipo sockaddr.

Longitud de la estructura Direccion.

La funcin devuelve -1 en caso de error. Una vez hecho esto, podemos decir al sistema que empiece a atender las llamadas de los clientes por medio de la funcinlisten() if (listen (Descriptor, 1) == -1) { printf ("Error\n"); } La funcin listen() admite dos parmetros, afortunadamente sencillos:

Descriptor del socket. Nmero mximo de clientes encolados. Supongamos que recibimos la conexin de un primer cliente y le atendemos. Mientras lo estamos haciendo, se conecta un segundo cliente, al que no atendemos puesto que estamos ejecutando el cdigo necesario para atender al primero. Mientras sucede todo esto, llega un tercer cliente que tambin se conecta. Estamos atendiendo al primero y tenemos dos en la "lista de espera". El segundo parmetro de listen()indica cuntos clientes mximo podemos tener en la lista de espera. Cuando un cliente entra en la lista de espera, su llamada a connect() queda bloqueada hasta que se le atiende. Si la lista de espera est llena, el nuevo cliente que llama a connect() recibir un error de dicha funcin. Algo as como un "vuelva usted maana".

La funcin listen() devuelve 1 en caso de error.

Con todo esto ya slo queda recoger los clientes de la lista de espera por medio de la funcin accept(). Si no hay ningn cliente, la llamada quedar bloqueada hasta que lo haya. Esta funcin devuelve un descriptor de fichero que es el que se tiene que usar para "hablar" con el cliente. El descriptor anterior corresponde al servicio y slo sirve para encolar a los clientes. Digamos que el primer descriptor es el aparato de telfono de la telefonista de la empresa y el segundo descriptor es el aparato de telfono del que est atendiendo al cliente. struct sockaddr Cliente; int Descriptor_Cliente; int Longitud_Cliente; Descriptor_Cliente = accept (Descriptor, &Cliente, &Longitud_Cliente); if (Descriptor_Cliente == -1) { printf ("Error\n"); } La funcin accept() es otra que lleva un parmetro complejo, pero que no debemos rellenar. Los parmetros que admite son

Descriptor del socket abierto. Puntero a estructura sockaddr. A la vuelta de la funcin, esta estructura contendr la direccin y dems datos del ordenador cliente que se ha conectado a nosotros. Puntero a un entero, en el que se nos devolver la longitud til del campo anterior.

La funcin devuelve un 1 en caso de error. Si todo ha sido correcto, ya podemos "hablar" con el cliente. Para ello se utilizan las funciones read() y write() de forma similar a como se hara con un fichero. Supongamos que sabemos que al conectarse un cliente, nos va a mandar una cadena de cinco caracteres. Para leerla sera int Leido = 0;/* Nmero de caracteres ledos hasta el momento */ int Aux = 0; /* Guardaremos el valor devuelto por read() */ int Longitud = 5; /* Nmero de caracteres a leer */ char Datos[5]; /* Buffer donde guardaremos los caracteres */ /* Bucle hasta que hayamos ledo todos los caracteres que estamos esperando */

while (Leido < Longitud) { /* Se leen los caracteres */ Aux = read (Descriptor, Datos + Leido, Longitud - Leido); /* Si hemos conseguido leer algn carcter */ if (Aux > 0) { /* Se incrementa el nmero de caracteres ledos */ Leido = Leido + Aux; } else { /* Si no se ha ledo ningn carcter, se comprueba la condicin de socket cerrado */ if (Aux == 0) { printf ("Socket cerrado\n"); } else /* y la condicin de error */ if (Aux == -1) { printf ("Error\n"); } } } Parece un poco complicado. A ver si somos capaces de aclararlo. La funcin read() admite como parmetros

Descriptor del fichero / socket del que se quiere leer Puntero a char donde se almacenarn los datos ledos Nmero de caracteres que se quieren leer.

La funcin devuelve 1 si ha habido error, 0 si el socket se ha cerrado o el fichero ha llegado a fin de fichero, o bien el nmero de caracteres si se ha conseguido leer alguno. En el caso de socket, si no hay errores y el socket sigue abierto y no hay caracteres para leer (no los han enviado desde el otro extremo), la llamada queda bloqueada. En el caso de leer de socket, tenemos un pequeo problema aadido y es que se leen los caracteres disponibles y se vuelve. Si pedimos 5 caracteres, entra dentro de lo posible que read() lea 3 caracteres y vuelva, sin dar error, pero sin leer todos los que hemos pedido. Por ese motivo, al leer de socket es casi obligatorio (totalmente obligatorio si

queremos transmitir muchos caracteres de un solo golpe) el leer con un bucle, comprobando cada vez cuantos caracteres se han ledo y cuantos faltan. Por este motivo, read() va dentro de un while() en el que se mira si el total de caracteres ledos es menor que el nmero de caracteres que queremos leer. La lectura del read() debe adems pasar como parmetro cada vez la posicin dentro del buffer de lectura en la que queremos situar los caracteres (Datos + Leido ) y la longitud de caracteres a leer,(Longitud - Leido ) que tambin cambia segn se va leyendo. En cuanto a escribir caracteres, la funcin write() admite los mismos parmetros, con la excepcin de que el buffer de datos debe estar previamente relleno con la informacin que queremos enviar. Tiene el mismo problema, que escribe lo que puede y vuelve, pudiendo no haber escrito toda la informacin, por lo que hay que hacer un trozo de cdigo similar. int Escrito = 0; /* Nm. de caracteres que ya se han escrito */ int Aux = 0; /* Nmero de caracteres escritos en cada pasada */ int Longitud = 5; /* Total de caracteres a escribir */ char Datos[] = "Hola"; /* El 5 carcter es el \0 del final */ /* Bucle mientras no se hayan escrito todos los caracteres deseados */ while (Escrito < Longitud) { /* Se escriben los caracteres */ Aux = write (Descriptor, Datos + Escrito, Longitud Escrito); /* Si hemos conseguido escribir algn carcter */ if (Aux > 0) { /* Incrementamos el nmero de caracteres escritos */ Escrito = Escrito + Aux; } else { /* Si no hemos podido escribir caracteres, comprobamos la condicin de socket cerrado */ if (Aux == 0) { printf ("Socket cerrado\n"); } else /* y la condicin de error */

if (Aux == -1) { printf ("Error\n"); } } } En un programa ms serio, ni el cliente ni el servidor saben a priori qu es lo que tienen que leer. Normalmente hay una serie de mensajes que los dos conocen precedidos de una "cabecera", en la que suelen ir campos del estilo "Identificador de mensaje" y "Longitud del mensaje". De esta forma, primero se leen estos dos campos y sabiendo qu mensaje va a llegar y su longitud, se procede a leerlo. A la hora de escribir, primero se manda la cabecera diciendo qu mensaje se va a mandar y qu longitud tiene, y luego se manda el mensaje en s. Una vez que se han ledo / enviado todos los datos necesarios, se procede a cerrar el socket. Para ello se llama a la funcin close(), que admite como parmetro el descriptor del socket que se quiere cerrar. close (Descriptor_Cliente); Normalmente el servidor cierra el descriptor del cliente (Descriptor_Cliente), no el del socket (Descriptor), ya que este se suele dejar abierto para volver a realizar una llamada a accept() y sacar al siguiente cliente de la cola. Es como si una vez que un amable seor de una empresa nos ha atendido le dice a la telefonista que no atienda ms el telfono. Esas cosas slo las hacen los jefes.

DETALLES DEL CLIENTE

Puesto que la escritura / lectura y cierre de sockets es idntica a la del servidor, nicamente contaremos la apertura del socket que, cmo no, es ms compleja que la del servidor, puesto que adems del nmero de servicio, debe obtener ladireccin IP del servidor. En primer lugar, como en el servidor, obtenemos el nmero del servicio. struct servent *Puerto; Puerto = getservbyname ("Nombre_Servicio", "tcp"); if (Puerto == NULL) {

printf ("Error\n"); } Despus obtenemos la direccin IP del servidor. El parmetro que hay que pasar es una cadena de caracteres con elnombre del servidor, tal cual lo pusimos en el fichero /etc/hosts. Devuelve los datos del servidor en una estructura hostent. struct hostent *Host; Host = gethostbyname ("Nombre_Servidor"); if (Host == NULL) { printf ("Error\n"); } Una vez que tenemos todos los datos necesarios, abrimos el socket igual que en el servidor. Descriptor = socket (AF_INET, SOCK_STREAM, 0); if (Descriptor == -1) { printf ("Error\n"); } Ya tenemos todo lo necesario para solicitar conexin con el servidor. El parmetro de connect() ya es conocido y slo tenemos que rellenarlo, igual que en bind() del servidor. struct sockaddr_in Direccion; Direccion.sin_family = AF_INET; Direccion.sin_addr.s_addr = ((structin_addr*)(Host->h_addr))>s_addr; Direccion.sin_port = Puerto->s_port; if (connect (Descriptor, (struct sockaddr *)&Direccion,sizeof (Direccion)) == -1) { printf ("Error\n"); } La nica novedad es que la direccin del servidor se coloca en Direccion.sin_addr.s_addr y no como pusimos antes,INADDR_ANY. Dicha direccin

la tenemos dentro de la estructura obtenida con gethostbyname(), en el campo((structin_addr*)(Host->h_addr))->s_addr. Vaya por Dios!, Menudo campo!. Nos pasa como dijimos antes, los tipos no son exactamente los mismos y tenemos estructuras anidadas en estructuras, con lo que la sintaxis queda de esa forma tan horrible. La explicacin es la siguiente: La estructura Host tiene un campo h_addr, de ah la parte Host->h_addr. Este campo no es del tipo deseado, as que se convierte con un cast a struct in_addr, de ah lo de (struct in_addr*)(Host->h_addr). Bueno, pues todo esto es a su vez una estructura, de la que nos interesa el campo s_addr, as que metemos todo entre parntesis, cogemos el campo y nos queda lo que tenemos puesto en el cdigo ((structin_addr*)(Host->h_addr))->s_addr El resto es exactamente igual que en el servidor.

ALGUNAS CONSIDERACIONES Puede haber variaciones con otro tipo de sockets.

El ejemplo aqu expuesto funciona correctamente, pero si se quieren hacer otras cosas un poco ms serias hay que tener en cuenta varios puntos que indicamos aqu por encima. En primer lugar el ejemplo es con sockets orientados a conexin y de tipo AF_INET ( para que pueda funcionar con servidor en un ordenador y cliente en otro). Si cambiamos de tipo de socket o de conexin, la idea bsica es la misma, pero la sintaxis del cdigo cambia ligeramente. Antes de realizar dicho cambio, conviene saber qu cosas hay que cambiar en el cdigo. Un ejemplo claro, si usamos sockets no orientados a conexin, sobra la llamada a connect() que hace el cliente y la de accept() que hace el servidor, pero en su lugar el cliente debe hacer una llamada a bind(). Puedes ver aqu un ejemplo de socket udp. Si usamos sockets AF_UNIX, sobra pedir la direccin IP del servidor, ya que es el mismo ordenador en el que corren ambos programas.

Organizacin de los enteros.

En el mundo de los ordenadores, estn los micros de intel (y los que los emulan) y los dems. La diferencia, entre otras muchas, es que organizan los enteros de forma distinta; uno pone antes el byte ms significativo del entero y el otro lo pone al final. Si conectamos dos ordenadores con sockets, una de las informaciones que se transmiten en la conexin es un entero con el nmero de servicio. Ya la hemos liado! hay micros que no se entienden entre s. Para evitar este tipo de problemas estn la funciones htons(), htonl() y similares. Esta funcin convierte los enteros a un formato "standard" de red, con lo que se

garantiza que nos podemos entender con cualquier entero. Eso implica que algunos de los campos de las estructuras que hemos rellenado arriba, debemos aplicarles esta funcin antes de realizar la conexin. Si enviamos despus enteros con write() o los leemos con read(), debemos convertirlos y desconvertirlos a formato red. Puedes ver un ejemplo de todo esto al conectar un socket en Java con uno en C. Aunque ambos corran en el mismo ordenador, java tiene su propia mquina virtual, por lo que es como si corriera en su propio microprocesados, distinto de los pentium.

Atencin al cliente
Una tcnica habitual en el servidor es que cree nuevos procesos (o hilos) para cada cliente. Puedes echar un ojo a la funcin fork(). Si no se quieren crear procesos, se puede usar la funcin select(). A esta funcin se le dicen todos los sockets que estamos atendiendo y cuando la llamemos, nos quedamos bloqueados hasta que en alguno de ellos haya "actividad". Esto nos evita estar en un bucle mirando todos los sockets clientes uno por uno para ver si alguno quiere algo. Se suelen crear procesos con fork() cuando el servidor no es capaz de atender todas las peticiones de los clientes a suficiente velocidad. Al tener un proceso dedicado a cada cliente, se puede atender a varios "simultaneamente". Se suele usar select() cuando podemos atender a los clientes lo suficientemente rpido como para hacerlo de uno en uno, sin hacer esperar demasiado a nadie. Poniendo un ejemplo, si en una ventanilla de un banco "gotean" los clientes y se despacha rpido a cada uno, basta con una nica ventanilla y una persona en ella que "duerma disimuladamente" mientras llega un cliente. Si los clientes llegan a mogolln y se tarda en atender a cada uno de ellos, es mejor que haya muchas ventanillas, lo ideal, una por cada cliente.

Ejemplo de Utilizacion de Headers (http/1.1) Descripcin

void header ( string $string [, bool $replace = true [, int $http_response_code ]] )
header() es usado para enviar encabezados HTTP sin formato. Ver la especificacin HTTP/1.1 specification para ms informacin sobre encabezados HTTP. Recuerde que header() debe ser llamado antes de mostrar nada por pantalla, etiquetas HTML, lneas en blanco desde un fichero o desde PHP. Es un error muy comn leer cdigo con funciones comoinclude() o require(), u otro tipo de funciones de acceso de ficheros que incluyen espacios o lneas en blanco que se muestran antes de llamar a la funcin header(). Sucede el mismo problema cuando se utiliza un solo fichero PHP/HTML. <html> <?php /* Esto producir un error. Fjate en el html * que se muestra antes que la llamada a header() */ header('Location: http://www.example.com/'); ?>
Report a bug

Parmetros
string

El encabezado en formato cadena. Existen dos casos especiales en el uso de header. El primero el encabezado que empieza con la cadena "HTTP/" (las maysculas no son importantes), es utilizado para averiguar el cdigo de status HTTP a enviar. Por ejemplo, si se tiene Apache configurado para usar un script en PHP para controlar las peticiones a ficheros no encontrados (usando la directivaErrorDocument), querr asegurarse de que el script genera el cdigo de status que corresponde. <?php header("HTTP/1.0 404 Not Found"); ?>

Para el uso de FastCGI deb usarse la siguiente respuesta para un 404:

<?php header("Status: 404 Not Found"); ?> El segundo caso especial es el encabezado "Location:" No solamente enva el encabezado al navegador, sino que tambin devuelve el cdigo de status (302) REDIRECT al navegador a no ser que el cdigo de status 201 o 3xx ya haya sido enviado. <?php header("Location: http://www.example.com/"); /* Redireccin del navega dor */ /* Asegurndonos de que el cdigo interior no ser ejecutado cuando se realiza la redireccin. */ exit; ?>

replace

El parmetro opcional replace indica cuando el encabezado debe reemplazar un encabezado previo similar o aadir un segundo encabezado del mismo tipo. Por defecto lo reemplazar, pero si se pasa FALSE como segundo argumento se puede forzar mltiples encabezados del mismo tipo. Por ejemplo: <?php header('WWW-Authenticate: Negotiate');

header('WWW-Authenticate: NTLM', false); ?>

http_response_code

Fuerza el cdigo de respuesta HTTP a un valor especfico. Observe que este parmetro solamente tiene efecto si string no est vaco. Ejemplo Dilogo de descarga
Si se quiere preguntar al usuario si quiere guardar los datos que se estn enviando, como un fichero PDF generado, puede usarse el encabezado ContentDisposition para proporcionar un nombre de fichero recomendado y forzar al navegador el mostarar el dilogo para guardar el fichero. <?php // Vamos a mostrar un PDF header('Content-type: application/pdf'); // Se llamar downloaded.pdf header('Content-Disposition: attachment; filename="downloaded.pdf"'); // La fuente de PDF se encuentra en original.pdf readfile('original.pdf'); ?>