9.2 OPZIONI
Il metodo OPTIONS rappresenta una richiesta di informazioni sulle opzioni di comunicazione disponibili sulla catena di richiesta / risposta identificata dalla Request-URI. Questo metodo consente al client di determinare le opzioni e / o i requisiti associati a una risorsa o le capacità di un server, senza implicare un'azione di risorsa o avviare un recupero di risorsa.
Le risposte a questo metodo non sono memorizzabili nella cache.
Se la richiesta OPTIONS include un corpo-entità (come indicato dalla presenza di Content-Length o Transfer-Encoding), il tipo di supporto DEVE essere indicato da un campo Content-Type. Sebbene questa specifica non definisca alcun utilizzo per tale corpo, le estensioni future a HTTP potrebbero utilizzare il corpo OPTIONS per eseguire query più dettagliate sul server. Un server che non supporta tale estensione PU scartare il corpo della richiesta.
Se l'URI della richiesta è un asterisco ("*"), la richiesta OPTIONS deve essere applicata al server in generale piuttosto che a una risorsa specifica. Poiché le opzioni di comunicazione di un server dipendono tipicamente dalla risorsa, la richiesta "*" è utile solo come metodo di tipo "ping" o "no-op"; non fa altro che consentire al client di testare le capacità del server. Ad esempio, questo può essere utilizzato per testare un proxy per la conformità HTTP / 1.1 (o la sua mancanza).
Se l'URI della richiesta non è un asterisco, la richiesta OPTIONS si applica solo alle opzioni disponibili durante la comunicazione con quella risorsa.
Una risposta 200 DOVREBBE includere tutti i campi di intestazione che indicano caratteristiche opzionali implementate dal server e applicabili a quella risorsa (ad esempio, Consenti), possibilmente includendo estensioni non definite da questa specifica. Il corpo di risposta, se presente, DOVREBBE includere anche informazioni sulle opzioni di comunicazione. Il formato per tale corpo non è definito da questa specifica, ma potrebbe essere definito da future estensioni a HTTP. La negoziazione del contenuto PU essere utilizzata per selezionare il formato di risposta appropriato. Se il corpo della risposta non è incluso, la risposta DEVE includere un campo Content-Length con un valore di campo "0".
Il campo dell'intestazione della richiesta Max-Forwards PU essere utilizzato per indirizzare un proxy specifico nella catena di richieste. Quando un proxy riceve una richiesta OPTIONS su un absoluteURI per il quale è consentito l'inoltro della richiesta, il proxy DEVE verificare la presenza di un campo Max-Forward. Se il valore del campo Max-Forward è zero ("0"), il proxy NON DEVE inoltrare il messaggio; invece, il proxy DOVREBBE rispondere con le proprie opzioni di comunicazione. Se il valore del campo Max-Forwards è un numero intero maggiore di zero, il proxy DEVE decrementare il valore del campo quando inoltra la richiesta. Se nella richiesta non è presente alcun campo Max-Forward, la richiesta inoltrata NON DEVE includere un campo Max-Forward.
9.4 TESTA
Il metodo HEAD è identico a GET tranne per il fatto che il server NON DEVE restituire il corpo del messaggio nella risposta. Le metainformazioni contenute nelle intestazioni HTTP in risposta a una richiesta HEAD DOVREBBE essere identiche alle informazioni inviate in risposta a una richiesta GET. Questo metodo può essere utilizzato per ottenere metainformazioni sull'entità implicita nella richiesta senza trasferire l'ente-corpo stesso. Questo metodo viene spesso utilizzato per testare la validità, l'accessibilità e le modifiche recenti dei collegamenti ipertestuali.
La risposta a una richiesta HEAD PU essere memorizzabile nella cache nel senso che le informazioni contenute nella risposta POSSONO essere utilizzate per aggiornare un'entità precedentemente memorizzata nella cache da quella risorsa. Se i nuovi valori del campo indicano che l'entità memorizzata nella cache è diversa dall'entità corrente (come sarebbe indicato da una modifica in Content-Length, Content-MD5, ETag o Last-Modified), la cache DEVE trattare la voce della cache come obsoleta.