2012-05-03 17 views
6

Actualmente, Rails 3 enruta una solicitud HEAD a la ruta GET coincidente. Hay una cabeza? método en la solicitud, pero en devuelve falso y la solicitud actúa como una solicitud de obtención. ¿Puedo detectar si la solicitud es una solicitud HEAD?HEAD Solicitudes HTTP en Rails 3

Razonamiento: entiendo que una solicitud HEAD debe devolver los mismos encabezados EXACTOS que el get, por lo que Rails desea realizar el GET completo y luego afeitarse el cuerpo. Sin embargo, puedo cumplir con esta solicitud sin emitir las mismas llamadas a bases de datos, etc. que el GET haría. ¿Esto tiene sentido?

+0

Es posible que deba publicar algún código relevante. ¿La cabeza? El método debe volverse verdadero para las solicitudes HEAD (http://api.rubyonrails.org/classes/ActionDispatch/Request.html#method-i-head-3F) – rjk

Respuesta

2

¿Puede utilizar el request.head? Método para averiguar si se trata de una petición HEAD:

http://api.rubyonrails.org/classes/ActionDispatch/Request.html#method-i-head-3F

Una vez que haya determinado que es, también puede utilizar la cabeza del controlador() método en lugar de la típica render:

http://guides.rubyonrails.org/layouts_and_rendering.html#using-head-to-build-header-only-responses

Así que simplemente verificaría request.head? antes de molestar con las actividades de la base de datos. A continuación, utilice

head :ok, :custom_header => 'value' 
+0

Por lo tanto, he aquí una esencia con algo de [más información] (https://gist.github.com/2594991) Puede ver que HEAD se enruta al GET my Rails, momento en el cual la solicitud dice que es un GET. Probé la cabeza ?, pero no puedo conseguir que indique que es una solicitud HEAD. –

1
def index 
    if request.head? 
    head :created 
    else 
    Rails.logger.info "Derp #{request.method}" 
    end 
end 

Hmm. El método de controlador anterior funciona como esperaba en Ruby v1.9.3-p194 y Rails v3.2.3; El cuerpo de respuesta sin respuesta 201 para las solicitudes HEAD y 200's w/para las GET.

+0

Estoy en 1.9.2 y Rails 3.1.4 ... Estoy completamente preparado para estar haciendo algo mal. Tendré que investigar más ... Gracias. –

+0

Entonces, creo que la respuesta real es que los rieles fuerzan a la solicitud HEAD mediante la misma acción que maneja GET que es b/c para generar el ETag. Si HEAD hizo algo diferente, (probablemente) rompería el caché del lado del cliente. Como tal, las llamadas exactas tienen que ser emitidas ... No me gusta que realmente no puedo usar la cabeza? saber que es una solicitud HEAD, pero yo (creo que) entiendo el razonamiento. –

4

Tuve este problema exacto. Resulta que habilitar el almacenamiento en caché causa esto. ¿Desea apagar el almacenamiento en caché en su entorno y #head? funcionará como se espera

El problema es que Rack :: Cache convierte las solicitudes HEAD en solicitudes GET para que puedan almacenarse en caché. Podría decirse que este es el comportamiento correcto, pero interfirió con mi aplicación.