2012-05-03 24 views
6

Rails 3 invia attualmente una richiesta HEAD alla route GET corrispondente. C'è una testa? metodo sulla richiesta, ma in return false e la richiesta si comporta come una richiesta get. Posso rilevare se la richiesta è una richiesta HEAD?Richieste HTTP HEAD in Rails 3

Ragionamento: ottengo che una richiesta HEAD restituisca le stesse intestazioni EXACT del get, quindi Rails vuole eseguire l'intero GET e quindi radere il corpo. Tuttavia, posso conformarmi a questa richiesta senza emettere le stesse chiamate DB, ecc. Che il GET farebbe. Ha senso ciò?

+0

Potrebbe essere necessario inserire del codice pertinente. La testa? il metodo dovrebbe restituire true per le richieste HEAD (http://api.rubyonrails.org/classes/ActionDispatch/Request.html#method-i-head-3F) – rjk

risposta

2

È possibile utilizzare request.head? metodo per scoprire se si tratta di una richiesta HEAD:

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

Una volta stabilito che è, è anche possibile utilizzare la testa del controllore() il metodo al posto del tipico render:

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

Quindi dovrei semplicemente controllare request.head? prima di preoccuparti delle attività del database. Quindi utilizzare

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

Quindi, ecco un elenco con alcune [altre informazioni] (https://gist.github.com/2594991) È possibile vedere che l'HEAD viene instradato su GET my Rails, a quel punto la richiesta dice che è un GET. Ho provato la testa ?, ma non riesco a farlo per indicare che si tratta di una richiesta HEAD. –

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

Hmm. Il metodo del controller sopra funziona come mi aspetto su Ruby v1.9.3-p194 e Rails v3.2.3; 201's w/o body di risposta per le richieste HEAD e 200 w/per GET.

+0

Sono su 1.9.2 e Rails 3.1.4 ... Sono completamente preparato a fare qualcosa di sbagliato. Dovrò indagare ulteriormente ... Grazie. –

+0

Quindi, penso che la vera risposta sia che le rotaie costringono la richiesta HEAD alla stessa azione che gestisce GET è b/c che deve generare l'ETag. Se HEAD avesse fatto qualcosa di diverso, avrebbe (probabilmente) interrotto il caching sul lato client. Come tale, le chiamate esatte devono essere emesse .... Non mi piace che non posso davvero usare la testa? per sapere che è una richiesta HEAD, ma io (penso di averlo) capisco il ragionamento. –

4

Ho avuto questo problema esatto. Si scopre che abilitare il caching lo fa. Disattiva la memorizzazione nella cache nel tuo ambiente e #head? funzionerà come previsto

Il problema è che Rack :: Cache trasforma le richieste HEAD in richieste GET in modo che possano essere memorizzate nella cache. Questo è probabilmente il comportamento corretto, ma ha interferito con la mia applicazione.