9. Metodi (Methods)

9.1. Panoramica (Overview)

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 ciò che 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, se tale semantica aggiuntiva non è in conflitto con il metodo. Ad esempio, un client può inviare campi di intestazione di richiesta condizionale (Sezione 13.1) per rendere l'azione richiesta condizionale allo stato corrente della risorsa di destinazione.

HTTP è progettato per essere utilizzabile come interfaccia verso sistemi di oggetti distribuiti. Il metodo di richiesta invoca un'azione da applicare a una risorsa di destinazione in modo molto simile a come un'invocazione di metodo remoto può essere inviata a un oggetto identificato.

method = token

Il token del metodo è case-sensitive perché potrebbe essere utilizzato come gateway verso sistemi basati su oggetti con nomi di metodo case-sensitive. Per convenzione, i metodi standardizzati sono definiti con lettere maiuscole US-ASCII.

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 da sé se tale semantica è implementata o consentita.

Questa specifica definisce un numero di metodi standardizzati comunemente utilizzati in HTTP, come mostrato nella tabella seguente.

Nome Metodo	Descrizione	Sezione
GET	Trasferire una rappresentazione corrente della risorsa di destinazione.	9.3.1
HEAD	Come GET, ma non trasferire il contenuto della risposta.	9.3.2
POST	Eseguire l'elaborazione specifica della risorsa sul contenuto della richiesta.	9.3.3
PUT	Sostituire tutte le rappresentazioni correnti della risorsa di destinazione con il contenuto della richiesta.	9.3.4
DELETE	Rimuovere tutte le rappresentazioni correnti della risorsa di destinazione.	9.3.5
CONNECT	Stabilire un tunnel verso il server identificato dalla risorsa di destinazione.	9.3.6
OPTIONS	Descrivere le opzioni di comunicazione per la risorsa di destinazione.	9.3.7
TRACE	Eseguire un test di loopback del messaggio lungo il percorso verso la risorsa di destinazione.	9.3.8

Tutti i server general-purpose DEVONO (MUST) supportare i metodi GET e HEAD. Tutti gli altri metodi sono FACOLTATIVI (OPTIONAL).

L'insieme di metodi consentiti da una risorsa di destinazione può essere elencato in un campo di intestazione Allow (Sezione 10.2.1). Tuttavia, l'insieme di metodi consentiti può cambiare dinamicamente. Un server di origine che riceve un metodo di richiesta non riconosciuto o non implementato DOVREBBE (SHOULD) rispondere con il codice di stato 501 (Not Implemented). Un server di origine che riceve un metodo di richiesta riconosciuto e implementato, ma non consentito per la risorsa di destinazione, DOVREBBE (SHOULD) rispondere con il codice di stato 405 (Method Not Allowed).

Metodi aggiuntivi, al di fuori dell'ambito di questa specifica, sono stati specificati per l'uso in HTTP. Tutti tali metodi dovrebbero essere registrati nel "Registro dei Metodi del Protocollo di Trasferimento Ipertestuale (HTTP)", come descritto nella Sezione 16.1.

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

9.2.1. Metodi Sicuri (Safe Methods)

I metodi di richiesta sono considerati "sicuri" se la loro semantica definita è essenzialmente di sola lettura; ovvero, il client non richiede né si aspetta che si verifichi alcun cambiamento di stato sul server di origine come risultato dell'applicazione di un metodo sicuro a una risorsa di destinazione. Allo stesso modo, non ci si aspetta che l'uso ragionevole di un metodo sicuro causi danni, perdita di proprietà o carico insolito sul server di origine.

Questa definizione di metodi sicuri non impedisce a un'implementazione di includere comportamenti potenzialmente dannosi, che non sono completamente 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 tale comportamento aggiuntivo e non può esserne ritenuto responsabile. 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 questo è considerato sicuro anche se lo storage del log potrebbe riempirsi e causare il fallimento del server. Allo stesso modo, una richiesta sicura avviata selezionando una pubblicità sul Web avrà spesso l'effetto collaterale di addebitare un conto pubblicitario.

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

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

