4. Request Methods (Metodi di Richiesta)

4.1. Overview (Panoramica)

Il token del metodo di richiesta è la fonte primaria della semantica della richiesta; indica lo scopo per cui il client ha effettuato questa richiesta e cosa il client si aspetta come risultato positivo.

La semantica del metodo di richiesta può essere ulteriormente specializzata dalla semantica di alcuni campi di intestazione quando presenti in una richiesta (Section 5) se tali semantiche aggiuntive non entrano in conflitto con il metodo. Ad esempio, un client può inviare campi di intestazione di richiesta condizionale (Section 5.2) per rendere l'azione richiesta condizionale allo stato corrente della risorsa target ([RFC7232]).

method = token

HTTP è stato originariamente progettato per essere utilizzabile come interfaccia verso sistemi di oggetti distribuiti. Il metodo di richiesta era concepito come applicazione di semantica a una risorsa target nello stesso modo in cui l'invocazione di un metodo definito su un oggetto identificato applicherebbe semantica. Il token del metodo è sensibile alle maiuscole/minuscole perché potrebbe essere utilizzato come gateway verso sistemi basati su oggetti con nomi di metodo sensibili alle maiuscole/minuscole.

A differenza degli oggetti distribuiti, i metodi di richiesta standardizzati in HTTP non sono specifici della risorsa, poiché le interfacce uniformi forniscono una migliore visibilità e riutilizzabilità nei sistemi basati su rete [REST]. Una volta definito, un metodo standardizzato dovrebbe avere la stessa semantica quando applicato a qualsiasi risorsa, sebbene ogni risorsa determini per sé se tali semantiche sono implementate o consentite.

Questa specifica definisce un certo numero di metodi standardizzati comunemente utilizzati in HTTP, come delineato nella tabella seguente. Per convenzione, i metodi standardizzati sono definiti in lettere maiuscole US-ASCII.

Method	Safe (Sicuro)	Idempotent (Idempotente)	Description (Descrizione)
GET	Yes	Yes	Trasferire una rappresentazione corrente della risorsa target.
HEAD	Yes	Yes	Come GET, ma trasferire solo la riga di stato e la sezione di intestazione.
POST	No	No	Eseguire elaborazione specifica della risorsa sul payload della richiesta.
PUT	No	Yes	Sostituire tutte le rappresentazioni correnti della risorsa target con il payload della richiesta.
DELETE	No	Yes	Rimuovere tutte le rappresentazioni correnti della risorsa target.
CONNECT	No	No	Stabilire un tunnel verso il server identificato dalla risorsa target.
OPTIONS	Yes	Yes	Descrivere le opzioni di comunicazione per la risorsa target.
TRACE	Yes	Yes	Eseguire un test di loopback del messaggio lungo il percorso verso la risorsa target.

Tutti i server generici DEVONO supportare i metodi GET e HEAD. Tutti gli altri metodi sono OPZIONALI.

Metodi aggiuntivi, al di fuori dell'ambito di questa specifica, sono stati standardizzati per l'uso in HTTP. Tutti tali metodi dovrebbero essere registrati nel "Hypertext Transfer Protocol (HTTP) Method Registry" gestito da IANA, come definito nella Section 8.1.

L'insieme dei metodi consentiti da una risorsa target può essere elencato in un campo di intestazione Allow (Section 7.4.1). Tuttavia, l'insieme dei metodi consentiti può cambiare dinamicamente. Quando viene ricevuto un metodo di richiesta non riconosciuto o non implementato da un server di origine, il server di origine DOVREBBE rispondere con il codice di stato 501 (Not Implemented). Quando viene ricevuto un metodo di richiesta conosciuto da un server di origine ma non consentito per la risorsa target, il server di origine DOVREBBE rispondere con il codice di stato 405 (Method Not Allowed).

4.2. Common Method Properties (Proprietà Comuni dei Metodi)

