Passa al contenuto principale

6. Response (Risposta)

Dopo aver ricevuto e interpretato un messaggio di richiesta, un server risponde con un messaggio di risposta HTTP.

Response      = Status-Line               ; Section 6.1
                *(( general-header        ; Section 4.5
                 | response-header        ; Section 6.2
                 | entity-header ) CRLF)  ; Section 7.1
                CRLF
                [ message-body ]          ; Section 7.2

6.1 Status-Line (Riga di Stato)​

La prima riga di un messaggio di risposta è la Status-Line, composta dalla versione del protocollo seguita da un codice di stato numerico e dalla sua frase di ragione associata, con ogni elemento separato da caratteri SP. Non sono consentiti CR o LF, tranne nella sequenza CRLF finale.

Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

6.1.1 Status Code and Reason Phrase (Codice di Stato e Frase di Ragione)​

L'elemento Status-Code è un codice di risultato intero a 3 cifre del tentativo di comprendere e soddisfare la richiesta. Questi codici sono completamente definiti nella sezione 10. La Reason-Phrase ha lo scopo di fornire una breve descrizione testuale dello Status-Code. Lo Status-Code è destinato all'uso da parte di automi, e la Reason-Phrase è destinata all'utente umano. Il client non è tenuto a esaminare o visualizzare la Reason-Phrase.

La prima cifra dello Status-Code definisce la classe della risposta. Le ultime due cifre non hanno alcun ruolo di categorizzazione. Esistono 5 valori per la prima cifra:

  • 1xx: Informational (Informativo) - La richiesta è stata ricevuta, l'elaborazione continua

  • 2xx: Success (Successo) - L'azione è stata ricevuta, compresa e accettata con successo

  • 3xx: Redirection (Reindirizzamento) - Deve essere intrapresa un'ulteriore azione per completare la richiesta

  • 4xx: Client Error (Errore Client) - La richiesta contiene una sintassi errata o non può essere completata

  • 5xx: Server Error (Errore Server) - Il server non è riuscito a completare una richiesta apparentemente valida

I valori individuali dei codici di stato numerici definiti per HTTP/1.1, insieme a un insieme di esempi corrispondenti di Reason-Phrase, sono presentati di seguito. Le frasi di ragione elencate qui sono solo raccomandazioni - possono (MAY) essere sostituite con equivalenti locali senza influenzare il protocollo.

Status-Code    =
         "100"  ; Section 10.1.1: Continue
       | "101"  ; Section 10.1.2: Switching Protocols
       | "200"  ; Section 10.2.1: OK
       | "201"  ; Section 10.2.2: Created
       | "202"  ; Section 10.2.3: Accepted
       | "203"  ; Section 10.2.4: Non-Authoritative Information
       | "204"  ; Section 10.2.5: No Content
       | "205"  ; Section 10.2.6: Reset Content
       | "206"  ; Section 10.2.7: Partial Content
       | "300"  ; Section 10.3.1: Multiple Choices
       | "301"  ; Section 10.3.2: Moved Permanently
       | "302"  ; Section 10.3.3: Found
       | "303"  ; Section 10.3.4: See Other
       | "304"  ; Section 10.3.5: Not Modified
       | "305"  ; Section 10.3.6: Use Proxy
       | "307"  ; Section 10.3.8: Temporary Redirect
       | "400"  ; Section 10.4.1: Bad Request
       | "401"  ; Section 10.4.2: Unauthorized
       | "402"  ; Section 10.4.3: Payment Required
       | "403"  ; Section 10.4.4: Forbidden
       | "404"  ; Section 10.4.5: Not Found
       | "405"  ; Section 10.4.6: Method Not Allowed
       | "406"  ; Section 10.4.7: Not Acceptable
       | "407"  ; Section 10.4.8: Proxy Authentication Required
       | "408"  ; Section 10.4.9: Request Time-out
       | "409"  ; Section 10.4.10: Conflict
       | "410"  ; Section 10.4.11: Gone
       | "411"  ; Section 10.4.12: Length Required
       | "412"  ; Section 10.4.13: Precondition Failed
       | "413"  ; Section 10.4.14: Request Entity Too Large
       | "414"  ; Section 10.4.15: Request-URI Too Large
       | "415"  ; Section 10.4.16: Unsupported Media Type
       | "416"  ; Section 10.4.17: Requested range not satisfiable
       | "417"  ; Section 10.4.18: Expectation Failed
       | "500"  ; Section 10.5.1: Internal Server Error
       | "501"  ; Section 10.5.2: Not Implemented
       | "502"  ; Section 10.5.3: Bad Gateway
       | "503"  ; Section 10.5.4: Service Unavailable
       | "504"  ; Section 10.5.5: Gateway Time-out
       | "505"  ; Section 10.5.6: HTTP Version not supported
       | extension-code

extension-code = 3DIGIT
Reason-Phrase  = *<TEXT, excluding CR, LF>

I codici di stato HTTP sono estensibili. Le applicazioni HTTP non sono tenute a comprendere il significato di tutti i codici di stato registrati, sebbene tale comprensione sia ovviamente auspicabile. Tuttavia, le applicazioni devono (MUST) comprendere la classe di qualsiasi codice di stato, come indicato dalla prima cifra, e trattare qualsiasi risposta non riconosciuta come equivalente al codice di stato x00 di quella classe, tranne che una risposta non riconosciuta non deve (MUST NOT) essere memorizzata nella cache. Ad esempio, se un client riceve un codice di stato 431 non riconosciuto, può presumere con sicurezza che ci sia un problema con la sua richiesta e trattare la risposta come se avesse ricevuto un codice di stato 400. In tali casi, l'user agent dovrebbe (SHOULD) presentare all'utente l'entità inclusa nella risposta, poiché tale entità è probabile che includa informazioni leggibili dall'uomo che spiegano lo stato insolito.

6.2 Response Header Fields (Campi di Intestazione di Risposta)​

I campi di intestazione di risposta consentono al server di trasmettere informazioni aggiuntive sulla risposta che non possono essere inserite nella Status-Line. Questi campi di intestazione forniscono informazioni sul server e sull'accesso ulteriore alla risorsa identificata dal Request-URI.

response-header = Accept-Ranges           ; Section 14.5
                | Age                     ; Section 14.6
                | ETag                    ; Section 14.19
                | Location                ; Section 14.30
                | Proxy-Authenticate      ; Section 14.33
                | Retry-After             ; Section 14.37
                | Server                  ; Section 14.38
                | Vary                    ; Section 14.44
                | WWW-Authenticate        ; Section 14.47

I nomi dei campi di intestazione di risposta 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.

Ultimo aggiornamento il