Un user agent DOVREBBE (SHOULD) distinguere tra metodi sicuri e non sicuri quando presenta azioni potenziali a un utente, in modo che l'utente possa essere informato di un'azione non sicura prima che venga richiesta.

Quando una risorsa è costruita in modo tale che i parametri all'interno dell'URI di destinazione abbiano l'effetto di selezionare un'azione, è responsabilità del proprietario della risorsa assicurarsi che l'azione sia coerente con la semantica del metodo di richiesta. Ad esempio, è comune per il software di authoring di contenuti basato sul Web utilizzare azioni nei parametri di query, come "page?do=delete". Se lo scopo di tale risorsa è eseguire un'azione non sicura, il proprietario della risorsa DEVE (MUST) disabilitare o non consentire tale azione quando vi si accede utilizzando un metodo di richiesta sicuro. In caso contrario, si verificheranno effetti collaterali indesiderati quando i processi automatizzati eseguono un GET su ogni riferimento URI allo scopo di manutenzione dei link, pre-caricamento, costruzione di un indice di ricerca, ecc.

9.2.2. Metodi Idempotenti (Idempotent Methods)

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. Tra i 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 di controllo delle revisioni o implementare altri effetti collaterali non idempotenti per ogni richiesta idempotente.

I metodi idempotenti si distinguono 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 una risposta, 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 è riuscita, sebbene la risposta possa essere diversa.

Un client NON DOVREBBE (SHOULD NOT) riprovare automaticamente una richiesta con un metodo non idempotente a meno che non abbia un modo per sapere che la semantica della richiesta è in realtà idempotente, indipendentemente dal metodo, o un modo per rilevare che la richiesta originale non è mai stata applicata.

Ad esempio, un user agent potrebbe riprovare automaticamente una richiesta POST se sa (per progettazione o configurazione) che la richiesta è sicura per quella risorsa. Allo stesso modo, un user agent progettato specificamente per operare su un repository di controllo versione potrebbe essere in grado di recuperare da stati di guasto parziale controllando la/e revisione/i della risorsa di destinazione dopo un guasto di connessione, annullando o correggendo le modifiche che sono state applicate parzialmente, e quindi riprovando automaticamente le richieste fallite.

Alcuni client adottano un approccio più rischioso e tentano di indovinare quando è possibile un nuovo tentativo automatico. Ad esempio, un client potrebbe riprovare automaticamente una richiesta POST se la connessione di trasporto sottostante è stata chiusa prima che venisse ricevuta qualsiasi parte di risposta, in particolare se è stata utilizzata una connessione persistente inattiva.

Un proxy NON DEVE (MUST NOT) riprovare automaticamente richieste non idempotenti. Un client NON DOVREBBE (SHOULD NOT) riprovare automaticamente un nuovo tentativo automatico fallito.

9.2.3. Metodi e Caching (Methods and Caching)

Affinché una cache possa memorizzare e utilizzare una risposta, il metodo associato deve consentire esplicitamente il caching e dettagliare in quali condizioni una risposta può essere utilizzata per soddisfare richieste successive; una definizione di metodo che non lo fa non può essere messa in cache. Per requisiti aggiuntivi, vedere [CACHING].

Questa specifica definisce la semantica di caching per GET, HEAD e POST, sebbene la stragrande maggioranza delle implementazioni di cache supporti solo GET e HEAD.

9.3. Definizioni dei Metodi (Method Definitions)

9.3.1. GET

Il metodo GET richiede il trasferimento di una rappresentazione attualmente selezionata per la risorsa di destinazione. Una risposta positiva riflette la qualità di "uguaglianza" identificata dall'URI di destinazione (Sezione 1.2.2 di [URI]). Pertanto, il recupero di informazioni identificabili tramite HTTP viene solitamente eseguito effettuando una richiesta GET su un identificatore associato al potenziale di fornire tali informazioni in una risposta 200 (OK).