4.2.1. Safe Methods (Metodi Sicuri)

I metodi di richiesta sono considerati "sicuri" se la loro semantica definita è essenzialmente di sola lettura; cioè, il client non richiede, e non si aspetta, alcun cambiamento di stato sul server di origine come risultato dell'applicazione di un metodo sicuro a una risorsa target. Allo stesso modo, l'uso ragionevole di un metodo sicuro non dovrebbe causare danni, perdite di proprietà o carichi insoliti sul server di origine.

Questa definizione di metodi sicuri non impedisce a un'implementazione di includere comportamenti potenzialmente dannosi, che non sono interamente di sola lettura, o che causano effetti collaterali durante l'invocazione di un metodo sicuro. Ciò che è importante, tuttavia, è che il client non ha richiesto quel comportamento aggiuntivo e non può essere ritenuto responsabile per esso. Ad esempio, la maggior parte dei server aggiunge informazioni sulla richiesta ai file di log di accesso al completamento di ogni risposta, indipendentemente dal metodo, e ciò è considerato sicuro anche se lo storage del log potrebbe riempirsi e causare il crash del server. Allo stesso modo, una richiesta sicura iniziata selezionando una pubblicità sul Web avrà spesso l'effetto collaterale di addebitare un account pubblicitario.

Dei metodi di richiesta definiti da questa specifica, i metodi GET, HEAD, OPTIONS e TRACE sono definiti come sicuri.

Lo scopo di distinguere tra metodi sicuri e non sicuri è consentire ai processi di recupero automatizzati (spider) e all'ottimizzazione delle prestazioni della cache (pre-fetching) di funzionare senza timore di causare danni. Inoltre, consente a un agente utente di applicare vincoli appropriati sull'uso automatizzato di metodi non sicuri durante l'elaborazione di contenuti potenzialmente non affidabili.

Un agente utente DOVREBBE distinguere tra metodi sicuri e non sicuri quando presenta azioni potenziali a un utente, in modo che l'utente possa essere reso consapevole di un'azione non sicura prima che venga richiesta.

Quando una risorsa è costruita in modo tale che i parametri all'interno dell'URI di richiesta effettivo abbiano l'effetto di selezionare un'azione, è responsabilità del proprietario della risorsa garantire che l'azione sia coerente con la semantica del metodo di richiesta. Ad esempio, è comune per il software di modifica dei contenuti basato sul Web utilizzare azioni all'interno dei parametri di query, come "page?do=delete". Se lo scopo di tale risorsa è eseguire un'azione non sicura, allora il proprietario della risorsa DEVE disabilitare o non consentire quell'azione quando viene acceduta utilizzando un metodo di richiesta sicuro. Il mancato rispetto di ciò comporterà effetti collaterali sfortunati quando i processi automatizzati eseguiranno un GET su ogni riferimento URI per scopi di manutenzione dei link, pre-fetching, costruzione di un indice di ricerca, ecc.

4.2.2. Idempotent Methods (Metodi Idempotenti)

Un metodo di richiesta è considerato "idempotente" se l'effetto previsto sul server di più richieste identiche con quel metodo è lo stesso dell'effetto di una singola tale richiesta. Dei metodi di richiesta definiti da questa specifica, PUT, DELETE e i metodi di richiesta sicuri sono idempotenti.

Come la definizione di sicuro, la proprietà idempotente si applica solo a ciò che è stato richiesto dall'utente; un server è libero di registrare ogni richiesta separatamente, mantenere una cronologia del controllo di revisione o implementare altri effetti collaterali non idempotenti per ogni richiesta idempotente.

I metodi idempotenti sono distinti perché la richiesta può essere ripetuta automaticamente se si verifica un guasto di comunicazione prima che il client sia in grado di leggere la risposta del server. Ad esempio, se un client invia una richiesta PUT e la connessione sottostante viene chiusa prima che venga ricevuta alcuna risposta, allora il client può stabilire una nuova connessione e riprovare la richiesta idempotente. Sa che ripetere la richiesta avrà lo stesso effetto previsto, anche se la richiesta originale ha avuto successo, sebbene la risposta possa differire.

