5. Request (Richiesta)
Un messaggio di richiesta dal client al server include, nella prima riga di quel messaggio, il metodo da applicare alla risorsa, l'identificatore della risorsa e la versione del protocollo in uso.
Request = Request-Line ; Section 5.1
*(( general-header ; Section 4.5
| request-header ; Section 5.3
| entity-header ) CRLF) ; Section 7.1
CRLF
[ message-body ] ; Section 4.3
5.1 Request-Line (Riga di Richiesta)
La Request-Line inizia con un token di metodo (method token), seguito dal Request-URI e dalla versione del protocollo, e termina con un CRLF. Gli elementi sono separati da caratteri SP. Non sono consentiti CR o LF, tranne nella sequenza CRLF finale.
Request-Line = Method SP Request-URI SP HTTP-Version CRLF
5.1.1 Method (Metodo)
Il token Method indica il metodo da eseguire sulla risorsa identificata dal Request-URI. Il metodo è sensibile alle maiuscole.
Method = "OPTIONS" ; Section 9.2
| "GET" ; Section 9.3
| "HEAD" ; Section 9.4
| "POST" ; Section 9.5
| "PUT" ; Section 9.6
| "DELETE" ; Section 9.7
| "TRACE" ; Section 9.8
| "CONNECT" ; Section 9.9
| extension-method
extension-method = token
L'elenco dei metodi consentiti per una risorsa può essere specificato nel campo di intestazione Allow (sezione 14.7). Il codice di ritorno della risposta informa sempre il client se un metodo è attualmente consentito su una risorsa, poiché l'insieme dei metodi consentiti può cambiare dinamicamente. Il server di origine dovrebbe (SHOULD) restituire il codice di stato 405 (Method Not Allowed) se il metodo è riconosciuto dal server di origine ma non è consentito per la risorsa richiesta, e 501 (Not Implemented) se il metodo non è riconosciuto o non è implementato dal server di origine. Tutti i server generici devono (MUST) supportare i metodi GET e HEAD. Tutti gli altri metodi sono opzionali (OPTIONAL); tuttavia, se i metodi sopra citati sono implementati, devono (MUST) esserlo con la stessa semantica specificata nella sezione 9.
5.1.2 Request-URI (URI di Richiesta)
Il Request-URI è un Uniform Resource Identifier (sezione 3.2) che identifica la risorsa a cui deve essere applicata la richiesta.
Request-URI = "*" | absoluteURI | abs_path | authority
Le quattro opzioni del Request-URI dipendono dalla natura della richiesta. L'asterisco "*" significa che la richiesta non si applica a una risorsa particolare, ma al server stesso, ed è consentito solo quando il metodo utilizzato non si applica necessariamente a una risorsa. Un esempio è:
OPTIONS * HTTP/1.1
La forma absoluteURI viene utilizzata quando la richiesta viene inviata a un proxy. Il proxy è invitato a inoltrare la richiesta o a servire da una cache valida e restituire la risposta. Si noti che il proxy può (MAY) inoltrare la richiesta a un altro proxy o direttamente al server specificato dall'absoluteURI prima di inoltrare la richiesta al server in entrata successivo. Per evitare loop di richiesta, un proxy deve (MUST) essere in grado di riconoscere tutti i suoi nomi di server, inclusi alias, varianti locali e indirizzo IP numerico. Un esempio di richiesta sarebbe:
GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1
Per consentire la transizione all'uso di absoluteURI in tutte le richieste (versioni future di HTTP), tutti i server HTTP/1.1 devono (MUST) accettare la forma absoluteURI nelle richieste, anche se i client HTTP/1.1 li genereranno solo quando effettuano richieste a un proxy.
La forma authority viene utilizzata solo dal metodo CONNECT (sezione 9.9).
La forma più comune di Request-URI viene utilizzata per identificare una risorsa su un server di origine o gateway. In questo caso, il percorso assoluto dell'URI deve (MUST) essere trasmesso come Request-URI e la posizione di rete deve (MUST) essere trasmessa in un campo di intestazione Host. Ad esempio, un client che desidera recuperare una risorsa direttamente dal server di origine creerebbe una connessione TCP alla porta 80 dell'host "www.w3.org" e invierebbe le righe:
GET /pub/WWW/TheProject.html HTTP/1.1
Host: www.w3.org
seguito dal resto della richiesta. Si noti che se non viene fornito alcun numero di porta, si presume la porta predefinita HTTP 80.
Se un proxy riceve una tale richiesta, deve (MUST) aggiungere il campo di intestazione Host alla richiesta prima di inoltrarla, a meno che non sia già presente. (Vedere la sezione 14.23 per ulteriori dettagli su Host.)
Se il Request-URI inizia con una barra, viene trattato come un abs_path. Il destinatario deve (MUST) interpretare un abs_path vuoto come se l'abs_path dell'absoluteURI fosse "/".
Tutti i client HTTP/1.1 devono (MUST) includere un campo di intestazione Host quando generano messaggi di richiesta HTTP/1.1. Se una richiesta HTTP/1.1 manca di un campo di intestazione Host, il server deve (MUST) rispondere a quella richiesta con 400 (Bad Request).
Vedere la sezione 5.2 per ulteriori dettagli sui requisiti del proxy.
5.2 The Resource Identified by a Request (La Risorsa Identificata da una Richiesta)
I server di origine HTTP organizzano tipicamente le loro risorse in un certo spazio dei nomi (namespace). Il Request-URI identifica una risorsa all'interno di quello spazio dei nomi. Su Internet, i server di origine HTTP sono tipicamente accessibili tramite un host Internet e sono identificati (quando utilizzati con HTTP) come URI assoluti utilizzando lo schema "http" o "https". Un server di origine può (MAY) supportare uno o più spazi dei nomi e (quando utilizzato con HTTP) può supportare simultaneamente URI di uno o più schemi.
Consideriamo la seguente Request-Line:
GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1
Il Request-URI identifica la risorsa come:
http://www.w3.org/pub/WWW/TheProject.html
Se questa richiesta arriva direttamente al server di origine www.w3.org, il server dovrebbe (SHOULD) eseguire l'operazione sulla risorsa situata al percorso "/pub/WWW/TheProject.html" su quel server.
Se questa richiesta arriva a un proxy, il Request-URI specifica il server di origine e il proxy dovrebbe (SHOULD) contattare quel server (possibilmente utilizzando la propria cache, come descritto nella sezione 13). Si noti che l'URI fornito dal client nella richiesta può differire dall'URI utilizzato internamente dal server per identificare la risorsa.
Il metodo esatto di identificazione delle risorse utilizzato da un server di origine su Internet è al di fuori dell'ambito di questa specifica. Questa specifica non limita l'implementazione di HTTP richiedendo che l'implementazione utilizzi un file system basato su directory per soddisfare le richieste. Viene utilizzato solo l'URI utilizzato da HTTP per identificare la risorsa per la richiesta data.
5.3 Request Header Fields (Campi di Intestazione di Richiesta)
I campi di intestazione di richiesta consentono al client di passare informazioni aggiuntive sulla richiesta e sul client stesso al server. Questi campi fungono da modificatori di richiesta, con una semantica equivalente ai parametri di una chiamata di metodo in un linguaggio di programmazione.
request-header = Accept ; Section 14.1
| Accept-Charset ; Section 14.2
| Accept-Encoding ; Section 14.3
| Accept-Language ; Section 14.4
| Authorization ; Section 14.8
| Expect ; Section 14.20
| From ; Section 14.22
| Host ; Section 14.23
| If-Match ; Section 14.24
| If-Modified-Since ; Section 14.25
| If-None-Match ; Section 14.26
| If-Range ; Section 14.27
| If-Unmodified-Since ; Section 14.28
| Max-Forwards ; Section 14.31
| Proxy-Authorization ; Section 14.34
| Range ; Section 14.35
| Referer ; Section 14.36
| TE ; Section 14.39
| User-Agent ; Section 14.43
I nomi dei campi di intestazione di richiesta possono essere estesi in modo affidabile solo modificando la versione del protocollo. Tuttavia, nuovi campi di intestazione o sperimentali possono essere assegnati ai valori dei campi senza modificare la versione del protocollo. I campi di intestazione non riconosciuti dovrebbero (SHOULD) essere trattati come campi di intestazione di entità dal destinatario.