GET è il meccanismo principale di recupero delle informazioni e il fulcro di quasi tutte le ottimizzazioni delle prestazioni. Le applicazioni che generano un URI per ogni risorsa importante possono beneficiare di tali ottimizzazioni consentendo al contempo il loro riutilizzo da parte di altre applicazioni, creando un effetto di rete che favorisce l'ulteriore espansione del Web.

È allettante pensare agli identificatori di risorsa come nomi di percorso di file system remoti e alle rappresentazioni come copia del contenuto di tali file. In effetti, è così che vengono implementate molte risorse (vedere Sezione 17.3 per considerazioni di sicurezza correlate). Tuttavia, non ci sono tali limitazioni nella pratica.

L'interfaccia HTTP per una risorsa ha la stessa probabilità di essere implementata come un albero di oggetti di contenuto, una vista programmatica di vari record di database o un gateway verso altri sistemi informativi. Anche quando il meccanismo di mappatura URI è legato a un file system, un server di origine può essere configurato per eseguire il file con la richiesta come input e inviare l'output come rappresentazione, piuttosto che trasferire direttamente il file. In ogni caso, solo il server di origine deve sapere come ciascuno dei suoi identificatori di risorsa corrisponde a un'implementazione e come tale implementazione riesce a selezionare e inviare una rappresentazione corrente della risorsa di destinazione.

Un client può modificare la semantica di GET in una "richiesta di intervallo", richiedendo il trasferimento solo di alcune parti della rappresentazione selezionata, inviando un campo di intestazione Range nella richiesta (Sezione 14.2).

Sebbene il framing del messaggio di richiesta sia indipendente dal metodo utilizzato, il contenuto ricevuto in una richiesta GET non ha semantica generalmente definita, non può modificare il significato o la destinazione della richiesta e può portare alcune implementazioni a rifiutare la richiesta e chiudere la connessione a causa del suo potenziale come attacco di contrabbando di richieste (Sezione 11.2 di [HTTP/1.1]). Un client NON DOVREBBE (SHOULD NOT) generare contenuto in una richiesta GET a meno che non venga effettuata direttamente a un server di origine che ha precedentemente indicato, in-band o out-of-band, che tale richiesta ha uno scopo e sarà adeguatamente supportata. Un server di origine NON DOVREBBE (SHOULD NOT) fare affidamento su accordi privati per ricevere contenuto, poiché i partecipanti alla comunicazione HTTP spesso non sono consapevoli degli intermediari nella catena delle richieste.

La risposta a una richiesta GET è cacheable; una cache PUÒ (MAY) usarla per soddisfare richieste GET e HEAD successive, salvo diversamente indicato dal campo di intestazione Cache-Control (Sezione 5.2 di [CACHING]).

Quando il recupero di informazioni viene eseguito con un meccanismo che costruisce un URI di destinazione da informazioni fornite dall'utente, come i campi di query di un modulo che utilizza GET, potrebbero essere forniti dati potenzialmente sensibili che non sarebbero appropriati per la divulgazione all'interno di un URI (vedere Sezione 17.9). In alcuni casi, i dati possono essere filtrati o trasformati in modo che non rivelino tali informazioni. In altri casi, in particolare quando non vi è alcun beneficio dal caching di una risposta, l'uso del metodo POST (Sezione 9.3.3) invece di GET può trasmettere tali informazioni nel contenuto della richiesta piuttosto che nell'URI di destinazione.

9.3.2. HEAD

Il metodo HEAD è identico a GET tranne che il server NON DEVE (MUST NOT) inviare contenuto nella risposta. HEAD viene utilizzato per ottenere metadati sulla rappresentazione selezionata senza trasferire i suoi dati di rappresentazione, spesso allo scopo di testare collegamenti ipertestuali o trovare modifiche recenti.