4.2.3. Cacheable Methods (Metodi Memorizzabili in Cache)

I metodi di richiesta possono essere definiti come "memorizzabili in cache" per indicare che le risposte ad essi sono consentite per essere memorizzate per un riutilizzo futuro; per requisiti specifici vedere [RFC7234]. In generale, i metodi sicuri che non dipendono da una risposta corrente o autorevole sono definiti come memorizzabili in cache; questa specifica definisce GET, HEAD e POST come memorizzabili in cache, sebbene la stragrande maggioranza delle implementazioni di cache supporti solo GET e HEAD.

4.3. Method Definitions (Definizioni dei Metodi)

4.3.1. GET

Il metodo GET richiede il trasferimento di una rappresentazione attualmente selezionata per la risorsa target. GET è il meccanismo primario di recupero delle informazioni e il focus di quasi tutte le ottimizzazioni delle prestazioni. Pertanto, quando le persone parlano di recuperare alcune informazioni identificabili tramite HTTP, si riferiscono generalmente all'effettuazione di una richiesta GET.

È allettante pensare agli identificatori di risorsa come percorsi di file system remoti e alle rappresentazioni come copie del contenuto di tali file. Sarebbe sbagliato. Le rappresentazioni restituite in risposta a GET non sono necessariamente solo il contenuto di una risorsa come memorizzato dal server di origine. Invece, sono selezionate (tramite negoziazione del contenuto) e generate al volo, a seconda della richiesta.

Un payload all'interno di un messaggio di richiesta GET non ha semantica definita; l'invio di un corpo di payload su una richiesta GET potrebbe causare il rifiuto della richiesta da parte di alcune implementazioni esistenti.

La risposta a una richiesta GET è memorizzabile in cache; una cache PUÒ utilizzarla per soddisfare richieste GET e HEAD successive a meno che non sia indicato diversamente dal campo di intestazione Cache-Control (Section 5.2 di [RFC7234]).

4.3.2. HEAD

Il metodo HEAD è identico a GET tranne per il fatto che il server NON DEVE inviare un corpo di messaggio nella risposta (cioè, la risposta termina alla fine della sezione di intestazione). Il server DOVREBBE inviare gli stessi campi di intestazione in risposta a una richiesta HEAD che avrebbe inviato se la richiesta fosse stata un GET, tranne che i campi di intestazione del payload (Section 3.3) POSSONO essere omessi. Questo metodo può essere utilizzato per ottenere metadati sulla rappresentazione selezionata senza trasferire i dati di rappresentazione ed è spesso utilizzato per testare link ipertestuali per validità, accessibilità e modifiche recenti.

Un payload all'interno di un messaggio di richiesta HEAD non ha semantica definita; l'invio di un corpo di payload su una richiesta HEAD potrebbe causare il rifiuto della richiesta da parte di alcune implementazioni esistenti.

La risposta a una richiesta HEAD è memorizzabile in cache; una cache PUÒ utilizzarla per soddisfare richieste HEAD successive a meno che non sia indicato diversamente dal campo di intestazione Cache-Control (Section 5.2 di [RFC7234]). Una risposta HEAD potrebbe anche avere un effetto sulle risposte GET precedentemente memorizzate in cache; vedere Section 4.3.5 di [RFC7234].

4.3.3. POST

Il metodo POST richiede che la risorsa target elabori la rappresentazione inclusa nella richiesta secondo la semantica specifica della risorsa stessa. Ad esempio, POST viene utilizzato per le seguenti funzioni (tra le altre):

• Fornire un blocco di dati, come i campi inseriti in un modulo HTML, a un processo di gestione dei dati;

• Pubblicare un messaggio su una bacheca, newsgroup, mailing list, blog o gruppo simile di articoli;

