`X-SendFile` is a header that can be sent from a scripting language like PHP, Python, Perl, Ruby via CGI (or similar) or a FastCGI app that is preprocessed by the server (without sending to the client) and that tells the server that it has to server a static file instead of outputing the output generated by the CGI. Let's suppose that we want to send a big file from a CGI via authentication. The tradictional way has been to set the header `Content-Type` and directly send the binary data. Some sophisticated systems even process the HTTP headers to soupport partial file sending. But each of these kind of requests require to have a script being in memory and executing, communicating with the server at the same time that it is doing as a bridge sending the files to the client. Well. It happens that you can just send the `X-SendFile` header specifying the path to the file that we want to send and to finalize the CGI/FastCGI request. The script is only in memory the time required to verify the authentication and to send a single header to the server. This is by far much more efficient. We can even save a session indicating that the user is authentication in order to avoid having to check the credentials each time. The user's browser will send the cookie and we will be able to access the session pretty fast. The server we will be in charge of processing the header to send the user's requested data: **Using PHP:** ```php header('X-SendFile: /path/to/my/file'); ``` The `X-SendFile` header is implemented by popular servers, either directly in the core like in [lighttpd](http://redmine.lighttpd.net/wiki/1/X-LIGHTTPD-send-file) or [nginx](http://wiki.nginx.org/XSendfile), or as part of an extension like [mod_xsendfile para apache](https://tn123.org/mod_xsendfile/). Each server handles the header in a different way, allowing to specify configuration parameters and security restrictions per configuration. If we plan to use it, we should determine which server are we using, and check the server's documentation.

`X-SendFile` es una cabecera que puede mandar un lenguaje de scripting como PHP, Python, Perl, Ruby mediante CGI (o equivalente) o una aplicación FastCGI y que es preprocesada por el servidor (sin llegarse a mandar al cliente) y que indica al servidor que tiene que servir un archivo estático en lugar de mandar la salida producida por el CGI. Supongamos que queremos mandar un archivo grande desde un CGI mediante autentificación. La forma tradicional ha sido siempre establecer la cabecera Content-Type y mandar los datos binarios en churro. Algunos sistemas sofisticados incluso parseaban las cabeceras HTTP para soportar mandar trozos del archivo. Sin embargo cada una de estas peticiones requiere tener un script usando memoria el rato, comunicándose con el servidor que a su vez hace de puente mandando los datos al cliente. Pues bien. Con `X-SendFile` basta con mandar esta cabecera indicando el path al archivo que queremos mandar y finalizar la petición GGI/FastCGI. El script está en memoria el tiempo que le cuesta verificar la autentificación y mandar una única cabecera al servidor. Y esto es mucho más eficiente con diferencia. Incluso podemos guardar una sesión indicando que el usuario está autenticado para evitar tener que comprobar las credenciales cada vez. El navegador del usuario mandará al cookie correspondiente y podremos acceder a la sesión de forma rápida. El servidor ya se encargará de procesar las cabeceras para enviar los datos que el usuario pida: **En PHP:** ```php header('X-SendFile: /path/to/my/file'); ``` La cabecera `X-SendFile` la implementan los servidores populares, o bien en el core como es en el caso de [lighttpd](http://redmine.lighttpd.net/wiki/1/X-LIGHTTPD-send-file) y [nginx](http://wiki.nginx.org/XSendfile), o bien como parte de una extensión como en el caso de [mod_xsendfile para apache](https://tn123.org/mod_xsendfile/). Cada servidor gestiona la cabecera de una forma, permitiendo especificar parámetros de configuración y restricciones de seguridad por configuración Lo suyo para usarlo es ver el servidor que estamos usando y leer la documentación pertinente.