Il server DOVREBBE (SHOULD) inviare gli stessi campi di intestazione in risposta a una richiesta HEAD che avrebbe inviato in risposta a una richiesta GET. Tuttavia, un server PUÒ (MAY) omettere campi di intestazione per i quali un valore viene determinato solo durante la generazione del contenuto. Ad esempio, alcuni server memorizzano nel buffer una risposta dinamica a GET fino a quando non viene generata una quantità minima di dati in modo da poter delimitare le risposte piccole in modo più efficiente o prendere decisioni tardive riguardo alla selezione del contenuto. Una tale risposta a GET potrebbe contenere campi Content-Length e Vary, ad esempio, che non vengono generati in una risposta HEAD. Queste piccole incoerenze sono considerate preferibili alla generazione e allo scarto del contenuto per una richiesta HEAD, poiché HEAD viene solitamente richiesta per motivi di efficienza.

Sebbene il framing del messaggio di richiesta sia indipendente dal metodo utilizzato, il contenuto ricevuto in una richiesta HEAD non ha semantica generalmente definita, non può modificare il significato o la destinazione della richiesta e può portare alcune implementazioni a rifiutare la richiesta e chiudere la connessione a causa del suo potenziale come attacco di contrabbando di richieste (Sezione 11.2 di [HTTP/1.1]). Un client NON DOVREBBE (SHOULD NOT) generare contenuto in una richiesta HEAD a meno che non venga effettuata direttamente a un server di origine che ha precedentemente indicato, in-band o out-of-band, che tale richiesta ha uno scopo e sarà adeguatamente supportata. Un server di origine NON DOVREBBE (SHOULD NOT) fare affidamento su accordi privati per ricevere contenuto, poiché i partecipanti alla comunicazione HTTP spesso non sono consapevoli degli intermediari nella catena delle richieste.

La risposta a una richiesta HEAD è cacheable; una cache PUÒ (MAY) usarla per soddisfare richieste HEAD successive, salvo diversamente indicato dal campo di intestazione Cache-Control (Sezione 5.2 di [CACHING]). Una risposta HEAD può anche avere un effetto sulle risposte GET precedentemente memorizzate nella cache; vedere Sezione 4.3.5 di [CACHING].

9.3.3. POST

Il metodo POST richiede che la risorsa di destinazione elabori la rappresentazione inclusa nella richiesta secondo la semantica specifica della risorsa. 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, un newsgroup, una mailing list, un blog o un gruppo di articoli simili;
• Creare una nuova risorsa che non è ancora stata 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 in base al risultato dell'elaborazione della richiesta POST; quasi tutti i codici di stato definiti da questa specifica possono essere ricevuti in una 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 riuscita di una richiesta POST, il server di origine DOVREBBE (SHOULD) inviare una risposta 201 (Created) contenente un campo di intestazione Location (Sezione 10.2.2) che fornisce un identificatore per la risorsa primaria creata e una rappresentazione che descrive lo stato della richiesta mentre fa riferimento alla/e nuova/e risorsa/e.

Le risposte alle richieste POST sono cacheabili solo quando includono informazioni di freschezza esplicite (vedere Sezione 4.2.1 di [CACHING]) e un campo di intestazione Content-Location (Sezione 8.7) che ha lo stesso valore dell'URI di destinazione del POST. Una risposta POST memorizzata nella cache può essere riutilizzata per soddisfare una richiesta GET o HEAD successiva. Al contrario, una richiesta POST non può essere soddisfatta da una risposta POST memorizzata nella cache perché POST è potenzialmente non sicuro; vedere Sezione 4 di [CACHING].

Se il risultato dell'elaborazione di un POST sarebbe equivalente a una rappresentazione di una risorsa esistente, un server di origine PUÒ (MAY) reindirizzare lo user agent a quella risorsa inviando una risposta 303 (See Other) con l'identificatore della risorsa esistente nel campo Location. Ciò ha il vantaggio di fornire allo user agent un identificatore di risorsa e di trasferire la rappresentazione tramite un metodo più adatto alla cache condivisa, sebbene al costo di una richiesta aggiuntiva se lo user agent non ha già la rappresentazione memorizzata nella cache.

9.3.4. PUT