• Creare una nuova risorsa che deve ancora essere identificata dal server di origine; e,

• Aggiungere dati alle rappresentazioni esistenti di una risorsa.

Un server di origine indica la semantica della risposta scegliendo un codice di stato appropriato a seconda del risultato dell'elaborazione della richiesta POST; quasi tutti i codici di stato definiti da questa specifica potrebbero essere ricevuti in risposta a POST (le eccezioni sono 206 (Partial Content), 304 (Not Modified) e 416 (Range Not Satisfiable)).

Se una o più risorse sono state create sul server di origine come risultato dell'elaborazione con successo di una richiesta POST, il server di origine DOVREBBE inviare una risposta 201 (Created) contenente un campo di intestazione Location che fornisce un identificatore per la risorsa primaria creata (Section 7.1.2) e una rappresentazione che descrive lo stato della richiesta facendo riferimento alla/e nuova/e risorsa/e.

Le risposte alle richieste POST sono memorizzabili in cache solo quando includono informazioni esplicite sulla freschezza (vedere Section 4.2.1 di [RFC7234]). Tuttavia, la memorizzazione nella cache di POST non è ampiamente implementata. Per i casi in cui un server di origine desidera che il client sia in grado di memorizzare nella cache il risultato di un POST in un modo che può essere riutilizzato da un GET successivo, il server di origine PUÒ inviare una risposta 200 (OK) contenente il risultato e un campo di intestazione Content-Location che ha lo stesso valore dell'URI di richiesta effettivo del POST (Section 3.1.4.2).

Se il risultato dell'elaborazione di un POST fosse equivalente a una rappresentazione di una risorsa esistente, un server di origine PUÒ reindirizzare l'agente utente a quella risorsa inviando una risposta 303 (See Other) con l'identificatore della risorsa esistente nel campo Location. Questo ha i vantaggi di fornire all'agente utente un identificatore di risorsa e trasferire la rappresentazione tramite un metodo più adatto alla memorizzazione nella cache condivisa, sebbene al costo di una richiesta extra se l'agente utente non ha già la rappresentazione memorizzata nella cache.

4.3.4. PUT

Il metodo PUT richiede che lo stato della risorsa target sia creato o sostituito con lo stato definito dalla rappresentazione inclusa nel payload del messaggio di richiesta. Un PUT con successo di una data rappresentazione suggerirebbe che un GET successivo sulla stessa risorsa target risulterebbe nell'invio di una rappresentazione equivalente in una risposta 200 (OK). Tuttavia, non c'è garanzia che tale cambiamento di stato sarà osservabile, poiché la risorsa target potrebbe essere manipolata da altri agenti utente in parallelo, o potrebbe essere soggetta a elaborazione dinamica da parte del server di origine, prima che venga ricevuto qualsiasi GET successivo. Una risposta positiva implica solo che l'intento dell'agente utente è stato raggiunto al momento della sua elaborazione da parte del server di origine.

Se la risorsa target non ha una rappresentazione corrente e il PUT ne crea con successo una, allora il server di origine DEVE informare l'agente utente inviando una risposta 201 (Created). Se la risorsa target ha una rappresentazione corrente e quella rappresentazione viene modificata con successo in conformità con lo stato della rappresentazione inclusa, allora il server di origine DEVE inviare una risposta 200 (OK) o una risposta 204 (No Content) per indicare il completamento con successo della richiesta.

Un server di origine DOVREBBE verificare che la rappresentazione PUT sia coerente con eventuali vincoli che il server ha per la risorsa target che non possono essere o non sono modificati dal PUT. Ciò è particolarmente importante quando il server di origine utilizza informazioni di configurazione interne relative all'URI per impostare i valori per i metadati di rappresentazione sulle risposte GET. Quando una rappresentazione PUT è incoerente con la risorsa target, il server di origine DOVREBBE renderle coerenti, trasformando la rappresentazione o modificando la configurazione della risorsa, o rispondere con un messaggio di errore appropriato contenente informazioni sufficienti per spiegare perché la rappresentazione è inappropriata. Sono suggeriti i codici di stato 409 (Conflict) o 415 (Unsupported Media Type), essendo quest'ultimo specifico per i vincoli sui valori Content-Type.

