No, non dovresti preoccuparti, soprattutto non al tasso di HEAD di richieste HTTP che stai citando. Una di queste richieste ogni mezz'ora in media non è molto. Fondamentalmente, % richieste diHEAD fai cosa dice sulla confezione , ovvero, il tuo server web restituirà solo le intestazioni di risposta e non allegherà ad esso il corpo di risposta completo. Questo può essere utile per ridurre i requisiti di larghezza di banda per semplici compiti di ad es. stabilire il codice di risposta per il percorso richiesto, la convalida della cache del client e così via. Può quindi essere utilizzato per stabilire se il server Web risponde o se il percorso richiesto è ancora disponibile, non inviare nuovamente i contenuti che non sono stati modificati nel frattempo e che sono già memorizzati nella cache locale dal client, ... in base alla risposta del tuo server codice di stato HTTP e ai contenuti dell'intestazione.
Ora, queste richieste possono essere piuttosto frequenti e talvolta un po 'fastidiose in termini di quantità, ma tecnicamente sono migliori per il server in termini di consumo delle risorse, poiché un host web ben scritto può elaborare tali richieste più velocemente e consumare meno upload larghezza di banda per inviare una risposta, che se dovesse elaborare e includere nella sua risposta un documento completo. Con file multimediali più grandi, questo diventa ancora più evidente. Quindi non consiglierei di bloccare tali richieste nella configurazione del tuo server web, e se rendono meno leggibili i file di registro del tuo server, ti consiglio di reindirizzare tali richieste in un file di registro separato.
Per quanto riguarda ciò che viene restituito in questi header, non c'è nulla di molto diverso in loro che con le richieste normal GET , con l'eccezione che la lunghezza del contenuto sarà ovviamente più piccola. E non c'è motivo di pensare che l'aumento delle richieste HTTP HEAD sia una qualche forma di attacco DOS sul tuo server, dal momento che richiederebbe allo stesso l'attacker di inviare% richieste diGET, mentre allo stesso tempo esaurirebbe il tuo risorse del server molto più veloce. L'unico caso in cui HEAD lo farebbe più velocemente di GET è se non valuti limite o blocco con altri mezzi (egrequest IP) il primo, ma limiti il limite o filtri quest'ultimo e qualche altro HTTP comune tipi di richiesta come ad es POST , che sarebbe un caso di errata configurazione e non è molto frequente. Assicurati di non disabilitare involontariamente tali filtri nella tua configurazione per metodi di richiesta meno comuni, solo per essere sicuri.
Quindi, se dovresti bloccare HEAD le richieste spetta a te, ma non mi preoccuperei. Ci sono altri tipi di richieste HTTP che sono molto più preoccupanti, specialmente se non ne hai nemmeno bisogno per l'host, ad esempio TRACE , SEARCH , OPTIONS , ... Ed è sempre una buona pratica per disabilitare la risposta a tutti i metodi di richiesta HTTP per i quali il tuo software server non ha alcuna utilità. Ad esempio, questo è dalla mia configurazione di Apache:
RewriteCond %{REQUEST_METHOD} ^(TRACE|SEARCH|TRACK|OPTIONS|PUT|QUIT|CONNECT|DELETE|PATCH|DEBUG|PROPFIND|PROPPATCH|MKCOL|COPY|MOVE|LOCK|UNLOCK)
RewriteRule .* - [F]
Ciò garantisce che nessuno dei metodi elencati è servito (richiesta inoltrata dal software del server Web all'applicazione che gestisce queste richieste ed elaborata) e il server web immediatamente li rifiuta restituendo un 403 Forbidden codice di stato al client. Nota che le tue applicazioni web potrebbero essere scritte per richiedere alcuni dei metodi HTTP che blocco nella mia configurazione, questo esempio non è pensato per essere copiato direttamente e può interrompere la funzionalità del tuo host web, se non usato con cautela!