Il metodo PUT richiede che lo stato della risorsa di destinazione sia creato o sostituito con lo stato definito dalla rappresentazione inclusa nel contenuto del messaggio di richiesta. Un PUT riuscito di una data rappresentazione suggerirebbe che un GET successivo sulla stessa risorsa di destinazione comporterebbe l'invio di una rappresentazione equivalente in una risposta 200 (OK). Tuttavia, non vi è alcuna garanzia che tale cambiamento di stato sia osservabile, poiché la risorsa di destinazione potrebbe essere manipolata da altri user agent in parallelo, o potrebbe essere soggetta a elaborazione dinamica da parte del server di origine, prima che venga ricevuto un GET successivo. Una risposta positiva implica solo che l'intento dello user agent è stato raggiunto al momento della sua elaborazione da parte del server di origine.

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

Un server di origine DOVREBBE (SHOULD) verificare che la rappresentazione PUT sia coerente con i suoi vincoli configurati per la risorsa di destinazione. Ad esempio, se un server di origine determina i metadati di rappresentazione di una risorsa in base all'URI, il server di origine deve garantire che il contenuto ricevuto in una richiesta PUT riuscita sia coerente con tali metadati. Quando una rappresentazione PUT è incoerente con la risorsa di destinazione, il server di origine DOVREBBE (SHOULD) renderle coerenti trasformando la rappresentazione o modificando la configurazione della risorsa, oppure rispondere con un messaggio di errore appropriato contenente informazioni sufficienti per spiegare perché la rappresentazione è inappropriata. I codici di stato 409 (Conflict) o 415 (Unsupported Media Type) sono suggeriti, quest'ultimo essendo specifico per vincoli sui valori Content-Type.

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

a. riconfigurare la risorsa di destinazione 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; oppure c. rifiutare la richiesta con una risposta 415 (Unsupported Media Type) indicando che la risorsa di destinazione è limitata a "text/html", possibilmente includendo un collegamento a una risorsa diversa che sarebbe un obiettivo appropriato per la nuova rappresentazione.

HTTP non definisce esattamente come un metodo PUT influenzi lo stato di un server di origine al di là di ciò che può essere espresso dall'intento della richiesta dello user agent e dalla semantica della risposta del server di origine. Non definisce cosa potrebbe essere una risorsa, in qualsiasi senso di quella parola, al di là dell'interfaccia fornita tramite HTTP. Non definisce come lo stato della risorsa è "memorizzato", né come tale archiviazione 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.

Questo si estende al modo in cui il server di origine decide di associare un identificatore a una risorsa. Il server di origine è l'unico responsabile della mappatura di un URI di destinazione a una risorsa e quindi l'unico responsabile della creazione, modifica o distruzione di quella risorsa. Non esiste alcuna relazione richiesta tra la forma di un URI di destinazione e qualsiasi stato interno gestito dal server di origine, rendendo gli URI opachi a qualsiasi client che non sia a conoscenza dei dettagli di implementazione del server.

Un server di origine NON DEVE (MUST NOT) inviare un campo validatore (Sezione 8.8), come un campo ETag o Last-Modified, in una risposta riuscita a PUT a meno che i dati di rappresentazione della richiesta non siano stati salvati senza alcuna trasformazione applicata al contenuto (ovvero, i nuovi dati di rappresentazione della risorsa sono identici al contenuto ricevuto nella richiesta PUT) e il valore del campo validatore rifletta la nuova rappresentazione. Questo requisito consente a uno user agent di sapere quando la rappresentazione che ha inviato (e conservato in memoria) è il risultato del PUT, e quindi non ha bisogno di recuperarla nuovamente dal server di origine. Il/i nuovo/i validatore/i ricevuto/i nella risposta può/possono essere utilizzato/i per richieste condizionali future per evitare sovrascritture accidentali (Sezione 13.1).

La differenza fondamentale tra i metodi POST e PUT è evidenziata dall'intento diverso per la rappresentazione inclusa. La risorsa di destinazione 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 di destinazione. Di conseguenza, l'intento di PUT è idempotente e visibile agli intermediari, anche se l'effetto esatto è noto solo al server di origine.

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