Ad esempio, se la risorsa target è configurata per avere sempre un Content-Type di "text/html" e la rappresentazione che viene PUT ha un Content-Type di "image/jpeg", il server di origine dovrebbe fare una delle seguenti:

a. riconfigurare la risorsa target per riflettere il nuovo tipo di media;

b. trasformare la rappresentazione PUT in un formato coerente con quello della risorsa prima di salvarla come nuovo stato della risorsa; o,

c. rifiutare la richiesta con una risposta 415 (Unsupported Media Type) indicando che la risorsa target è limitata a "text/html", includendo forse un link a una risorsa diversa che sarebbe un target appropriato per la nuova rappresentazione.

HTTP non definisce esattamente come un metodo PUT influenzi lo stato di un server di origine oltre a ciò che può essere espresso dall'intento della richiesta dell'agente utente e dalla semantica della risposta del server di origine. Non definisce cosa potrebbe essere una risorsa, in qualsiasi senso di quella parola, oltre all'interfaccia fornita tramite HTTP. Non definisce come lo stato della risorsa è "memorizzato", né come tale memorizzazione potrebbe cambiare come risultato di un cambiamento nello stato della risorsa, né come il server di origine traduce lo stato della risorsa in rappresentazioni. In generale, tutti i dettagli di implementazione dietro l'interfaccia della risorsa sono intenzionalmente nascosti dal server.

Un server di origine NON DEVE inviare un campo di intestazione validatore (Section 7.2), come un campo ETag o Last-Modified, in una risposta positiva a PUT a meno che i dati di rappresentazione della richiesta non siano stati salvati senza alcuna trasformazione applicata al corpo (cioè, i nuovi dati di rappresentazione della risorsa sono identici ai dati di rappresentazione ricevuti nella richiesta PUT) e il valore del campo validatore riflette la nuova rappresentazione. Questo requisito consente a un agente utente di sapere che il corpo di rappresentazione che ha in memoria rimane corrente come risultato del PUT, quindi non necessita di essere recuperato nuovamente dal server di origine, e che i nuovi validatori ricevuti nella risposta possono essere utilizzati per richieste condizionali future al fine di prevenire sovrascritture accidentali (Section 5.2).

La differenza fondamentale tra i metodi POST e PUT è evidenziata dall'intento diverso per la rappresentazione inclusa. La risorsa target in una richiesta POST è destinata a gestire la rappresentazione inclusa secondo la semantica propria della risorsa, mentre la rappresentazione inclusa in una richiesta PUT è definita come sostituzione dello stato della risorsa target. Pertanto, l'intento di PUT è idempotente e visibile agli intermediari, anche se l'effetto esatto è noto solo al server di origine.

La corretta interpretazione di una richiesta PUT presuppone che l'agente utente sappia quale risorsa target è desiderata. Un servizio che seleziona un URI appropriato per conto del client, dopo aver ricevuto una richiesta di cambiamento di stato, DOVREBBE essere implementato utilizzando il metodo POST piuttosto che PUT. Se il server di origine non effettuerà il cambiamento di stato PUT richiesto alla risorsa target e desidera invece che venga applicato a una risorsa diversa, come quando la risorsa è stata spostata a un URI diverso, allora il server di origine DEVE inviare una risposta 3xx (Redirection) appropriata; l'agente utente PUÒ quindi prendere la propria decisione su se reindirizzare o meno la richiesta.

