Diferencia entre carriles SEND_DATA y send_file, con el ejemplo

Question

Puede explicar, ¿cuál es la diferencia entre send_data y send_file.

¿Cuál es el mejor para streaming y proceso de descarga de archivos?.

Answer 1

send_data(_data_, options = {}) 
send_file(_path_, options = {}) 

diferencia principal aquí es que se dejan pasar los datos (código binario o lo que sea) con send_data PATH o archivo con send_file.

Por lo que puede generar algunos datos y enviarlos como un texto en línea o como un archivo adjunto sin generar archivo en su servidor a través de send_data. O puede enviar archivos listos con send_file

data = "Hello World!" 
send_data(data, :filename => "my_file.txt") 

o

data = "Hello World!" 
file = "my_file.txt" 
File.open(file, "w"){ |f| f << data } 
send_file(file) 

Para perfomance de que es mejor para generar el archivo una vez y luego enviarlo como tantas veces como se desee. Entonces send_file se ajustará mejor.

Para la transmisión, por lo que yo entiendo, ambos de estos métodos utilizan el mismo grupo de opciones y configuraciones, lo que puede utilizar X-Enviar o lo que sea.

UPD

send_data y guardar el archivo:

data = "Hello World!" 
file = "my_file.txt" 
File.open(file, "w"){ |f| f << data } 
send_data(data) 

Answer 2

send_file puede ser más rápido que send_data

Como fl00r mentioned, send_file toma un camino, y send_data los datos.

Por lo tanto send_file es un subconjunto de send_data, ya que necesita un archivo en el sistema de archivos: se podría, por supuesto, acaba de leer el archivo y utilizar send_data en él. Pero send_file puede ser más rápido, por lo que es una compensación de rendimiento/generalidad.

send_file puede ser más rápido, ya que puede enviar la cabecera X-Sendfile en Apache (X-Accel-Redirect en Nginx) en lugar del contenido del archivo, ya que conoce el camino.

Esta cabecera es consumida por el proxy inverso (Apache o Nginx) que normalmente pasa por delante de los carriles en una configuración de producción.

Si está presente en la respuesta, el proxy inverso ignora la mayor parte de la respuesta actual y crea una nueva que devuelve el archivo en la ruta especificada.

Client <---> Internet <---> Reverse proxy <---> Rails 

Esto es mucho más eficiente, ya que el proxy inverso está altamente especializado en servir archivos estáticos, y puede hacer que sea mucho más rápido que los carriles (que no envía los datos del archivo si se enviará).

El caso de uso típico de send_file es cuando desea controlar el permiso de acceso de los archivos estáticos: no puede ponerlos en /public o de lo contrario se publicarán antes de que Rails tenga la oportunidad de decidir. Esto se discute en: Protecting the content of public/ in a Rails app

Para utilizar las cabeceras , hay que añadir:

config.action_dispatch.x_sendfile_header = "X-Sendfile" # for apache 
config.action_dispatch.x_sendfile_header = 'X-Accel-Redirect' # for nginx 

a confing/initializers/production.rb (noapplication.rb, ya que en el desarrollo no tiene un servidor proxy y desea send_file para enviar realmente los datos).

se discute en el Asset Pipeline Guide.