Una richiesta PUT applicata alla risorsa di destinazione 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 particolare versione (risorse diverse che ad un certo punto hanno condiviso lo stesso stato della risorsa versione corrente). Un PUT riuscito sull'URI "versione corrente" potrebbe quindi creare una nuova risorsa versione oltre a cambiare lo stato della risorsa di destinazione, e potrebbe anche causare l'aggiunta di collegamenti tra le risorse correlate.

Un server di origine che consente PUT su una data risorsa di destinazione DEVE (MUST) inviare una risposta 400 (Bad Request) a una richiesta PUT che contiene un campo di intestazione Content-Range (Sezione 14.4), poiché il contenuto potrebbe non essere completo. Gli aggiornamenti di contenuto parziale sono possibili prendendo di mira una risorsa identificata separatamente con uno stato che si sovrappone a una parte 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 alle richieste PUT non sono cacheabili. Se una richiesta PUT riuscita passa attraverso una cache che ha una o più risposte memorizzate per l'URI di destinazione, quelle risposte memorizzate saranno invalidate (vedere Sezione 4.4 di [CACHING]).

9.3.5. DELETE

Il metodo DELETE richiede che il server di origine rimuova l'associazione tra la risorsa di destinazione 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 di destinazione ha una o più rappresentazioni correnti, esse possono o non possono essere distrutte dal server di origine, e lo storage associato può o non può essere recuperato, dipendendo interamente dalla natura della risorsa e dalla sua implementazione da parte del server di origine (che è al di fuori dell'ambito di questa specifica). Allo stesso modo, altri aspetti di implementazione di una risorsa potrebbero dover essere disabilitati o archiviati come risultato di un DELETE, come connessioni di database o gateway. In generale, si presume che il server di origine consentirà DELETE solo sulle risorse per le quali ha un meccanismo prescritto per realizzare l'eliminazione.

Relativamente poche risorse consentono il metodo DELETE — il suo uso principale è 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 richiesta DELETE corrispondente per annullare tali azioni. Allo stesso modo, le implementazioni di user agent personalizzate che implementano una funzione di authoring, come i client di controllo delle revisioni che utilizzano HTTP per operazioni remote, potrebbero utilizzare DELETE basandosi su un'assunzione che lo spazio URI del server sia stato progettato per corrispondere a un repository di versioni.

Se un metodo DELETE viene applicato con successo, il server di origine DOVREBBE (SHOULD) inviare:

• un codice di stato 202 (Accepted) se è probabile che l'azione abbia successo ma non è ancora stata eseguita,
• un codice di stato 204 (No Content) se l'azione è stata eseguita e nessuna ulteriore informazione deve essere fornita, o
• un codice di stato 200 (OK) se l'azione è stata eseguita e il messaggio di risposta include una rappresentazione che descrive lo stato.

Sebbene il framing del messaggio di richiesta sia indipendente dal metodo utilizzato, il contenuto ricevuto in una richiesta DELETE non ha semantica generalmente definita, non può modificare il significato o la destinazione della richiesta e può portare alcune implementazioni a rifiutare la richiesta e chiudere la connessione a causa del suo potenziale come attacco di contrabbando di richieste (Sezione 11.2 di [HTTP/1.1]). Un client NON DOVREBBE (SHOULD NOT) generare contenuto in una richiesta DELETE a meno che non venga effettuata direttamente a un server di origine che ha precedentemente indicato, in-band o out-of-band, che tale richiesta ha uno scopo e sarà adeguatamente supportata. Un server di origine NON DOVREBBE (SHOULD NOT) fare affidamento su accordi privati per ricevere contenuto, poiché i partecipanti alla comunicazione HTTP spesso non sono consapevoli degli intermediari nella catena delle richieste.

Le risposte alle richieste DELETE non sono cacheabili. Se una richiesta DELETE riuscita passa attraverso una cache che ha una o più risposte memorizzate per l'URI di destinazione, quelle risposte memorizzate saranno invalidate (vedere Sezione 4.4 di [CACHING]).

9.3.6. CONNECT