Una richiesta PUT applicata alla risorsa target può avere effetti collaterali su altre risorse. Ad esempio, un articolo potrebbe avere un URI per identificare "la versione corrente" (una risorsa) che è separato dagli URI che identificano ogni versione particolare (risorse diverse che a un certo punto condividevano lo stesso stato della risorsa versione corrente). Una richiesta PUT con successo sull'URI "della versione corrente" potrebbe quindi creare una nuova risorsa versione oltre a cambiare lo stato della risorsa target, e potrebbe anche causare l'aggiunta di link tra le risorse correlate.

Un server di origine che consente PUT su una data risorsa target DEVE inviare una risposta 400 (Bad Request) a una richiesta PUT che contiene un campo di intestazione Content-Range (Section 4.2 di [RFC7233]), poiché il payload è probabilmente contenuto parziale che è stato erroneamente PUT come rappresentazione completa. Gli aggiornamenti di contenuto parziale sono possibili indirizzando una risorsa separatamente identificata con uno stato che si sovrappone a una porzione della risorsa più grande, o utilizzando un metodo diverso che è stato specificamente definito per aggiornamenti parziali (ad esempio, il metodo PATCH definito in [RFC5789]).

Le risposte al metodo PUT non sono memorizzabili in cache. Se una richiesta PUT con successo passa attraverso una cache che ha una o più risposte memorizzate per l'URI di richiesta effettivo, quelle risposte memorizzate saranno invalidate (vedere Section 4.4 di [RFC7234]).

4.3.5. DELETE

Il metodo DELETE richiede che il server di origine rimuova l'associazione tra la risorsa target e la sua funzionalità corrente. In effetti, questo metodo è simile al comando rm in UNIX: esprime un'operazione di eliminazione sulla mappatura URI del server di origine piuttosto che un'aspettativa che le informazioni precedentemente associate vengano eliminate.

