mod_php rispetta correttamente le richieste HEAD?

Question

L'RFC HTTP/1.1 stabilisce che "Il metodo HEAD è identico a GET tranne che il server NON DEVE restituire un messaggio nella risposta". So che Apache onora la RFC ma i moduli non devono. La mia domanda è, mod_php5 onora questo?

Il motivo che mi chiedo è perché ho appena imbattuto in un articolo dicendo che gli sviluppatori PHP dovrebbero controllare questo se stessi con:

if (stripos($_SERVER['REQUEST_METHOD'], 'HEAD') !== FALSE) { 
     exit(); 
    } 

Ho cercato su google un secondo e non molto alzato, diverso da alcune persone dicendo che cercano a cose strane come mod_rewrite/redirect dopo aver ricevuto le richieste HEAD e qualche vecchio baco da 2002 come sostenendo che mod_php eseguiva ancora il resto dello script di default. Così ho appena eseguito un test rapido utilizzando PECL :: HTTP per eseguire

http_head('http://mysite.com/test-head-request.php'); 

pur avendo:

<?php error_log('REST OF SCRIPT STILL RAN'); ?> 

nel test-testa-request.php per vedere se il resto dello script ancora eseguito e non lo fece.

Immagino che dovrebbe essere sufficiente per sistemarlo, ma voglio ottenere più feedback e forse contribuire a chiarire la confusione per chiunque altro si sia interrogato su questo. Quindi, se qualcuno lo sa dalla testa (non è un gioco di parole) o ha le convenzioni che usano per ricevere le richieste HEAD, sarebbe fantastico. Altrimenti, prenderò in anticipo la sorgente C e risponderò in un commento con i miei risultati. Grazie.

Answer 1

Il metodo HEAD è identico a GET con la differenza che il server NON DEVE restituire un messaggio nella risposta.

Ecco perché è necessario eseguire il controllo non. I client devono avere la certezza che le richieste di HEAD procedano come se fosse stato emesso un GET (connessione al database, elaborazione, ecc ...).

Addendum:

Quando si esegue

HEAD /test.php?a=3 HTTP/1.1 
Host: somesite.com 

PHP saranno ancora riempire $ _GET (e $ _REQUEST) con le variabili poste nella stringa di query, anche se non era una richiesta GET. Ciò consente la conformità con la definizione HEAD.

Answer 2

Ho appena fatto un rapido test con un file PHP, temp.php, che contiene questa porzione di codice:

<?php 

echo "Hello, World!\n"; 

die; 

Invio di una richiesta HTTP GET a quel file mi ottiene il contenuto della pagina:

$ telnet localhost 80 
Trying ::1... 
Trying 127.0.0.1... 
Connected to localhost. 
Escape character is '^]'. 
GET /temp/temp.php HTTP/1.1 
Host: localhost 

HTTP/1.1 200 OK 
Date: Thu, 08 Apr 2010 20:17:35 GMT 
Server: Apache/2.2.12 (Ubuntu) 
X-Powered-By: PHP/5.3.2RC2 
Vary: Accept-Encoding 
Content-Length: 14 
Content-Type: text/html 

Hello, World! 

Mentre l'invio di una richiesta HEAD HTTP non lo fa:

$ telnet localhost 80 
Trying ::1... 
Trying 127.0.0.1... 
Connected to localhost. 
Escape character is '^]'. 
HEAD /temp/temp.php HTTP/1.1 
Host: localhost 

HTTP/1.1 200 OK 
Date: Thu, 08 Apr 2010 20:17:50 GMT 
Server: Apache/2.2.12 (Ubuntu) 
X-Powered-By: PHP/5.3.2RC2 
Vary: Accept-Encoding 
Content-Type: text/html 

Non è sicuro questo è sempre vero, anche se ...

Mi ricordo una situazione (qualche tempo fa; era PHP 5.1) in cui ho dovuto mettermi alla prova, nel codice PHP, se ricevevo una richiesta GET o HEAD.

---

EDIT: Dopo un test additionnal

Ho appena fatto un altro test: il mio file temp.php contiene ora questo:

<?php 

file_put_contents('/tmp/a.txt', $_SERVER['REQUEST_METHOD'], FILE_APPEND); 
var_dump($_SERVER['REQUEST_METHOD']); 

die; 

invio di una richiesta HTTP HEAD, Ho capito:

$ telnet localhost 80 
Trying ::1... 
Trying 127.0.0.1... 
Connected to localhost. 
Escape character is '^]'. 
HEAD /temp/temp.php HTTP/1.1 
Host: localhost 

HTTP/1.1 200 OK 
Date: Thu, 08 Apr 2010 20:21:30 GMT 
Server: Apache/2.2.12 (Ubuntu) 
X-Powered-By: PHP/5.3.2RC2 
Vary: Accept-Encoding 
Content-Type: text/html 

Connection closed by foreign host. 

Qui, nessuna uscita.

MA, guardando il file /tmp/a.txt:

$ cat /tmp/a.txt 
HEAD 

Quindi: nessuna uscita inviata dal server non significa che non c'è fatto assolutamente nulla ;-)