Il metodo CONNECT richiede che il destinatario stabilisca un tunnel verso il server di origine di destinazione identificato dal request-target e, in caso di successo, limiti successivamente il suo comportamento all'inoltro cieco dei dati, 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ò poi essere protetta utilizzando TLS (Transport Layer Security, [TLS13]).

CONNECT è destinato solo all'uso nelle richieste a un proxy. Un client che invia una richiesta CONNECT DEVE (MUST) inviare la forma di autorità del request-target (Sezione 7.1); ovvero, il request-target 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

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

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

Un server di origine PUÒ (MAY) accettare una richiesta CONNECT e partecipare come un'estremità del tunnel se sceglie di farlo, presumibilmente per buone ragioni legate alla sicurezza della rete o alla politica del firewall. In tal caso, il server di origine può terminare la connessione (se ricevuta direttamente dal client), trattare l'intero messaggio di richiesta come i dati da inoltrare ciecamente e inoltrare tali dati al servizio di ascolto identificato. In alternativa, il server di origine può trattare il messaggio di richiesta come se fosse destinato ad essere applicato alla propria configurazione, il che bypasserebbe le restrizioni del firewall sul traffico in uscita (assumendo che entrambe le coppie client/server di origine e destinazione siano controllate dallo stesso amministratore di sistema). In entrambi i casi, il server di origine PUÒ (MAY) applicare controlli di accesso basati sul messaggio di richiesta per tale CONNECT, poiché potrebbe avere un impatto sulla sicurezza o sul funzionamento se inoltrato ciecamente.

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

Un messaggio di richiesta CONNECT non ha contenuto. L'interpretazione dei dati inviati dopo una richiesta CONNECT è specifica della versione HTTP utilizzata. Vedere Sezione 9.3.6 di [HTTP/1.1] per dettagli su CONNECT in HTTP/1.1.

Le risposte alle richieste CONNECT non sono cacheabili.

9.3.7. OPTIONS

Il metodo OPTIONS richiede informazioni sulle opzioni di comunicazione disponibili per la risorsa di destinazione, sia sul server di origine che presso 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 della risorsa.

Una richiesta OPTIONS con un asterisco ("") come request-target (Sezione 7.1) 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à (o mancanza di conformità) di un proxy a HTTP/1.1.

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

Un server che genera una risposta positiva a OPTIONS DOVREBBE (SHOULD) inviare tutti i campi di intestazione che potrebbero indicare funzionalità facoltative implementate dal server e applicabili alla risorsa di destinazione (ad esempio, Allow), comprese le potenziali estensioni non definite da questa specifica. Il contenuto della risposta, se presente, potrebbe anche descrivere le opzioni di comunicazione in una rappresentazione leggibile dalla macchina o dall'uomo. Un formato standard per tale rappresentazione non è definito da questa specifica, ma potrebbe essere definito da estensioni future a HTTP.

Un client PUÒ (MAY) inviare un campo di intestazione Max-Forwards in una richiesta OPTIONS per indirizzare un destinatario specifico nella catena delle richieste (vedere Sezione 7.6.2). Un proxy NON DEVE (MUST NOT) generare un campo di intestazione Max-Forwards quando inoltra una richiesta a meno che tale richiesta non sia stata ricevuta con un campo Max-Forwards.

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

Le risposte alle richieste OPTIONS non sono cacheabili.

9.3.8. TRACE

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

Un client NON DEVE (MUST NOT) generare campi di intestazione in una richiesta TRACE contenenti dati sensibili che potrebbero essere divulgati dalla risposta. Ad esempio, sarebbe imprudente per uno user agent inviare credenziali utente memorizzate [HTTP-AUTH] o cookie [COOKIE] in una richiesta TRACE. Il destinatario finale della richiesta DOVREBBE (SHOULD) escludere qualsiasi campo di intestazione della richiesta che probabilmente contiene dati sensibili quando tale destinatario genera il contenuto della risposta.

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

Un client NON DEVE (MUST NOT) inviare contenuto in una richiesta TRACE.

Le risposte alle richieste TRACE non sono cacheabili.