Se la risorsa target ha una o più rappresentazioni correnti, potrebbero o non potrebbero essere distrutte dal server di origine, e lo storage associato potrebbe o non potrebbe essere recuperato, dipendendo interamente dalla natura della risorsa e dalla sua implementazione da parte del server di origine (che sono oltre l'ambito di questa specifica). Allo stesso modo, altri aspetti di implementazione di una risorsa potrebbero dover essere disattivati o archiviati come conseguenza di un DELETE, come connessioni di database o gateway. In generale, si presume che il server di origine consentirà DELETE solo su risorse per le quali ha un meccanismo prescritto per realizzare l'eliminazione.

Relativamente poche risorse consentono il metodo DELETE -- il suo uso primario è per ambienti di authoring remoto, dove l'utente ha una certa direzione riguardo al suo effetto. Ad esempio, una risorsa che è stata precedentemente creata utilizzando una richiesta PUT, o identificata tramite il campo di intestazione Location dopo una risposta 201 (Created) a una richiesta POST, potrebbe consentire una corrispondente richiesta DELETE per annullare quelle azioni. Allo stesso modo, le implementazioni di agenti utente personalizzate che implementano una funzione di authoring, come i client di controllo di revisione che utilizzano HTTP per operazioni remote, potrebbero utilizzare DELETE basandosi su un'assunzione che lo spazio URI del server sia stato creato per corrispondere a un repository di versioni.

Se un metodo DELETE viene applicato con successo, il server di origine DOVREBBE inviare un codice di stato 202 (Accepted) se l'azione avrà probabilmente successo ma non è ancora stata attuata, un codice di stato 204 (No Content) se l'azione è stata attuata e non devono essere fornite ulteriori informazioni, o un codice di stato 200 (OK) se l'azione è stata attuata e il messaggio di risposta include una rappresentazione che descrive lo stato.

Un payload all'interno di un messaggio di richiesta DELETE non ha semantica definita; l'invio di un corpo di payload su una richiesta DELETE potrebbe causare il rifiuto della richiesta da parte di alcune implementazioni esistenti.

Le risposte al metodo DELETE non sono memorizzabili in cache. Se una richiesta DELETE passa attraverso una cache che ha una o più risposte memorizzate per l'URI di richiesta effettivo, quelle risposte memorizzate saranno invalidate (vedere Section 4.4 di [RFC7234]).

4.3.6. CONNECT

Il metodo CONNECT richiede che il destinatario stabilisca un tunnel verso il server di origine di destinazione identificato dal target della richiesta e, se ha successo, limiti successivamente il suo comportamento all'inoltro cieco di pacchetti, in entrambe le direzioni, fino alla chiusura del tunnel. I tunnel sono comunemente utilizzati per creare una connessione virtuale end-to-end, attraverso uno o più proxy, che può quindi essere protetta utilizzando TLS (Transport Layer Security, [RFC5246]).

CONNECT è destinato solo all'uso in richieste verso un proxy. Un server di origine che riceve una richiesta CONNECT per sé stesso PUÒ rispondere con un codice di stato 2xx (Successful) per indicare che è stata stabilita una connessione. Tuttavia, la maggior parte dei server di origine non implementa CONNECT.

Un client che invia una richiesta CONNECT DEVE inviare la forma di autorità del target della richiesta (Section 5.3 di [RFC7230]); cioè, il target della richiesta consiste solo del nome host e del numero di porta della destinazione del tunnel, separati da due punti. Ad esempio,

CONNECT server.example.com:80 HTTP/1.1
Host: server.example.com:80

Il proxy destinatario può stabilire un tunnel connettendosi direttamente al target della richiesta o, se configurato per utilizzare un altro proxy, inoltrando la richiesta CONNECT al prossimo proxy in entrata. Qualsiasi risposta 2xx (Successful) indica che il mittente (e tutti i proxy in entrata) passerà alla modalità tunnel immediatamente dopo la riga vuota che conclude la sezione di intestazione della risposta positiva; i dati ricevuti dopo quella riga vuota provengono dal server identificato dal target della richiesta. Qualsiasi risposta diversa da una risposta positiva indica che il tunnel non è ancora stato formato e che la connessione rimane governata da HTTP.

Un tunnel viene chiuso quando un intermediario del tunnel rileva che uno dei due lati ha chiuso la sua connessione: l'intermediario DEVE tentare di inviare tutti i dati in sospeso provenienti dal lato chiuso all'altro lato, chiudere entrambe le connessioni e quindi scartare tutti i dati rimanenti lasciati non consegnati.

L'autenticazione proxy potrebbe essere utilizzata per stabilire l'autorità per creare un tunnel. Ad esempio,

CONNECT server.example.com:80 HTTP/1.1
Host: server.example.com:80
Proxy-Authorization: basic aGVsbG86d29ybGQ=

Ci sono rischi significativi nello stabilire un tunnel verso server arbitrari, in particolare quando la destinazione è una porta TCP ben nota o riservata che non è destinata al traffico Web. Ad esempio, un CONNECT a "example.com:25" suggerirebbe che il proxy si connetta alla porta riservata per il traffico SMTP; se consentito, ciò potrebbe ingannare il proxy nel relay di email spam. I proxy che supportano CONNECT DOVREBBERO limitarne l'uso a un insieme limitato di porte note o un elenco configurabile di target di richiesta sicuri.

Un server NON DEVE inviare alcun campo di intestazione Transfer-Encoding o Content-Length in una risposta 2xx (Successful) a CONNECT. Un client DEVE ignorare qualsiasi campo di intestazione Content-Length o Transfer-Encoding ricevuto in una risposta positiva a CONNECT.

Un payload all'interno di un messaggio di richiesta CONNECT non ha semantica definita; l'invio di un corpo di payload su una richiesta CONNECT potrebbe causare il rifiuto della richiesta da parte di alcune implementazioni esistenti.

Le risposte al metodo CONNECT non sono memorizzabili in cache.

4.3.7. OPTIONS

Il metodo OPTIONS richiede informazioni sulle opzioni di comunicazione disponibili per la risorsa target, sia al server di origine che a un intermediario interveniente. Questo metodo consente a un client di determinare le opzioni e/o i requisiti associati a una risorsa, o le capacità di un server, senza implicare un'azione sulla risorsa.

Una richiesta OPTIONS con un asterisco ("") come target della richiesta (Section 5.3 di [RFC7230]) si applica 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 tipo di metodo "ping" o "no-op"; non fa nulla oltre a consentire al client di testare le capacità del server. Ad esempio, questo può essere utilizzato per testare la conformità HTTP/1.1 di un proxy (o la mancanza di essa).

Se il target della richiesta non è un asterisco, la richiesta OPTIONS si applica alle opzioni disponibili quando si comunica con la risorsa target.

Un server che genera una risposta positiva a OPTIONS DOVREBBE inviare qualsiasi campo di intestazione che potrebbe indicare funzionalità opzionali implementate dal server e applicabili alla risorsa target (ad esempio, Allow), incluse potenziali estensioni non definite da questa specifica. Il payload della risposta, se presente, potrebbe anche descrivere le opzioni di comunicazione in una rappresentazione leggibile da macchina o da umano. Un formato standard per tale rappresentazione non è definito da questa specifica, ma potrebbe essere definito da future estensioni a HTTP. Un server DEVE generare un campo Content-Length con un valore di "0" se nessun corpo di payload deve essere inviato nella risposta.

Un client PUÒ inviare un campo di intestazione Max-Forwards in una richiesta OPTIONS per indirizzare un destinatario specifico nella catena di richieste (vedere Section 5.1.2). Un proxy NON DEVE generare un campo di intestazione Max-Forwards durante l'inoltro di una richiesta a meno che quella richiesta non sia stata ricevuta con un campo Max-Forwards.

Un client che genera una richiesta OPTIONS contenente un corpo di payload DEVE inviare un campo di intestazione Content-Type valido che descriva il tipo di media della rappresentazione. Sebbene questa specifica non definisca alcun uso per tale payload, future estensioni a HTTP potrebbero utilizzare il corpo OPTIONS per effettuare query più dettagliate sulla risorsa target.

Le risposte al metodo OPTIONS non sono memorizzabili in cache.

4.3.8. TRACE

Il metodo TRACE richiede un loopback a livello applicativo remoto del messaggio di richiesta. Il destinatario finale della richiesta DOVREBBE riflettere il messaggio ricevuto, escludendo alcuni campi descritti di seguito, al client come corpo del messaggio di una risposta 200 (OK) con un Content-Type di "message/http" (Section 8.3.1 di [RFC7230]). Il destinatario finale è il server di origine o il primo server a ricevere un valore Max-Forwards di zero (0) nella richiesta (Section 5.1.2).

Un client NON DEVE generare campi di intestazione in una richiesta TRACE contenenti dati sensibili che potrebbero essere divulgati dalla risposta. Ad esempio, sarebbe sciocco per un agente utente inviare credenziali utente memorizzate [RFC7235] o cookie [RFC6265] in una richiesta TRACE. Il destinatario finale della richiesta DOVREBBE escludere eventuali campi di intestazione della richiesta che probabilmente contengono dati sensibili quando quel destinatario genera il corpo della risposta.

TRACE consente al client di vedere cosa viene ricevuto all'altra estremità della catena di richieste e utilizzare quei dati per informazioni di test o diagnostiche. Il valore del campo di intestazione Via (Section 5.7.1 di [RFC7230]) è di particolare interesse, poiché funge da traccia della catena di richieste. L'uso del campo di intestazione Max-Forwards consente al client di limitare la lunghezza della catena di richieste, il che è utile per testare una catena di proxy che inoltrano messaggi in un ciclo infinito.

Un client NON DEVE inviare un corpo di messaggio in una richiesta TRACE.

Le risposte al metodo TRACE non sono memorizzabili in cache.

---