From 30feb96f6084a2fb976a24ac01c1f4a054611b62 Mon Sep 17 00:00:00 2001 From: Florian Merz Date: Thu, 11 Feb 2021 14:47:54 +0100 Subject: unslug it: move --- files/it/web/http/basi_http/index.html | 48 ------ files/it/web/http/basics_of_http/index.html | 48 ++++++ files/it/web/http/compression/index.html | 67 ++++++++ files/it/web/http/compressione/index.html | 67 -------- files/it/web/http/content_negotiation/index.html | 143 +++++++++++++++++ .../web/http/headers/user-agent/firefox/index.html | 40 +++++ files/it/web/http/link_prefetching_faq/index.html | 126 +++++++++++++++ .../web/http/negoziazione-del-contenuto/index.html | 143 ----------------- files/it/web/http/overview/index.html | 176 +++++++++++++++++++++ files/it/web/http/panoramica/index.html | 176 --------------------- files/it/web/http/range_requests/index.html | 115 ++++++++++++++ files/it/web/http/richieste_range/index.html | 115 -------------- files/it/web/http/session/index.html | 171 ++++++++++++++++++++ files/it/web/http/sessione/index.html | 171 -------------------- 14 files changed, 886 insertions(+), 720 deletions(-) delete mode 100644 files/it/web/http/basi_http/index.html create mode 100644 files/it/web/http/basics_of_http/index.html create mode 100644 files/it/web/http/compression/index.html delete mode 100644 files/it/web/http/compressione/index.html create mode 100644 files/it/web/http/content_negotiation/index.html create mode 100644 files/it/web/http/headers/user-agent/firefox/index.html create mode 100644 files/it/web/http/link_prefetching_faq/index.html delete mode 100644 files/it/web/http/negoziazione-del-contenuto/index.html create mode 100644 files/it/web/http/overview/index.html delete mode 100644 files/it/web/http/panoramica/index.html create mode 100644 files/it/web/http/range_requests/index.html delete mode 100644 files/it/web/http/richieste_range/index.html create mode 100644 files/it/web/http/session/index.html delete mode 100644 files/it/web/http/sessione/index.html (limited to 'files/it/web/http') diff --git a/files/it/web/http/basi_http/index.html b/files/it/web/http/basi_http/index.html deleted file mode 100644 index cbb668f329..0000000000 --- a/files/it/web/http/basi_http/index.html +++ /dev/null @@ -1,48 +0,0 @@ ---- -title: Le basi dell'HTTP -slug: Web/HTTP/Basi_HTTP -translation_of: Web/HTTP/Basics_of_HTTP ---- -
{{HTTPSidebar}}
- -

HTTP è un protocollo espandibile che si basa su concetti come le risorse e gli URI (Uniform Resource Identifiers), la semplice struttura del messaggio, e il flusso di comunicazione client-server. Oltre a questi concetti di base, nel corso degli anni sono state sviluppate numerose estensioni che aggiungono funzionalità e semantica aggiornate con nuovi metodi HTTP o intestazioni.

- -

Articoli

- -
-
Descrizione dell'HTTP
-
Descrive cos'è l'HTTP e il suo ruolo nell'architettura web, compresa la sua posizione nella pila dei protocolli.
-
Evoluzione dell'HTTP
-
L'HTTP è stato creato all'inizio degli anni '90 ed è stato ampliato più volte. Questo articolo ripercorre la sua storia e descrive HTTP/0.9, HTTP/1.0, HTTP/1.1, e il moderno HTTP/2, oltre alle novità introdotte nel corso degli anni.
-
Risorse e URIs
-
Una breve introduzione al concetto di risorse, identificatori e posizioni sul web.
-
Identificare le risorse sul Web
-
Descrive come sono referenziate le risorse web e come individuarle.
-
Data URIs
-
Un tipo specifico di URI che incorpora direttamente la risorsa che rappresenta. I data URIs sono molto convenienti, ma hanno qualche pecca.
-
Resource URLs {{Non-standard_Inline}}
-
-

I Resource URLs, quelli con il prefisso dello schema delle risorse, sono utilizzati da Firefox e dalle estensioni del browser Firefox per caricare le risorse internamente, ma sono disponibili anche per alcuni siti a cui il browser si connette.

-
-
Separare l'identità e la posizione di una risorsa: L'intestazione HTTP Alt-Svc
-
La maggior parte delle volte l'identità e la posizione di una risorsa web sono condivise, questo può cambiare con l'intestazione Alt-Svc.
-
MIME types
-
Da HTTP/1.0, possono essere trasmessi diversi tipi di contenuto. Questo articolo spiega come questo è compiuto usando l' {{HTTPHeader("Content-Type")}} header e il MIME standard.
-
Choosing between www and non-www URLs
-
Questo articolo fornisce indicazioni sul come scegliere se usi un www-prefixed domain o no, insieme alle conseguenze di quella scelta.
-
Flow of an HTTP session
-
Questo articolo fondamentale descrive una tipica sessione HTTP:
- Cosa succede dietro le quinte quando fai clic su un collegamento nel tuo browser.
-
HTTP Messages
-
I messaggi HTTP trasmessi durante la richiesta o risposta hanno una chiara struttura. Questo articolo introduttivo descrive questa struttura, il suo scopo, e le sue possibilità.
-
Frame and message structure in HTTP/2
-
HTTP/2 eincapsula e rappresenta messaggi HTTP/1.x in un frame binario. Questo articolo spiega la struttura del frame, il suo scopo, e i vari modi con il quale può essere scritto sotto forma di codice.
-
Connection management in HTTP/1.x
-
HTTP/1.1 era la prima versione di HTTP per supportare persistent connection and pipelining. Questo articolo spiega entrambi i concetti.
-
Connection management in HTTP/2
-
HTTP/2 completely revisited how connections are created and maintained. This article explains how HTTP frames allow multiplexing and solve the 'head-of-line' blocking problem of former HTTP versions.
-
Content Negotiation
-
HTTP introduces a set of headers, starting with Accept as a way for a browser to announce the format, language, or encoding it prefers. This article explains how this advertisement happens, how the server is expected to react, and how it chooses the most adequate response.
-
- -
diff --git a/files/it/web/http/basics_of_http/index.html b/files/it/web/http/basics_of_http/index.html new file mode 100644 index 0000000000..cbb668f329 --- /dev/null +++ b/files/it/web/http/basics_of_http/index.html @@ -0,0 +1,48 @@ +--- +title: Le basi dell'HTTP +slug: Web/HTTP/Basi_HTTP +translation_of: Web/HTTP/Basics_of_HTTP +--- +
{{HTTPSidebar}}
+ +

HTTP è un protocollo espandibile che si basa su concetti come le risorse e gli URI (Uniform Resource Identifiers), la semplice struttura del messaggio, e il flusso di comunicazione client-server. Oltre a questi concetti di base, nel corso degli anni sono state sviluppate numerose estensioni che aggiungono funzionalità e semantica aggiornate con nuovi metodi HTTP o intestazioni.

+ +

Articoli

+ +
+
Descrizione dell'HTTP
+
Descrive cos'è l'HTTP e il suo ruolo nell'architettura web, compresa la sua posizione nella pila dei protocolli.
+
Evoluzione dell'HTTP
+
L'HTTP è stato creato all'inizio degli anni '90 ed è stato ampliato più volte. Questo articolo ripercorre la sua storia e descrive HTTP/0.9, HTTP/1.0, HTTP/1.1, e il moderno HTTP/2, oltre alle novità introdotte nel corso degli anni.
+
Risorse e URIs
+
Una breve introduzione al concetto di risorse, identificatori e posizioni sul web.
+
Identificare le risorse sul Web
+
Descrive come sono referenziate le risorse web e come individuarle.
+
Data URIs
+
Un tipo specifico di URI che incorpora direttamente la risorsa che rappresenta. I data URIs sono molto convenienti, ma hanno qualche pecca.
+
Resource URLs {{Non-standard_Inline}}
+
+

I Resource URLs, quelli con il prefisso dello schema delle risorse, sono utilizzati da Firefox e dalle estensioni del browser Firefox per caricare le risorse internamente, ma sono disponibili anche per alcuni siti a cui il browser si connette.

+
+
Separare l'identità e la posizione di una risorsa: L'intestazione HTTP Alt-Svc
+
La maggior parte delle volte l'identità e la posizione di una risorsa web sono condivise, questo può cambiare con l'intestazione Alt-Svc.
+
MIME types
+
Da HTTP/1.0, possono essere trasmessi diversi tipi di contenuto. Questo articolo spiega come questo è compiuto usando l' {{HTTPHeader("Content-Type")}} header e il MIME standard.
+
Choosing between www and non-www URLs
+
Questo articolo fornisce indicazioni sul come scegliere se usi un www-prefixed domain o no, insieme alle conseguenze di quella scelta.
+
Flow of an HTTP session
+
Questo articolo fondamentale descrive una tipica sessione HTTP:
+ Cosa succede dietro le quinte quando fai clic su un collegamento nel tuo browser.
+
HTTP Messages
+
I messaggi HTTP trasmessi durante la richiesta o risposta hanno una chiara struttura. Questo articolo introduttivo descrive questa struttura, il suo scopo, e le sue possibilità.
+
Frame and message structure in HTTP/2
+
HTTP/2 eincapsula e rappresenta messaggi HTTP/1.x in un frame binario. Questo articolo spiega la struttura del frame, il suo scopo, e i vari modi con il quale può essere scritto sotto forma di codice.
+
Connection management in HTTP/1.x
+
HTTP/1.1 era la prima versione di HTTP per supportare persistent connection and pipelining. Questo articolo spiega entrambi i concetti.
+
Connection management in HTTP/2
+
HTTP/2 completely revisited how connections are created and maintained. This article explains how HTTP frames allow multiplexing and solve the 'head-of-line' blocking problem of former HTTP versions.
+
Content Negotiation
+
HTTP introduces a set of headers, starting with Accept as a way for a browser to announce the format, language, or encoding it prefers. This article explains how this advertisement happens, how the server is expected to react, and how it chooses the most adequate response.
+
+ +
diff --git a/files/it/web/http/compression/index.html b/files/it/web/http/compression/index.html new file mode 100644 index 0000000000..59154440d8 --- /dev/null +++ b/files/it/web/http/compression/index.html @@ -0,0 +1,67 @@ +--- +title: Compressione in HTTP +slug: Web/HTTP/Compressione +translation_of: Web/HTTP/Compression +--- +
{{HTTPSidebar}}
+ +

La compressione è un valido modo per incrementare le performance di un sito web. Per alcuni documenti, infatti, la riduzione del peso fino al 70% permette di dimiuire la larghezza di banda necessaria. Nel corso degli anni, inoltre, gli algoritmi sono diventati più efficienti e allo stesso tempo client e server ne supportano di nuovi.

+ +

A livello pratico non è necessario che gli sviluppatori web implementino dei meccanismi di compressione, dato che sia browser che server li hanno già implementati, ma devono tuttavia assicurarsi che il server sia adeguatamente configurato. La compressione avviene a tre livelli differenti:

+ + + +

Formato di compressione dei file

+ +

Ogni tipo di dati ha una certa ridondanza, ovvero uno spreco di spazio. Se il testo può in genere avere una ridondanza fino al 60%, questa percentuale può essere molto più alta per altri media come audio e video. A differenza del testo, questi altri tipi di supporti utilizzano molto spazio per archiviare i dati, di conseguenza la necessità di ottimizzare l'archiviazione e recuperare spazio si manifestò fin da subito. Gli ingegneri hanno progettato l'algoritmo di compressione ottimizzato utilizzato dai formati di file progettati per questo scopo specifico. Gli algoritmi di compressione utilizzati per i file possono essere raggruppati in due grandi categorie:

+ + + +

Alcuni formati possono essere utilizzati sia per la compressione loss-less che lossy, come ad esempio webp, e di solito l'algoritmo di compressione con perdita può essere configurato per comprimere più o meno, il che ovviamente porta a una qualità inferiore o superiore. Per migliorare le prestazioni di un sito Web l'ideale è comprimerlo il più possibile, mantenendo allo stesso tempo un livello di qualità accettabile. Per le immagini, un'immagine generata da uno strumento potrebbe non essere sufficientemente ottimizzata per il Web; si consiglia di utilizzare strumenti che comprimeranno il più possibile con la qualità richiesta. Esistono numerosi strumenti specializzati per questo.

+ +

Gli algoritmi di compressione lossy sono generalmente più efficienti di quelli lossless.

+ +
+

Poiché la compressione funziona meglio su un tipo specifico di file, di solito non fornisce nulla per comprimerli una seconda volta. In effetti, questo è spesso controproducente in quanto il costo del sovraccarico (gli algoritmi di solito richiedono un dizionario che si aggiunge alla dimensione iniziale) può essere superiore al guadagno extra nella compressione risultando in un file più grande. Non utilizzare le due seguenti tecniche per i file in un formato compresso.

+
+ +

Compression End-to-end

+ +

Per la compressione, la compressione end-to-end è il luogo in cui risiedono i maggiori miglioramenti delle prestazioni dei siti Web. La compressione end-to-end si riferisce a una compressione del corpo di un messaggio che viene eseguita dal server e durerà inalterata fino a quando non raggiunge il client. Qualunque siano i nodi intermedi, lasciano il corpo intatto.

+ +

+ +

Tutti i browser e server moderni lo supportano e l'unica cosa da negoziare è l'algoritmo di compressione da utilizzare. Questi algoritmi sono ottimizzati per il testo. Negli anni '90, la tecnologia di compressione stava avanzando a un ritmo rapido e numerosi algoritmi successivi sono stati aggiunti alla serie di scelte possibili. Al giorno d'oggi, solo due sono rilevanti: gzip, il più comune, e br il nuovo sfidante.

+ +

Per selezionare l'algoritmo da utilizzare, i browser e i server utilizzano la negoziazione proattiva dei contenuti. Il browser invia un'intestazione {{HTTPHeader ("Accept-Encoding")}} con l'algoritmo che supporta e il suo ordine di precedenza, il server ne sceglie uno, lo utilizza per comprimere il corpo della risposta e utilizza {{HTTPHeader (" Content-Encoding ")}} per indicare al browser l'algoritmo che ha scelto. Poiché la negoziazione del contenuto è stata utilizzata per scegliere una rappresentazione basata sulla sua codifica, il server deve inviare un'intestazione {{HTTPHeader ("Vary")}} contenente almeno {{HTTPHeader ("Accept-Encoding")}} accanto a questa intestazione in la risposta; in questo modo, le cache saranno in grado di memorizzare nella cache le diverse rappresentazioni della risorsa.

+ +

+ +

Poiché la compressione apporta miglioramenti significativi alle prestazioni, si consiglia di attivarla per tutti i file, ma già compressi come immagini, file audio e video.

+ +

Apache supporta la compressione e utilizza mod_deflate; per nginx c'è ngx_http_gzip_module; per IIS, l'elemento <httpCompression>.

+ +

Hop-by-hop compression

+ +

La compressione hop-by-hop, sebbene simile alla compressione end-to-end, differisce per un elemento fondamentale: la compressione non avviene sulla risorsa nel server, creando una rappresentazione specifica che viene poi trasmessa, ma sul corpo di il messaggio tra due nodi qualsiasi sul percorso tra il client e il server. Le connessioni tra i nodi intermedi successivi possono applicare una compressione diversa.

+ +

+ +

Per fare ciò, HTTP utilizza un meccanismo simile alla negoziazione del contenuto per la compressione end-to-end: il nodo che trasmette la richiesta annuncia la sua volontà utilizzando l'intestazione {{HTTPHeader ("TE")}} e l'altro nodo sceglie il metodo adeguato , lo applica e indica la sua scelta con l'intestazione {{HTTPHeader ("Transfer-Encoding")}}.

+ +

+ +

I

+ +

In pratica, la compressione hop-by-hop è trasparente per il server e il client ed è usata raramente. {{HTTPHeader ("TE")}} e {{HTTPHeader ("Transfer-Encoding")}} sono usati principalmente per inviare una risposta a blocchi, consentendo di iniziare a trasmettere una risorsa senza conoscerne la lunghezza.

+ +

Si noti che l'utilizzo di {{HTTPHeader ("Transfer-Encoding")}} e la compressione a livello di hop è così raro che la maggior parte dei server, come Apache, nginx o IIS, non ha un modo semplice per configurarlo. Tale configurazione di solito avviene a livello di proxy.

diff --git a/files/it/web/http/compressione/index.html b/files/it/web/http/compressione/index.html deleted file mode 100644 index 59154440d8..0000000000 --- a/files/it/web/http/compressione/index.html +++ /dev/null @@ -1,67 +0,0 @@ ---- -title: Compressione in HTTP -slug: Web/HTTP/Compressione -translation_of: Web/HTTP/Compression ---- -
{{HTTPSidebar}}
- -

La compressione è un valido modo per incrementare le performance di un sito web. Per alcuni documenti, infatti, la riduzione del peso fino al 70% permette di dimiuire la larghezza di banda necessaria. Nel corso degli anni, inoltre, gli algoritmi sono diventati più efficienti e allo stesso tempo client e server ne supportano di nuovi.

- -

A livello pratico non è necessario che gli sviluppatori web implementino dei meccanismi di compressione, dato che sia browser che server li hanno già implementati, ma devono tuttavia assicurarsi che il server sia adeguatamente configurato. La compressione avviene a tre livelli differenti:

- - - -

Formato di compressione dei file

- -

Ogni tipo di dati ha una certa ridondanza, ovvero uno spreco di spazio. Se il testo può in genere avere una ridondanza fino al 60%, questa percentuale può essere molto più alta per altri media come audio e video. A differenza del testo, questi altri tipi di supporti utilizzano molto spazio per archiviare i dati, di conseguenza la necessità di ottimizzare l'archiviazione e recuperare spazio si manifestò fin da subito. Gli ingegneri hanno progettato l'algoritmo di compressione ottimizzato utilizzato dai formati di file progettati per questo scopo specifico. Gli algoritmi di compressione utilizzati per i file possono essere raggruppati in due grandi categorie:

- - - -

Alcuni formati possono essere utilizzati sia per la compressione loss-less che lossy, come ad esempio webp, e di solito l'algoritmo di compressione con perdita può essere configurato per comprimere più o meno, il che ovviamente porta a una qualità inferiore o superiore. Per migliorare le prestazioni di un sito Web l'ideale è comprimerlo il più possibile, mantenendo allo stesso tempo un livello di qualità accettabile. Per le immagini, un'immagine generata da uno strumento potrebbe non essere sufficientemente ottimizzata per il Web; si consiglia di utilizzare strumenti che comprimeranno il più possibile con la qualità richiesta. Esistono numerosi strumenti specializzati per questo.

- -

Gli algoritmi di compressione lossy sono generalmente più efficienti di quelli lossless.

- -
-

Poiché la compressione funziona meglio su un tipo specifico di file, di solito non fornisce nulla per comprimerli una seconda volta. In effetti, questo è spesso controproducente in quanto il costo del sovraccarico (gli algoritmi di solito richiedono un dizionario che si aggiunge alla dimensione iniziale) può essere superiore al guadagno extra nella compressione risultando in un file più grande. Non utilizzare le due seguenti tecniche per i file in un formato compresso.

-
- -

Compression End-to-end

- -

Per la compressione, la compressione end-to-end è il luogo in cui risiedono i maggiori miglioramenti delle prestazioni dei siti Web. La compressione end-to-end si riferisce a una compressione del corpo di un messaggio che viene eseguita dal server e durerà inalterata fino a quando non raggiunge il client. Qualunque siano i nodi intermedi, lasciano il corpo intatto.

- -

- -

Tutti i browser e server moderni lo supportano e l'unica cosa da negoziare è l'algoritmo di compressione da utilizzare. Questi algoritmi sono ottimizzati per il testo. Negli anni '90, la tecnologia di compressione stava avanzando a un ritmo rapido e numerosi algoritmi successivi sono stati aggiunti alla serie di scelte possibili. Al giorno d'oggi, solo due sono rilevanti: gzip, il più comune, e br il nuovo sfidante.

- -

Per selezionare l'algoritmo da utilizzare, i browser e i server utilizzano la negoziazione proattiva dei contenuti. Il browser invia un'intestazione {{HTTPHeader ("Accept-Encoding")}} con l'algoritmo che supporta e il suo ordine di precedenza, il server ne sceglie uno, lo utilizza per comprimere il corpo della risposta e utilizza {{HTTPHeader (" Content-Encoding ")}} per indicare al browser l'algoritmo che ha scelto. Poiché la negoziazione del contenuto è stata utilizzata per scegliere una rappresentazione basata sulla sua codifica, il server deve inviare un'intestazione {{HTTPHeader ("Vary")}} contenente almeno {{HTTPHeader ("Accept-Encoding")}} accanto a questa intestazione in la risposta; in questo modo, le cache saranno in grado di memorizzare nella cache le diverse rappresentazioni della risorsa.

- -

- -

Poiché la compressione apporta miglioramenti significativi alle prestazioni, si consiglia di attivarla per tutti i file, ma già compressi come immagini, file audio e video.

- -

Apache supporta la compressione e utilizza mod_deflate; per nginx c'è ngx_http_gzip_module; per IIS, l'elemento <httpCompression>.

- -

Hop-by-hop compression

- -

La compressione hop-by-hop, sebbene simile alla compressione end-to-end, differisce per un elemento fondamentale: la compressione non avviene sulla risorsa nel server, creando una rappresentazione specifica che viene poi trasmessa, ma sul corpo di il messaggio tra due nodi qualsiasi sul percorso tra il client e il server. Le connessioni tra i nodi intermedi successivi possono applicare una compressione diversa.

- -

- -

Per fare ciò, HTTP utilizza un meccanismo simile alla negoziazione del contenuto per la compressione end-to-end: il nodo che trasmette la richiesta annuncia la sua volontà utilizzando l'intestazione {{HTTPHeader ("TE")}} e l'altro nodo sceglie il metodo adeguato , lo applica e indica la sua scelta con l'intestazione {{HTTPHeader ("Transfer-Encoding")}}.

- -

- -

I

- -

In pratica, la compressione hop-by-hop è trasparente per il server e il client ed è usata raramente. {{HTTPHeader ("TE")}} e {{HTTPHeader ("Transfer-Encoding")}} sono usati principalmente per inviare una risposta a blocchi, consentendo di iniziare a trasmettere una risorsa senza conoscerne la lunghezza.

- -

Si noti che l'utilizzo di {{HTTPHeader ("Transfer-Encoding")}} e la compressione a livello di hop è così raro che la maggior parte dei server, come Apache, nginx o IIS, non ha un modo semplice per configurarlo. Tale configurazione di solito avviene a livello di proxy.

diff --git a/files/it/web/http/content_negotiation/index.html b/files/it/web/http/content_negotiation/index.html new file mode 100644 index 0000000000..e2be7de758 --- /dev/null +++ b/files/it/web/http/content_negotiation/index.html @@ -0,0 +1,143 @@ +--- +title: Negoziazione del contenuto +slug: Web/HTTP/negoziazione-del-contenuto +translation_of: Web/HTTP/Content_negotiation +--- +
Nel protocollo HTTP, la negoziazione del contenuto è il meccanismo utilizzato per servire diverse rappresentazioni di una risorsa avente medesimo URI, in modo che il programma utente possa specificare quale sia più adatta all'utente (ad esempio, quale lingua di un documento, quale formato immagine o quale codifica del contenuto).
+ +
+

Nota: alcuni svantaggi della negoziazione del contenuto HTTP sono spiegati in una pagina wiki del WHATWG. HTML5 fornisce alternative alla negoziazione del contenuto tramite, ad esempio, l'elemento <source>.

+
+ +

Principi di negoziazione dei contenuti

+ +

Uno specifico documento è chiamato risorsa. Quando un client desidera ottenere una risorsa, il client la richiede utilizzando il suo URL. Il server utilizza questo URL per scegliere una delle varianti che fornisce - ogni variante viene chiamata rappresentazione - e restituisce una rappresentazione specifica per il client. La risorsa complessiva, così come ciascuna delle rappresentazioni, ha un URL specifico. Il modo in cui viene scelta una rappresentazione specifica quando la risorsa viene chiamata è determinato dalla negoziazione del contenuto e ci sono diversi modi per negoziare tra il client e il server.

+ +

+ +

La determinazione della rappresentazione più adatta avviene attraverso uno dei seguenti meccanismi:

+ + + +

Nel corso degli anni sono state avanzate altre proposte di negoziazione dei contenuti, come la negoziazione trasparente dei contenuti e l'intestazione Alternates, ma non hanno ottenuto la giusta attenzione e sono state quindi abbandonate.

+ +

Negoziazione dei contenuti gestita dal server

+ +

Nella negoziazione del contenuto gestita lato server, o negoziazione proattiva del contenuto, il browser (o qualsiasi altro tipo di user-agent) invia diverse intestazioni HTTP insieme all'URL. Queste intestazioni descrivono la scelta preferita dell'utente. Il server li utilizza come suggerimenti e un algoritmo interno sceglie il contenuto migliore da offrire al client. L'algoritmo è specifico del server e non è definito dallo standard. Vedi, ad esempio, l'algoritmo di negoziazione di Apache.

+ +

+ +

Lo standard HTTP / 1.1 definisce l'elenco delle intestazioni standard che avviano la negoziazione guidata dal server ({{HTTPHeader("Accept")}}, {{HTTPHeader("Accept-Charset")}}, {{HTTPHeader("Accept-Encoding")}}, {{HTTPHeader("Accept-Language")}}). Sebbene in senso stretto {{HTTPHeader ("User-Agent")}} non sia in questo elenco, a volte viene anche utilizzato per inviare una rappresentazione specifica della risorsa richiesta, per quanto questa non sia considerata una buona pratica. Il server utilizza l'intestazione {{HTTPHeader ("Vary")}} per indicare quali intestazioni ha effettivamente utilizzato per la negoziazione del contenuto (o più precisamente le intestazioni di risposta associate), in modo che le cache possano funzionare in modo ottimale.

+ +

Oltre a questi, c'è una proposta sperimentale per aggiungere più intestazioni all'elenco delle intestazioni disponibili, chiamate suggerimenti del client. I suggerimenti del client indicano il tipo di dispositivo su cui viene eseguito l'user agent (ad esempio, se si tratta di un computer desktop o di un dispositivo mobile).

+ +

Anche se la negoziazione del contenuto guidata dal server è il modo più comune per concordare una rappresentazione specifica di una risorsa, presenta diversi svantaggi:

+ + + +

Intestazione Accept

+ +

L’ intestazione {{HTTPHeader("Accept")}} elenca i tipi di risorse media MIME che l’interprete vuole processare. È una lista di elementi MIME separati da virgole, ognuno combinato con un indice di qualità, ovvero un parametro che indica il relativo grado di preferenza tra diversi tipi MIME.

+ +

L’ intestazione {{HTTPHeader("Accept")}} è definita dal browser, o da qualunque altro interprete, e può variare in base al contesto, come ottenre una pagina HTML, un'immagine, un video o uno script: diverge quando si ottiene un documento inserito nella barra degli indirizzi, o un elemento linkato via {{ HTMLElement("img") }}, {{ HTMLElement("video") }} or {{ HTMLElement("audio") }}. I browser sono liberi di usare il valore dell’intestazione che pensano sia il più adeguato; è disponibile una lista di valori standard per I browers più comuni. is available.

+ +

L’intestazione Accept-CH {{experimental_inline}}

+ +
+

Questa è parte di una tecnologia sperimentale chiamata Client Hints. É supportata da Chrome 46 in poi. Il valore Device-Memoryè presente da Chrome 61 in poi.

+
+ +

L’header sperimentale {{HTTPHeader("Accept-CH")}}elenca dati di configurazione che possono essere usati dal server per elaborare una risposta appropriate. I valori validi sono:

+ + + + + + + + + + + + + + + + + + + + + + + + + + +
ValoreSignificato
Device-MemoryIndica in modo approssimativo la quantità di memoria RAM. Questo valore è un approssimazione ottenuta arrotondando alla potenza di due più vicina e dividendo ciò per 1024. Per esempio, 512 megabytes diventano 0.5.
DPRIndica la risoluzione del dispositivo del client.
Viewport-WidthIndica la larghezza dell’area visibile in pixel CSS.
WidthIndica la reale larghezza di una risorsa (per esempio la larghezza di un’immagine).
+ +

L’intestazione Accept-Charset

+ +

L’ intestazione {{HTTPHeader("Accept-Charset")}} indica al server che tipo di codifica dei caratteri viene accettata dall’interprete. DI solito, è impostata con valori differenti per ogni browser locale, per esempio ISO-8859-1,utf-8;q=0.7,*;q=0.7 for a per l’Europa occidentale.

+ +

Essendo UTF-8 molto diffuso e il metodo più usato per la codifica dei caratteri, e per garantire una maggiore privacy attraverso meno configuration-based entropy , il browser omette Accept-Charset l’intestazione: Internet Explorer 8, Safari 5, Opera 11, Firefox 10 e Chrome 27 hanno abbandonato questa intestazione.

+ +

L’intestazione Accept-CH-Lifetime

+ +
+

Questa è parte di una tecnologia sperimentale chiamata Client Hints. É supportata da Chrome 61 in poi.

+
+ +

L’intestazione {{HTTPHeader("Accept-CH-Lifetime")}} è usata con il valore Device-Memory dell’intestazione Accept-CH e indica il tempo che il dispositivo dovrebbe impiegare per condividere una certa quantità di memoria del dispositivo con il server. Il valore è in millisecondi ed è opzionale.

+ +

L’intestazione Accept-Encoding

+ +

L’intestazione {{HTTPHeader("Accept-Encoding")}} definisce il metodo di compressione utilizzato. Il valore è una lista di fattori q (es.: br, gzip;q=0.8) che indica la priorità del valore di codifica. Il valore di default di identità è quello a proprità più bassa (a meno che non sia specificato diversamente).

+ +

La comprensione dei messaggi http è uno dei modi migliori per migliorare le prestazioni di un sito web, esso diminuisce la dimensione dei dati trasmessi permettendo un uso migliore della larghezza di banda; I browser inviano sempre questa intestazone e il server deve essere configurato per addatarsi a tale intestazione ed usare la compressione.

+ +

L' intestazione Accept-Language

+ +

L'intestazione Accept-Language L'intestazone {{HTTPHeader("Accept-Language")}} indica il linguaggio predefinito dell'utente. E' una lista di valori con fattori di qualità(es.:"de, en;q=0.7"). Un valore di default è spesso deciso a seconda del linguaggio dell'interfaccia grafica dell'interprete, ma la maggior parte dei browser permette di impostare lingue differenti.

+ +

A causa dell'aumento dell'uso dei configuration-based entropy si può usare un valore modificato per identificare l'utente, non è consigliato cambiarlo e un sito web non può fidarsi di questo valore per interpretare la richiesta dell'utente. I Site designers non devono essere troppo scrupolosi nell'usare un interprete attraverso questa intestazione dato che risulterebbe scomodo all'utente:

+ + + +

L'intestazione User-Agent 

+ +
+

Anche se esistono usi appropriati di questa intastazione per selezionare contenuto, è considerata una cattiva abitudine affidarsi ad esso per definire quali funzioni sono supportate dall' interprete.

+
+ +

L'intestazione {{HTTPHeader("User-Agent")}} identifica il browser che invia la richiesta. Questa stringa può contenere una lista di product token e commenti separati da spazi.

+ +

Un product token è un nome seguito da '/' e un numero di versione, come Firefox/4.0.1. Ci possono essere tanti product token quanti ne vuole l'interprete. Un comment è una stringa qualsiasi delimitata da parentesi. Ovviamente le parentesi non possono essere usate nella stringa. Il formato del commento non è definito da nessuno standard, ma molti browser ci inseriscono molti token, separati da ';'.

+ +

L'intestazione di risposta Vary 

+ +

In contrasto alle precedenti intestazioni Accept-* che sono inviate dal client, l'intestazione  {{HTTPHeader("Vary")}} è inviata dal web server come risposta. Indica la lista delle intestazioni usate dal server durante la fase di negoziazione gestita dal server. L'intestazione è necessaria per informare la cache dei criteri decisionali in modo da replicarli, permettendo alla cache di essere funzionale e prevenendo l'invio di servizi errati all'utente.

+ +

Il valore '*' esprime che la fase di negoziazione gestita dal server usa anche informazioni non trasmesse in un'intestazione per scegliere il contenuto appropriato.

+ +

L'intestazione Vary è stata aggiunta nella versione HTTP 1.1 ed è necessaria per permettere alle cache di funzionare in modo adeguato. Una cache, per funzionare con la fase di negoziazione gestita dal server necessita di sapere i criteri usati dal server per scegliere il contenuto trasmesso. In questo modo lòa cache può replicare l'argoritmo in modo da fornire contenuti adeguati senza altre richieste al server. Ovviamente il carattere '*' previene la memorizzazione, dato che la cache non conosce che algoritmi ci stanno dietro.

+ +

Negoziazione Agent-driven

+ +

La negoziazione Server-driven presenta alcuni svantaggi: non è molto scalabile. C'è un'intestazione per ogni funzione/caratteristica usate nella negoziazione. Se vuoi usare risoluzione dello schermo deve essere creata una nuova intestazione HTTP. L'invio delle intestazioni deve essere fatto ad ogni richiest. Questo portebrebbe ad una diminuzione delle performance in caso di molte intestazioni. Più intestazioni specifiche vengono inviate, più il complesso risulta ambiguo, portando a problemi di privacy.

+ +

Sin dagli albori di HTTP, il protocollo permette un altro tipo di negoziazione: agent-driven negotiation o reactive negotiation. In questa negoziazione, quando si presenta una richiesta ambigua, il server risponde con una pagina contenente dei link alle risorse alternative disponibili. All'utente vengono presentate le risorse e sceglie quale usare.

+ +

+ +

Sfortunatamente lo standard HTTP non specifica il formato della pagina, permettendo di scegliere tra le risorse disponobili non permettendo una facile automatizzazione del processo. Inoltre si ricade nella negoziazione server-driven, questo metodo è quasi sempre usato insieme allo scripting, specialmente utilizzando JavaScript per i redirect: dopo aver controllato i criteri di memorizzazione, il codice esegue il redirect. Un secondo problema è che è necessaria una richiesta per ottenere la risorsa, compromettendo la disponibilità della risorsa all'utente.

diff --git a/files/it/web/http/headers/user-agent/firefox/index.html b/files/it/web/http/headers/user-agent/firefox/index.html new file mode 100644 index 0000000000..0c4a3c17e2 --- /dev/null +++ b/files/it/web/http/headers/user-agent/firefox/index.html @@ -0,0 +1,40 @@ +--- +title: Gli User Agent di Gecko +slug: Gli_User_Agent_di_Gecko +translation_of: Web/HTTP/Headers/User-Agent/Firefox +--- +

Lista degli user agent rilasciati da Netscape e AOL basati su Gecko™.

+ +

Uso appropriato

+ +

Mozilla consiglia di non utilizzare le stringhe User Agent come mezzo primario di identificazione del browser. Si veda Identificazione del browser e supporto cross browser per uno sguardo in profondità ai vari approcci per la rilevazione del browser.

+ +

In particolare, Mozilla raccomanda di utilizzare lo user agent solo per l'identificazione lato server. Se il codice già esistente per l'identificazione lato client utilizza lo user agent, è possibile semplicemente cercare la stringa "Gecko" per sapere se il browser è basato su questo motore.

+ +

Per l'identificazione di un browser che utilizza Gecko, è possibile utilizzare l'oggetto navigator.

+ +

Gli User Agent di Gecko

+ +

Si veda mozilla.org's user-agent strings reference per i valori specifici delle vociPlatform ,Security ,OS-or-CPU eLocalization .

+ + + +

Per ulteriori dettagli sulle versioni di Netscape e Mozilla, si veda mozilla.org cvstags reference.

+ +

{{ languages( { "ja": "ja/Gecko_User_Agent_Strings", "en": "en/Gecko_User_Agent_Strings", "fr": "fr/Les_cha\u00eenes_UserAgent_de_Gecko" } ) }}

diff --git a/files/it/web/http/link_prefetching_faq/index.html b/files/it/web/http/link_prefetching_faq/index.html new file mode 100644 index 0000000000..41a0e183c1 --- /dev/null +++ b/files/it/web/http/link_prefetching_faq/index.html @@ -0,0 +1,126 @@ +--- +title: Link prefetching FAQ +slug: Link_prefetching_FAQ +tags: + - Gecko + - HTML + - HTTP + - Sviluppo_Web + - Tutte_le_categorie +translation_of: Web/HTTP/Link_prefetching_FAQ +--- + + +

Il link prefetching è un meccanismo del browser, che utilizza il tempo di inattività per il download o effettuare ilprefetch dei documenti che l'utente potrebbe visitare in un futuro prossimo. Una pagina web fornisce dei consigli per il prefetching al browser, il quale dopo averla caricata, comincia in silenzio il prefetchinf dei documenti specificati e li memorizza nella sua cache. Quando l'utente visita uno dei documenti precaricati, quest'ultimo viene servito velocemente a partire dalla cache del browser.

+ +

Cosa sono i prefetching consigliati (prefetching hints)?

+ +

Il browser cerca o un tag HTML link o una intestazione HTTP Link: con una relazione tipo next o prefetch. Ecco un esempio usando il tag link:

+ +
<link rel="prefetch" href="/images/big.jpeg">
+
+ +

Lo stesso suggerimento di prefetch usando una intestazione Link::

+ +
Link: </images/big.jpeg>; rel=prefetch
+
+ +

L'intestazione Link: può anche essere specificata all'interno del documento HTML usando un tag meta:

+ +
<meta http-equiv="Link" content="&lt;/images/big.jpeg&gt;; rel=prefetch">
+
+ +

Il formato dell'intestazione Link: viene descritta nella RFC 2068, sezione 19.6.2.4.

+ +
Nota: internamente facciamo riferimento ad una vecchia specifica di HTTP/1.1 dato che la nuova RFC 2616 non descrive l'intestazione Link:. Nonostante le intestazioni Link: non siano parte dello standard revisionato, vengono pratiacmente ancora usate dai server per specificare fogli di stile CSS, per questi ne facciamo qui uso.
+ +

Il browser osserva tutti questi suggerimenti ed mette in attesa ogni richiesta per poi effettuare il prefetching nel periodo di inattività del browser. Possono esserci molteplici suggerumenti per ogni pagina, per cui avrebbe senso precaricare molteplici documenti. Ad esempio, il prossimo documento potrebbe contenere diverse immagini di grandi dimensioni.

+ +

Seguono alcuni esempi:

+ +
<link rel="prefetch alternate stylesheet" title="Designed for Mozilla" href="mozspecific.css">
+<link rel="next" href="2.html">
+
+ +

Viene eseguito il prefetch sui tag ancora (<a>)?

+ +

No, solo i tag <link> con un tipo relazione next o prefetch vengono precaricati. Comunque, in caso di interesse sufficiente, potremmo pensare di estendere il supporto prefetching ai tag <a> che includono un tipo relazione next o prefetch. Fare questo potrebbe aiutare i fornitori di contenuti ad evitare il problema di aggiornare i link precaricati.

+ +

Il prefetching è attinente agli standard?

+ +

Si, il prefetching di link, come descritto in questo documento, non viola nessuno standard web. Infatti, le specifiche HTML 4.01 permettono esplicitamente la definizione di nuovi tipi relazione link (vedere la Sezione 6.12: Link types). Comunque, l'esatto meccanismo usato da Mozilla non è ancora parte dello standard. Un draft è in preparazione.

+ +

Come viene determinato il periodo di inattività (idle) del browser?

+ +

Nell'implementazione corrente (Mozilla 1.2), il tempo di inattività si determina usando l'API nsIWebProgressListener. Si collega un listener all'oggetto nsIWebProgress ("@mozilla.org/docloaderservice;1"). Da questo, si ricevono notifiche di start e stop, e si approssima il tempo di inattività come il periodo tra l'ultimo documento dal caricamento terminato ed il primo documento dal caricamento iniziato. La notifica dello stop dell'ultimo documento avviene approssimativamente quando il gestore onLoad inizia la sua attività per il documento. Questo accade quando si dà il via a richieste di prefetch. Se un frame figlio contiene suggerimenti di prefetching, il prefetch non inizierà fino a che non siano caricati il documento padre e tutti i figli.

+ + + +

QUando l'utente clicca un link, o inizia un qualche tipo di caricamento di pagina, il prefetch di link si interrompe ed ogni suggerimento di prefetch viene ignorato. Se un documento precaricato è stato parzialmente scaricato, viene comunque memorizzato nella cache se il server invia una intestazione "Accept-Ranges: bytes". Questa intestazione viene tipicamente generata dal webserver nel fornire un documento statico. QUando l'utente visita realmente un documento precaricato, la rimanente porzione del documento viene caricata usando una richiesta HTTP byte-range.

+ + + +

Si e no. Se si sta scaricando qualcosa usando Mozilla, il link prefetching verrà posticipato fino a che i download in background non saranno completati. Ad esempio, se si carica un gruppo di segnalibri (il che significa aprire diverse tab), ogni richiesta di prefetch iniziata da una delle pagine di segnalibro non inizierà fino a quando tutte le tab non avranno terminato il caricamento. Se si usa un'altra applicazione di rete, il link prefetching potrebbe competere per la banda con l'altra applicazione. Questo è un problema che speriamo di risolvere in futuro usando i servizi del sistema operativo per controllare il tempo di inattività della connesione.

+ +

Ci sono restrizioni su cosa viene eseguito il prefetching?

+ +

Si, solo gli URL http:// possono essere precaricati (URL https:// non sono mai precaricato per ragioni di sicurezza). Altri protocolli (come FTP) non forniscono un supporto abbastanza ricco per il caching da lato client. In aggiunta a questa restrizione, gli URL conquery strings (stringhe di interrogazione) non sono precaricate. Questo perché alcuni URL inviano a documenti che non possono essere riutilizzati fuori dalla cache del browser, per cui il prefetching non darebbe grandi risultati. Abbiamo visto come siti esistenti utilizzino il tag <link rel="next"> con degli URL contenenti query string per fare riferimento al prossimo documento di una serie. Bugzilla ne è un esempio, e questo fa si che i sui report non siano memorizzabili in cache, per cui il prefetch degli URL raddoppierebbe il carico del server del pover Bugzilla! Si possono failmente pensare che altri siti siano stati progettati come Bugzilla, per cui noi esplicitamente non facciamo eseguire il prefetch degli URL con query string. (Avrebbe sensio permettere il prefecth di questi documenti quando è specificato il tipo relazione rel=prefetch, dato che non dovrebbe apparire in nessun contenuto esistente.) Non ci sono altre restrizioni sugli URL precaricati.

+ +

Mozilla effettua il prefetch di documenti da host differenti?

+ +

Si. Non ci sono restrizioni sull'origine dei documenti per il link prefetching. Litare il prefetching solo agli URL dello stesso server non offrirebbe nessun aumento della sicurezza del browser.

+ +

Le richieste da prefetching contengono una intestazione Refer: ?

+ +

Sì, le richieste da prefetch includono una intestazione HTTP Referer: indicante il documento dal quale il suggerimento di prefetch è stato estratto.

+ +

Questo potrebbe avere impatto sul tracciamento dei refer solitamente usato in molti siti. Per questo, il link prefetching potrebbe non essere appropriato per tutti i contenuti. Comunque, è possibile istruire Mozilla per validare un documento precaricato quando l'utente segue un href verso il documento precaricato, specificando l'intestazione HTTP Cache-control: must-revalidate. Questa intestazione abilita la memorizzazione in cache, ma ha necessita di una richiesta di validazione If-Modified-Since o If-None-Match prima di servire il documento dalla cache stessa.

+ +

Come amministratore di server, posso distinguere tra richieste di prefetch e richieste normali?

+ +

Si, mandiamo la seguente intestazione insieme con la richiesta di prefetch:

+ +
X-moz: prefetch
+ +

Ovviamente, questa intestazione di richiesta non è del tutto standard, e potrebbe cambiare in future release di Mozilla.

+ +

C'è una opzione per disabilitare il prefetching di link?

+ +

Si, c'è una preferenza nascosta da impostare per disabilatare il link prefetching. Aggiungere questa linea a prefs.js nella directory del proprio profilo di Mozilla.

+ +
user_pref("network.prefetch-next",false);
+ +

Stiamo considerando di aggiungere una Interfaccia Utente per questa preferenza (vedere {{ Bug(166648) }}); in ogni caso, la nostra teoria è che se il link prefetching deve essere disabilitato allora qualcosa è sagliato nella sua implementazione. Cerchiamo di migliorare l'implementazione se questa si rivelasse errata, piuttosto che attenderci che gli utenti vadano a cercare qualche oscura voce di preferenza nell'interfaccia uente. Diamine, l'interfaccia utente di Mozilla per le opzioni è già abbastanza piena ;-)

+ +
Aggiornamento: causa la moltitudine di richieste, Mozilla 1.3+ include una opzione di preferenza nell'interfaccia utente per disabilitare il prefetching. Vedere Preferences->Advanced-> +
user_pref("network.prefetch-next",false);
+
+ +

Riguardo alle persone che pagano per avere banda?

+ +

Basically, there are two ways of looking at this issue: # websites can already cause things to be silently downloaded using JS/DOM hacks. # prefetching is a browser feature; users should be able to disable it easily. It is important that websites adopt <code><link></code> tag based prefetching instead of trying to roll-in silent downloading using various JS/DOM hacks. The <code><link></code> tag gives the browser the ability to know what sites are up to, and we can use this information to better prioritize document prefetching. The user preference to disable <code><link></code> tag prefetching may simply encourage websites to stick with JS/DOM hacks, and that would not be good for users. This is one reason why prefetching is enabled by default.

+ + + +

I browser basati su Mozilla 1.2 (o successivi) così come browser basati su Mozilla 1.0.2 (o successivi) supportano il prefetching. Questo include Firefox e Netscape 7.01+. Le build di Camino da Marzo 2003 sono basate su Mozilla 1.0.1, pre cui non supportano il prefetching.

+ +

Effettua un test con il tuo browser per vedere se supporta il Link Prefetching.

+ +

Cos'altro riguardo...?

+ +

Per qualasiasi altra domanda o commento riguardo al link prefetching, mandatele pure a me :-)

+ +

Vedere inoltre...

+ +

Prefetching Hints

+ +
+

Original Document Information

+ + +
+ +

{{ languages( { "en": "en/Link_prefetching_FAQ" } ) }}

diff --git a/files/it/web/http/negoziazione-del-contenuto/index.html b/files/it/web/http/negoziazione-del-contenuto/index.html deleted file mode 100644 index e2be7de758..0000000000 --- a/files/it/web/http/negoziazione-del-contenuto/index.html +++ /dev/null @@ -1,143 +0,0 @@ ---- -title: Negoziazione del contenuto -slug: Web/HTTP/negoziazione-del-contenuto -translation_of: Web/HTTP/Content_negotiation ---- -
Nel protocollo HTTP, la negoziazione del contenuto è il meccanismo utilizzato per servire diverse rappresentazioni di una risorsa avente medesimo URI, in modo che il programma utente possa specificare quale sia più adatta all'utente (ad esempio, quale lingua di un documento, quale formato immagine o quale codifica del contenuto).
- -
-

Nota: alcuni svantaggi della negoziazione del contenuto HTTP sono spiegati in una pagina wiki del WHATWG. HTML5 fornisce alternative alla negoziazione del contenuto tramite, ad esempio, l'elemento <source>.

-
- -

Principi di negoziazione dei contenuti

- -

Uno specifico documento è chiamato risorsa. Quando un client desidera ottenere una risorsa, il client la richiede utilizzando il suo URL. Il server utilizza questo URL per scegliere una delle varianti che fornisce - ogni variante viene chiamata rappresentazione - e restituisce una rappresentazione specifica per il client. La risorsa complessiva, così come ciascuna delle rappresentazioni, ha un URL specifico. Il modo in cui viene scelta una rappresentazione specifica quando la risorsa viene chiamata è determinato dalla negoziazione del contenuto e ci sono diversi modi per negoziare tra il client e il server.

- -

- -

La determinazione della rappresentazione più adatta avviene attraverso uno dei seguenti meccanismi:

- - - -

Nel corso degli anni sono state avanzate altre proposte di negoziazione dei contenuti, come la negoziazione trasparente dei contenuti e l'intestazione Alternates, ma non hanno ottenuto la giusta attenzione e sono state quindi abbandonate.

- -

Negoziazione dei contenuti gestita dal server

- -

Nella negoziazione del contenuto gestita lato server, o negoziazione proattiva del contenuto, il browser (o qualsiasi altro tipo di user-agent) invia diverse intestazioni HTTP insieme all'URL. Queste intestazioni descrivono la scelta preferita dell'utente. Il server li utilizza come suggerimenti e un algoritmo interno sceglie il contenuto migliore da offrire al client. L'algoritmo è specifico del server e non è definito dallo standard. Vedi, ad esempio, l'algoritmo di negoziazione di Apache.

- -

- -

Lo standard HTTP / 1.1 definisce l'elenco delle intestazioni standard che avviano la negoziazione guidata dal server ({{HTTPHeader("Accept")}}, {{HTTPHeader("Accept-Charset")}}, {{HTTPHeader("Accept-Encoding")}}, {{HTTPHeader("Accept-Language")}}). Sebbene in senso stretto {{HTTPHeader ("User-Agent")}} non sia in questo elenco, a volte viene anche utilizzato per inviare una rappresentazione specifica della risorsa richiesta, per quanto questa non sia considerata una buona pratica. Il server utilizza l'intestazione {{HTTPHeader ("Vary")}} per indicare quali intestazioni ha effettivamente utilizzato per la negoziazione del contenuto (o più precisamente le intestazioni di risposta associate), in modo che le cache possano funzionare in modo ottimale.

- -

Oltre a questi, c'è una proposta sperimentale per aggiungere più intestazioni all'elenco delle intestazioni disponibili, chiamate suggerimenti del client. I suggerimenti del client indicano il tipo di dispositivo su cui viene eseguito l'user agent (ad esempio, se si tratta di un computer desktop o di un dispositivo mobile).

- -

Anche se la negoziazione del contenuto guidata dal server è il modo più comune per concordare una rappresentazione specifica di una risorsa, presenta diversi svantaggi:

- - - -

Intestazione Accept

- -

L’ intestazione {{HTTPHeader("Accept")}} elenca i tipi di risorse media MIME che l’interprete vuole processare. È una lista di elementi MIME separati da virgole, ognuno combinato con un indice di qualità, ovvero un parametro che indica il relativo grado di preferenza tra diversi tipi MIME.

- -

L’ intestazione {{HTTPHeader("Accept")}} è definita dal browser, o da qualunque altro interprete, e può variare in base al contesto, come ottenre una pagina HTML, un'immagine, un video o uno script: diverge quando si ottiene un documento inserito nella barra degli indirizzi, o un elemento linkato via {{ HTMLElement("img") }}, {{ HTMLElement("video") }} or {{ HTMLElement("audio") }}. I browser sono liberi di usare il valore dell’intestazione che pensano sia il più adeguato; è disponibile una lista di valori standard per I browers più comuni. is available.

- -

L’intestazione Accept-CH {{experimental_inline}}

- -
-

Questa è parte di una tecnologia sperimentale chiamata Client Hints. É supportata da Chrome 46 in poi. Il valore Device-Memoryè presente da Chrome 61 in poi.

-
- -

L’header sperimentale {{HTTPHeader("Accept-CH")}}elenca dati di configurazione che possono essere usati dal server per elaborare una risposta appropriate. I valori validi sono:

- - - - - - - - - - - - - - - - - - - - - - - - - - -
ValoreSignificato
Device-MemoryIndica in modo approssimativo la quantità di memoria RAM. Questo valore è un approssimazione ottenuta arrotondando alla potenza di due più vicina e dividendo ciò per 1024. Per esempio, 512 megabytes diventano 0.5.
DPRIndica la risoluzione del dispositivo del client.
Viewport-WidthIndica la larghezza dell’area visibile in pixel CSS.
WidthIndica la reale larghezza di una risorsa (per esempio la larghezza di un’immagine).
- -

L’intestazione Accept-Charset

- -

L’ intestazione {{HTTPHeader("Accept-Charset")}} indica al server che tipo di codifica dei caratteri viene accettata dall’interprete. DI solito, è impostata con valori differenti per ogni browser locale, per esempio ISO-8859-1,utf-8;q=0.7,*;q=0.7 for a per l’Europa occidentale.

- -

Essendo UTF-8 molto diffuso e il metodo più usato per la codifica dei caratteri, e per garantire una maggiore privacy attraverso meno configuration-based entropy , il browser omette Accept-Charset l’intestazione: Internet Explorer 8, Safari 5, Opera 11, Firefox 10 e Chrome 27 hanno abbandonato questa intestazione.

- -

L’intestazione Accept-CH-Lifetime

- -
-

Questa è parte di una tecnologia sperimentale chiamata Client Hints. É supportata da Chrome 61 in poi.

-
- -

L’intestazione {{HTTPHeader("Accept-CH-Lifetime")}} è usata con il valore Device-Memory dell’intestazione Accept-CH e indica il tempo che il dispositivo dovrebbe impiegare per condividere una certa quantità di memoria del dispositivo con il server. Il valore è in millisecondi ed è opzionale.

- -

L’intestazione Accept-Encoding

- -

L’intestazione {{HTTPHeader("Accept-Encoding")}} definisce il metodo di compressione utilizzato. Il valore è una lista di fattori q (es.: br, gzip;q=0.8) che indica la priorità del valore di codifica. Il valore di default di identità è quello a proprità più bassa (a meno che non sia specificato diversamente).

- -

La comprensione dei messaggi http è uno dei modi migliori per migliorare le prestazioni di un sito web, esso diminuisce la dimensione dei dati trasmessi permettendo un uso migliore della larghezza di banda; I browser inviano sempre questa intestazone e il server deve essere configurato per addatarsi a tale intestazione ed usare la compressione.

- -

L' intestazione Accept-Language

- -

L'intestazione Accept-Language L'intestazone {{HTTPHeader("Accept-Language")}} indica il linguaggio predefinito dell'utente. E' una lista di valori con fattori di qualità(es.:"de, en;q=0.7"). Un valore di default è spesso deciso a seconda del linguaggio dell'interfaccia grafica dell'interprete, ma la maggior parte dei browser permette di impostare lingue differenti.

- -

A causa dell'aumento dell'uso dei configuration-based entropy si può usare un valore modificato per identificare l'utente, non è consigliato cambiarlo e un sito web non può fidarsi di questo valore per interpretare la richiesta dell'utente. I Site designers non devono essere troppo scrupolosi nell'usare un interprete attraverso questa intestazione dato che risulterebbe scomodo all'utente:

- - - -

L'intestazione User-Agent 

- -
-

Anche se esistono usi appropriati di questa intastazione per selezionare contenuto, è considerata una cattiva abitudine affidarsi ad esso per definire quali funzioni sono supportate dall' interprete.

-
- -

L'intestazione {{HTTPHeader("User-Agent")}} identifica il browser che invia la richiesta. Questa stringa può contenere una lista di product token e commenti separati da spazi.

- -

Un product token è un nome seguito da '/' e un numero di versione, come Firefox/4.0.1. Ci possono essere tanti product token quanti ne vuole l'interprete. Un comment è una stringa qualsiasi delimitata da parentesi. Ovviamente le parentesi non possono essere usate nella stringa. Il formato del commento non è definito da nessuno standard, ma molti browser ci inseriscono molti token, separati da ';'.

- -

L'intestazione di risposta Vary 

- -

In contrasto alle precedenti intestazioni Accept-* che sono inviate dal client, l'intestazione  {{HTTPHeader("Vary")}} è inviata dal web server come risposta. Indica la lista delle intestazioni usate dal server durante la fase di negoziazione gestita dal server. L'intestazione è necessaria per informare la cache dei criteri decisionali in modo da replicarli, permettendo alla cache di essere funzionale e prevenendo l'invio di servizi errati all'utente.

- -

Il valore '*' esprime che la fase di negoziazione gestita dal server usa anche informazioni non trasmesse in un'intestazione per scegliere il contenuto appropriato.

- -

L'intestazione Vary è stata aggiunta nella versione HTTP 1.1 ed è necessaria per permettere alle cache di funzionare in modo adeguato. Una cache, per funzionare con la fase di negoziazione gestita dal server necessita di sapere i criteri usati dal server per scegliere il contenuto trasmesso. In questo modo lòa cache può replicare l'argoritmo in modo da fornire contenuti adeguati senza altre richieste al server. Ovviamente il carattere '*' previene la memorizzazione, dato che la cache non conosce che algoritmi ci stanno dietro.

- -

Negoziazione Agent-driven

- -

La negoziazione Server-driven presenta alcuni svantaggi: non è molto scalabile. C'è un'intestazione per ogni funzione/caratteristica usate nella negoziazione. Se vuoi usare risoluzione dello schermo deve essere creata una nuova intestazione HTTP. L'invio delle intestazioni deve essere fatto ad ogni richiest. Questo portebrebbe ad una diminuzione delle performance in caso di molte intestazioni. Più intestazioni specifiche vengono inviate, più il complesso risulta ambiguo, portando a problemi di privacy.

- -

Sin dagli albori di HTTP, il protocollo permette un altro tipo di negoziazione: agent-driven negotiation o reactive negotiation. In questa negoziazione, quando si presenta una richiesta ambigua, il server risponde con una pagina contenente dei link alle risorse alternative disponibili. All'utente vengono presentate le risorse e sceglie quale usare.

- -

- -

Sfortunatamente lo standard HTTP non specifica il formato della pagina, permettendo di scegliere tra le risorse disponobili non permettendo una facile automatizzazione del processo. Inoltre si ricade nella negoziazione server-driven, questo metodo è quasi sempre usato insieme allo scripting, specialmente utilizzando JavaScript per i redirect: dopo aver controllato i criteri di memorizzazione, il codice esegue il redirect. Un secondo problema è che è necessaria una richiesta per ottenere la risorsa, compromettendo la disponibilità della risorsa all'utente.

diff --git a/files/it/web/http/overview/index.html b/files/it/web/http/overview/index.html new file mode 100644 index 0000000000..f2cf4c990c --- /dev/null +++ b/files/it/web/http/overview/index.html @@ -0,0 +1,176 @@ +--- +title: Una panoramica su HTTP +slug: Web/HTTP/Panoramica +tags: + - HTTP + - Protocolli +translation_of: Web/HTTP/Overview +--- +
{{HTTPSidebar}}
+ +

HTTP è un {{Glossary("protocollo")}} che permette il recupero di risorse, come le pagine HTML. È il fondamento di ogni scambio di dati sul Web ed è un protocollo client-server,il che significa che le richieste vengono avviate dal destinatario, solitamente il browser Web. Un documento completo viene ricostruito dai diversi sotto-documenti recuperati, ad esempio testo, descrizione del layout, immagini, video, script e altro.

+ +

A Web document is the composition of different resources

+ +

Client e server comunicano scambiando messaggi individuali (al contrario di un flusso di dati). I messaggi inviati dal client, solitamente un browser Web, sono chiamati richieste (requests) e i messaggi inviati dal server come risposta sono chiamati risposte (responses).

+ +

HTTP as an application layer protocol, on top of TCP (transport layer) and IP (network layer) and below the presentation layer.Progettato all'inizio degli anni '90 (1990), HTTP è un protocollo estensibile che si è evoluto nel tempo. È un protocollo a livello di applicazione che viene inviato mediante {{Glossary("TCP")}}, o mediante una connessione TCP cifrata {{Glossary("TLS")}}, anche se teoricamente potrebbe essere utilizzato qualsiasi protocollo di trasporto affidabile. Grazie alla sua estensibilità, viene utilizzato non solo per recuperare documenti ipertestuali, ma anche immagini e video o per pubblicare contenuti su server, come con i risultati dei moduli HTML. HTTP può essere utilizzato anche per recuperare parti di documenti per aggiornare pagine Web su richiesta.

+ +

Componenti di sistemi basati su HTTP

+ +

HTTP è un protocollo client-server: le richieste vengono inviate da un'entità, lo user-agent (o un proxy per conto di esso). Il più delle volte lo user-agent è un browser Web, ma può essere qualsiasi cosa, ad esempio un robot che esegue la scansione del Web per popolare e mantenere un indice del motore di ricerca.

+ +

Ogni singola richiesta viene inviata a un server, che la gestisce e fornisce una risposta, chiamata response. Tra il client e il server ci sono numerose entità, chiamate collettivamente {{Glossary("Proxy_server", "proxies")}}, che eseguono operazioni diverse e fungono da gateway o {{Glossary("Cache", "caches")}}, per esempio.

+ +

Client server chain

+ +

In realtà, ci sono più computer tra un browser e il server che gestisce la richiesta: ci sono router, modem e altro. Grazie alla struttura a strati del Web, questi sono nascosti nella rete e nei livelli di trasporto. L'HTTP è in cima, a livello applicazione. Sebbene importanti per diagnosticare i problemi di rete, i livelli sottostanti sono per lo più irrilevanti per la descrizione di HTTP.

+ +

Client: lo user-agent

+ +

Lo user-agent è qualsiasi strumento che agisce per conto dell'utente. Questo ruolo viene svolto principalmente dal browser Web; altre possibilità sono i programmi utilizzati da ingegneri e sviluppatori Web per eseguire il debug delle loro applicazioni.

+ +

Il browser è sempre l'entità che avvia la richiesta. Non è mai il server (sebbene nel corso degli anni siano stati aggiunti alcuni meccanismi per simulare i messaggi avviati dal server).

+ +

Per presentare una pagina Web, il browser invia una richiesta iniziale per recuperare il documento HTML che rappresenta la pagina. Quindi analizza questo file, effettuando richieste aggiuntive corrispondenti a script di esecuzione, informazioni sul layout (CSS) da visualizzare e sotto-risorse contenute all'interno della pagina (solitamente immagini e video). Il browser Web quindi compone queste risorse per presentare all'utente un documento completo, la pagina Web. Gli script eseguiti dal browser possono recuperare più risorse nelle fasi successive e il browser aggiorna la pagina Web di conseguenza.

+ +

Una pagina Web è un documento ipertestuale. Ciò significa che alcune parti del testo visualizzato sono collegamenti che possono essere attivati (di solito con un clic del mouse) per recuperare una nuova pagina Web, consentendo all'utente di dirigere il proprio user-agent e navigare nel Web. Il browser traduce queste indicazioni in richieste HTTP e interpreta ulteriormente le risposte HTTP per presentare all'utente una risposta chiara.

+ +

Il Web server

+ +

Sul lato opposto del canale di comunicazione, è il server, che serve (restituisce) il documento come richiesto dal client. Un server appare virtualmente come un'unica macchina: questo perché potrebbe essere un insieme di server, i quali condividono il carico (bilanciamento del carico) o un complesso software che interroga altri computer (come una cache, un DB server o un e-commerce server), generando totalmente o parzialmente il documento su richiesta.

+ +

Un server non è necessariamente una singola macchina, ma più istanze di software server possono essere ospitate sulla stessa macchina. Con HTTP / 1.1 e l'intestazione {{HTTPHeader ("Host")}}, possono persino condividere lo stesso indirizzo IP. HERE!!!

+ +

Proxies

+ +

Between the Web browser and the server, numerous computers and machines relay the HTTP messages. Due to the layered structure of the Web stack, most of these operate at the transport, network or physical levels, becoming transparent at the HTTP layer and potentially making a significant impact on performance. Those operating at the application layers are generally called proxies. These can be transparent, forwarding on the requests they receive without altering them in any way, or non-transparent, in which case they will change the request in some way before passing it along to the server. Proxies may perform numerous functions:

+ + + +

Basic aspects of HTTP

+ +

HTTP is simple

+ +

HTTP is generally designed to be simple and human readable, even with the added complexity introduced in HTTP/2 by encapsulating HTTP messages into frames. HTTP messages can be read and understood by humans, providing easier testing for developers, and reduced complexity for newcomers.

+ +

HTTP is extensible

+ +

Introduced in HTTP/1.0, HTTP headers make this protocol easy to extend and experiment with. New functionality can even be introduced by a simple agreement between a client and a server about a new header's semantics.

+ +

HTTP is stateless, but not sessionless

+ +

HTTP is stateless: there is no link between two requests being successively carried out on the same connection. This immediately has the prospect of being problematic for users attempting to interact with certain pages coherently, for example, using e-commerce shopping baskets. But while the core of HTTP itself is stateless, HTTP cookies allow the use of stateful sessions. Using header extensibility, HTTP Cookies are added to the workflow, allowing session creation on each HTTP request to share the same context, or the same state.

+ +

HTTP and connections

+ +

A connection is controlled at the transport layer, and therefore fundamentally out of scope for HTTP. Though HTTP doesn't require the underlying transport protocol to be connection-based; only requiring it to be reliable, or not lose messages (so at minimum presenting an error). Among the two most common transport protocols on the Internet, TCP is reliable and UDP isn't. HTTP therefore relies on the TCP standard, which is connection-based.

+ +

Before a client and server can exchange an HTTP request/response pair, they must establish a TCP connection, a process which requires several round-trips. The default behavior of HTTP/1.0 is to open a separate TCP connection for each HTTP request/response pair. This is less efficient than sharing a single TCP connection when multiple requests are sent in close succession.

+ +

In order to mitigate this flaw, HTTP/1.1 introduced pipelining (which proved difficult to implement) and persistent connections: the underlying TCP connection can be partially controlled using the {{HTTPHeader("Connection")}} header. HTTP/2 went a step further by multiplexing messages over a single connection, helping keep the connection warm and more efficient.

+ +

Experiments are in progress to design a better transport protocol more suited to HTTP. For example, Google is experimenting with QUIC which builds on UDP to provide a more reliable and efficient transport protocol.

+ +

What can be controlled by HTTP

+ +

This extensible nature of HTTP has, over time, allowed for more control and functionality of the Web. Cache or authentication methods were functions handled early in HTTP history. The ability to relax the origin constraint, by contrast, has only been added in the 2010s.

+ +

Here is a list of common features controllable with HTTP.

+ + + +

HTTP flow

+ +

When a client wants to communicate with a server, either the final server or an intermediate proxy, it performs the following steps:

+ +
    +
  1. Open a TCP connection: The TCP connection is used to send a request, or several, and receive an answer. The client may open a new connection, reuse an existing connection, or open several TCP connections to the servers.
    2. +
  2. Send an HTTP message: HTTP messages (before HTTP/2) are human-readable. With HTTP/2, these simple messages are encapsulated in frames, making them impossible to read directly, but the principle remains the same. For example: + 
    GET / HTTP/1.1
+Host: developer.mozilla.org
+Accept-Language: fr
    +
    3. +
  3. Read the response sent by the server, such as: + 
    HTTP/1.1 200 OK
+Date: Sat, 09 Oct 2010 14:28:02 GMT
+Server: Apache
+Last-Modified: Tue, 01 Dec 2009 20:18:22 GMT
+ETag: "51142bc1-7449-479b075b2891b"
+Accept-Ranges: bytes
+Content-Length: 29769
+Content-Type: text/html
+
+<!DOCTYPE html... (here comes the 29769 bytes of the requested web page)
    +
    4. +
  4. Close or reuse the connection for further requests.
    5. +
+ +

If HTTP pipelining is activated, several requests can be sent without waiting for the first response to be fully received. HTTP pipelining has proven difficult to implement in existing networks, where old pieces of software coexist with modern versions. HTTP pipelining has been superseded in HTTP/2 with more robust multiplexing requests within a frame.

+ +

HTTP Messages

+ +

HTTP messages, as defined in HTTP/1.1 and earlier, are human-readable. In HTTP/2, these messages are embedded into a binary structure, a frame, allowing optimizations like compression of headers and multiplexing. Even if only part of the original HTTP message is sent in this version of HTTP, the semantics of each message is unchanged and the client reconstitutes (virtually) the original HTTP/1.1 request. It is therefore useful to comprehend HTTP/2 messages in the HTTP/1.1 format.

+ +

There are two types of HTTP messages, requests and responses, each with its own format.

+ +

Requests

+ +

An example HTTP request:

+ +

A basic HTTP request

+ +

Requests consists of the following elements:

+ + + +

Responses

+ +

An example response:

+ +

+ +

Responses consist of the following elements:

+ + + +

APIs based on HTTP

+ +

The most commonly used API based on HTTP is the {{domxref("XMLHttpRequest")}} API, which can be used to exchange data between a {{Glossary("user agent")}} and a server. The modern {{domxref("Fetch API")}} provides the same features with a more powerful and flexible feature set.

+ +

Another API, server-sent events, is a one-way service that allows a server to send events to the client, using HTTP as a transport mechanism. Using the {{domxref("EventSource")}} interface, the client opens a connection and establishes event handlers. The client browser automatically converts the messages that arrive on the HTTP stream into appropriate {{domxref("Event")}} objects, delivering them to the event handlers that have been registered for the events' {{domxref("Event.type", "type")}} if known, or to the {{domxref("EventSource.onmessage", "onmessage")}} event handler if no type-specific event handler was established.

+ +

Conclusion

+ +

HTTP è un protocollo estensibile che è facile da usare. The client-server structure, combined with the ability to simply add headers, allows HTTP to advance along with the extended capabilities of the Web.

+ +

Though HTTP/2 adds some complexity, by embedding HTTP messages in frames to improve performance, the basic structure of messages has stayed the same since HTTP/1.0. Session flow remains simple, allowing it to be investigated, and debugged with a simple HTTP message monitor.

diff --git a/files/it/web/http/panoramica/index.html b/files/it/web/http/panoramica/index.html deleted file mode 100644 index f2cf4c990c..0000000000 --- a/files/it/web/http/panoramica/index.html +++ /dev/null @@ -1,176 +0,0 @@ ---- -title: Una panoramica su HTTP -slug: Web/HTTP/Panoramica -tags: - - HTTP - - Protocolli -translation_of: Web/HTTP/Overview ---- -
{{HTTPSidebar}}
- -

HTTP è un {{Glossary("protocollo")}} che permette il recupero di risorse, come le pagine HTML. È il fondamento di ogni scambio di dati sul Web ed è un protocollo client-server,il che significa che le richieste vengono avviate dal destinatario, solitamente il browser Web. Un documento completo viene ricostruito dai diversi sotto-documenti recuperati, ad esempio testo, descrizione del layout, immagini, video, script e altro.

- -

A Web document is the composition of different resources

- -

Client e server comunicano scambiando messaggi individuali (al contrario di un flusso di dati). I messaggi inviati dal client, solitamente un browser Web, sono chiamati richieste (requests) e i messaggi inviati dal server come risposta sono chiamati risposte (responses).

- -

HTTP as an application layer protocol, on top of TCP (transport layer) and IP (network layer) and below the presentation layer.Progettato all'inizio degli anni '90 (1990), HTTP è un protocollo estensibile che si è evoluto nel tempo. È un protocollo a livello di applicazione che viene inviato mediante {{Glossary("TCP")}}, o mediante una connessione TCP cifrata {{Glossary("TLS")}}, anche se teoricamente potrebbe essere utilizzato qualsiasi protocollo di trasporto affidabile. Grazie alla sua estensibilità, viene utilizzato non solo per recuperare documenti ipertestuali, ma anche immagini e video o per pubblicare contenuti su server, come con i risultati dei moduli HTML. HTTP può essere utilizzato anche per recuperare parti di documenti per aggiornare pagine Web su richiesta.

- -

Componenti di sistemi basati su HTTP

- -

HTTP è un protocollo client-server: le richieste vengono inviate da un'entità, lo user-agent (o un proxy per conto di esso). Il più delle volte lo user-agent è un browser Web, ma può essere qualsiasi cosa, ad esempio un robot che esegue la scansione del Web per popolare e mantenere un indice del motore di ricerca.

- -

Ogni singola richiesta viene inviata a un server, che la gestisce e fornisce una risposta, chiamata response. Tra il client e il server ci sono numerose entità, chiamate collettivamente {{Glossary("Proxy_server", "proxies")}}, che eseguono operazioni diverse e fungono da gateway o {{Glossary("Cache", "caches")}}, per esempio.

- -

Client server chain

- -

In realtà, ci sono più computer tra un browser e il server che gestisce la richiesta: ci sono router, modem e altro. Grazie alla struttura a strati del Web, questi sono nascosti nella rete e nei livelli di trasporto. L'HTTP è in cima, a livello applicazione. Sebbene importanti per diagnosticare i problemi di rete, i livelli sottostanti sono per lo più irrilevanti per la descrizione di HTTP.

- -

Client: lo user-agent

- -

Lo user-agent è qualsiasi strumento che agisce per conto dell'utente. Questo ruolo viene svolto principalmente dal browser Web; altre possibilità sono i programmi utilizzati da ingegneri e sviluppatori Web per eseguire il debug delle loro applicazioni.

- -

Il browser è sempre l'entità che avvia la richiesta. Non è mai il server (sebbene nel corso degli anni siano stati aggiunti alcuni meccanismi per simulare i messaggi avviati dal server).

- -

Per presentare una pagina Web, il browser invia una richiesta iniziale per recuperare il documento HTML che rappresenta la pagina. Quindi analizza questo file, effettuando richieste aggiuntive corrispondenti a script di esecuzione, informazioni sul layout (CSS) da visualizzare e sotto-risorse contenute all'interno della pagina (solitamente immagini e video). Il browser Web quindi compone queste risorse per presentare all'utente un documento completo, la pagina Web. Gli script eseguiti dal browser possono recuperare più risorse nelle fasi successive e il browser aggiorna la pagina Web di conseguenza.

- -

Una pagina Web è un documento ipertestuale. Ciò significa che alcune parti del testo visualizzato sono collegamenti che possono essere attivati (di solito con un clic del mouse) per recuperare una nuova pagina Web, consentendo all'utente di dirigere il proprio user-agent e navigare nel Web. Il browser traduce queste indicazioni in richieste HTTP e interpreta ulteriormente le risposte HTTP per presentare all'utente una risposta chiara.

- -

Il Web server

- -

Sul lato opposto del canale di comunicazione, è il server, che serve (restituisce) il documento come richiesto dal client. Un server appare virtualmente come un'unica macchina: questo perché potrebbe essere un insieme di server, i quali condividono il carico (bilanciamento del carico) o un complesso software che interroga altri computer (come una cache, un DB server o un e-commerce server), generando totalmente o parzialmente il documento su richiesta.

- -

Un server non è necessariamente una singola macchina, ma più istanze di software server possono essere ospitate sulla stessa macchina. Con HTTP / 1.1 e l'intestazione {{HTTPHeader ("Host")}}, possono persino condividere lo stesso indirizzo IP. HERE!!!

- -

Proxies

- -

Between the Web browser and the server, numerous computers and machines relay the HTTP messages. Due to the layered structure of the Web stack, most of these operate at the transport, network or physical levels, becoming transparent at the HTTP layer and potentially making a significant impact on performance. Those operating at the application layers are generally called proxies. These can be transparent, forwarding on the requests they receive without altering them in any way, or non-transparent, in which case they will change the request in some way before passing it along to the server. Proxies may perform numerous functions:

- - - -

Basic aspects of HTTP

- -

HTTP is simple

- -

HTTP is generally designed to be simple and human readable, even with the added complexity introduced in HTTP/2 by encapsulating HTTP messages into frames. HTTP messages can be read and understood by humans, providing easier testing for developers, and reduced complexity for newcomers.

- -

HTTP is extensible

- -

Introduced in HTTP/1.0, HTTP headers make this protocol easy to extend and experiment with. New functionality can even be introduced by a simple agreement between a client and a server about a new header's semantics.

- -

HTTP is stateless, but not sessionless

- -

HTTP is stateless: there is no link between two requests being successively carried out on the same connection. This immediately has the prospect of being problematic for users attempting to interact with certain pages coherently, for example, using e-commerce shopping baskets. But while the core of HTTP itself is stateless, HTTP cookies allow the use of stateful sessions. Using header extensibility, HTTP Cookies are added to the workflow, allowing session creation on each HTTP request to share the same context, or the same state.

- -

HTTP and connections

- -

A connection is controlled at the transport layer, and therefore fundamentally out of scope for HTTP. Though HTTP doesn't require the underlying transport protocol to be connection-based; only requiring it to be reliable, or not lose messages (so at minimum presenting an error). Among the two most common transport protocols on the Internet, TCP is reliable and UDP isn't. HTTP therefore relies on the TCP standard, which is connection-based.

- -

Before a client and server can exchange an HTTP request/response pair, they must establish a TCP connection, a process which requires several round-trips. The default behavior of HTTP/1.0 is to open a separate TCP connection for each HTTP request/response pair. This is less efficient than sharing a single TCP connection when multiple requests are sent in close succession.

- -

In order to mitigate this flaw, HTTP/1.1 introduced pipelining (which proved difficult to implement) and persistent connections: the underlying TCP connection can be partially controlled using the {{HTTPHeader("Connection")}} header. HTTP/2 went a step further by multiplexing messages over a single connection, helping keep the connection warm and more efficient.

- -

Experiments are in progress to design a better transport protocol more suited to HTTP. For example, Google is experimenting with QUIC which builds on UDP to provide a more reliable and efficient transport protocol.

- -

What can be controlled by HTTP

- -

This extensible nature of HTTP has, over time, allowed for more control and functionality of the Web. Cache or authentication methods were functions handled early in HTTP history. The ability to relax the origin constraint, by contrast, has only been added in the 2010s.

- -

Here is a list of common features controllable with HTTP.

- - - -

HTTP flow

- -

When a client wants to communicate with a server, either the final server or an intermediate proxy, it performs the following steps:

- -
    -
  1. Open a TCP connection: The TCP connection is used to send a request, or several, and receive an answer. The client may open a new connection, reuse an existing connection, or open several TCP connections to the servers.
    2. -
  2. Send an HTTP message: HTTP messages (before HTTP/2) are human-readable. With HTTP/2, these simple messages are encapsulated in frames, making them impossible to read directly, but the principle remains the same. For example: - 
    GET / HTTP/1.1
-Host: developer.mozilla.org
-Accept-Language: fr
    -
    3. -
  3. Read the response sent by the server, such as: - 
    HTTP/1.1 200 OK
-Date: Sat, 09 Oct 2010 14:28:02 GMT
-Server: Apache
-Last-Modified: Tue, 01 Dec 2009 20:18:22 GMT
-ETag: "51142bc1-7449-479b075b2891b"
-Accept-Ranges: bytes
-Content-Length: 29769
-Content-Type: text/html
-
-<!DOCTYPE html... (here comes the 29769 bytes of the requested web page)
    -
    4. -
  4. Close or reuse the connection for further requests.
    5. -
- -

If HTTP pipelining is activated, several requests can be sent without waiting for the first response to be fully received. HTTP pipelining has proven difficult to implement in existing networks, where old pieces of software coexist with modern versions. HTTP pipelining has been superseded in HTTP/2 with more robust multiplexing requests within a frame.

- -

HTTP Messages

- -

HTTP messages, as defined in HTTP/1.1 and earlier, are human-readable. In HTTP/2, these messages are embedded into a binary structure, a frame, allowing optimizations like compression of headers and multiplexing. Even if only part of the original HTTP message is sent in this version of HTTP, the semantics of each message is unchanged and the client reconstitutes (virtually) the original HTTP/1.1 request. It is therefore useful to comprehend HTTP/2 messages in the HTTP/1.1 format.

- -

There are two types of HTTP messages, requests and responses, each with its own format.

- -

Requests

- -

An example HTTP request:

- -

A basic HTTP request

- -

Requests consists of the following elements:

- - - -

Responses

- -

An example response:

- -

- -

Responses consist of the following elements:

- - - -

APIs based on HTTP

- -

The most commonly used API based on HTTP is the {{domxref("XMLHttpRequest")}} API, which can be used to exchange data between a {{Glossary("user agent")}} and a server. The modern {{domxref("Fetch API")}} provides the same features with a more powerful and flexible feature set.

- -

Another API, server-sent events, is a one-way service that allows a server to send events to the client, using HTTP as a transport mechanism. Using the {{domxref("EventSource")}} interface, the client opens a connection and establishes event handlers. The client browser automatically converts the messages that arrive on the HTTP stream into appropriate {{domxref("Event")}} objects, delivering them to the event handlers that have been registered for the events' {{domxref("Event.type", "type")}} if known, or to the {{domxref("EventSource.onmessage", "onmessage")}} event handler if no type-specific event handler was established.

- -

Conclusion

- -

HTTP è un protocollo estensibile che è facile da usare. The client-server structure, combined with the ability to simply add headers, allows HTTP to advance along with the extended capabilities of the Web.

- -

Though HTTP/2 adds some complexity, by embedding HTTP messages in frames to improve performance, the basic structure of messages has stayed the same since HTTP/1.0. Session flow remains simple, allowing it to be investigated, and debugged with a simple HTTP message monitor.

diff --git a/files/it/web/http/range_requests/index.html b/files/it/web/http/range_requests/index.html new file mode 100644 index 0000000000..e6bbe43d19 --- /dev/null +++ b/files/it/web/http/range_requests/index.html @@ -0,0 +1,115 @@ +--- +title: Richieste HTTP range +slug: Web/HTTP/Richieste_range +translation_of: Web/HTTP/Range_requests +--- +
{{HTTPSidebar}}
+ +

Le richieste HTTP range permettono di mandare una sola porzione di un messaggio HTTP da un server a un client invece del messaggio intero. Le richieste parziali sono utili per file di grandi dimensioni o per mettere un download in pausa e riprenderlo successivamente.

+ +

Controllare se un server supporta richieste parziali

+ +

Se l'header {{HTTPHeader("Accept-Ranges")}} è presente nelle risposte HTTP (e il suo valore non è "none"), il server supporta richieste HTTP range. E' possibile controllarlo creando una richiesta {{HTTPMethod("HEAD")}} con cURL, ad esempio.

+ +
curl -I http://i.imgur.com/z4d4kWk.jpg
+
+HTTP/1.1 200 OK
+...
+Accept-Ranges: bytes
+Content-Length: 146515
+
+ +

In questa risposta, Accept-Ranges: bytes indica che i bytes possono essere usati come unità base per definire un range (intervallo). Qui anche l'header {{HTTPHeader("Content-Length")}} è utile perché indica la dimensione dell'intero file contenente l'immagine.

+ +

Se il sito omette l'header Accept-Ranges, probabilmente non supporta richieste parziali. Alcuni siti mandano esplicitamente "none" come valore, indicando che non supportano la funzionalità. In questo caso, i download managers di alcune app disabiliteranno i loro pulsanti di pausa.

+ +
curl -I https://www.youtube.com/watch?v=EwTZ2xpQwpA
+
+HTTP/1.1 200 OK
+...
+Accept-Ranges: none
+
+ +

Richiedere un range specifico

+ +

Se il server supporta richieste range, è possibile effettuare questa richiesta tramite l'header {{HTTPHeader("Range")}}, che indica la parte o le parti di un documento con le quali il server dovrà rispondere.

+ +

Range formato da una singola parte

+ +

Possiamo richiedere un singolo range da una risorsa. Possiamo fare una richiesta di prova tramite cURL. L'opzione "-H" appenderà una riga all'header alla richiesta, in questo caso l'header Range che richiede i primi 1024 bytes.

+ +
curl http://i.imgur.com/z4d4kWk.jpg -i -H "Range: bytes=0-1023"
+ +

La richiesta effettuata è la seguente:

+ +
GET /z4d4kWk.jpg HTTP/1.1
+Host: i.imgur.com
+Range: bytes=0-1023
+ +

Il server risponde con lo stato {{HTTPStatus("206")}} Partial Content:

+ +
HTTP/1.1 206 Partial Content
+Content-Range: bytes 0-1023/146515
+Content-Length: 1024
+...
+(binary content)
+
+ +

L'header {{HTTPHeader("Content-Length")}} ora indica la dimensione dell'intervallo richiesto (non la dimensione totale dell'immagine). L'header {{HTTPHeader("Content-Range")}} nella risposta indica la posizione del messaggio parziale all'interno del file.

+ +

Range formato da più parti

+ +

L'header {{HTTPHeader("Range")}} permette anche di ottenere più di un intervallo alla volta. Gli intervalli sono separati da una virgola.

+ +
curl http://www.example.com -i -H "Range: bytes=0-50, 100-150"
+ +

Il server risponde con lo stato {{HTTPStatus("206")}} Partial Content e l'header {{HTTPHeader("Content-Type")}}: multipart/byteranges; boundary=3d6b6a416f9b5, indicando che un range multiparte segue. Ogni parte contiene il proprio campo Content-Type and Content-Range.

+ +
HTTP/1.1 206 Partial Content
+Content-Type: multipart/byteranges; boundary=3d6b6a416f9b5
+Content-Length: 282
+
+--3d6b6a416f9b5
+Content-Type: text/html
+Content-Range: bytes 0-50/1270
+
+<!doctype html>
+<html>
+<head>
+    <title>Example Do
+--3d6b6a416f9b5
+Content-Type: text/html
+Content-Range: bytes 100-150/1270
+
+eta http-equiv="Content-type" content="text/html; c
+--3d6b6a416f9b5--
+ +

Richieste di range condizionali

+ +

Quando la richiesta è in pausa e viene successivamente ripresa, è necessario garantire che la risorsa remota non sia stata modificata da quando l'ultimo frammento è stato ricevuto.

+ +

L'header della richiesta HTTP {{HTTPHeader("If-Range")}} rende una richiesta range condizionale: se la condizione è verificata, la richiesta verrà effettuata e il server restituirà lo stato {{HTTPStatus("206")}} Partial Content con il corpo appropriato. Se la condizione non è verificata, il server restituirà l'intera risorsa con status {{HTTPStatus("200")}} OK. Questo header può essere usato in combinazione con un validatore {{HTTPHeader("Last-Modified")}} oppure un {{HTTPHeader("ETag")}}, ma non entrambi.

+ +
If-Range: Wed, 21 Oct 2015 07:28:00 GMT
+ +

Risposte alle richieste parziali

+ +

Quando si lavora con richieste range, esistono tre stati rilevanti:

+ + + +

Confronto con Transfer-Encoding frammentato

+ +

L'header {{HTTPHeader("Transfer-Encoding")}} permette la codifica a frammenti, che è utile quando grandi quantità di dati sono mandati al client e la dimensione totale della risposta non è conosciuta fino a quando la richiesta è stata processata. Il server manda dati al client immediatamente senza fare buffering della risposta o determinare la lunghezza esatta, migliorando la latenza. Richieste range e chunking sono compatibili e possono essere usate contemporaneamente.

+ +

Vedi anche

+ + diff --git a/files/it/web/http/richieste_range/index.html b/files/it/web/http/richieste_range/index.html deleted file mode 100644 index e6bbe43d19..0000000000 --- a/files/it/web/http/richieste_range/index.html +++ /dev/null @@ -1,115 +0,0 @@ ---- -title: Richieste HTTP range -slug: Web/HTTP/Richieste_range -translation_of: Web/HTTP/Range_requests ---- -
{{HTTPSidebar}}
- -

Le richieste HTTP range permettono di mandare una sola porzione di un messaggio HTTP da un server a un client invece del messaggio intero. Le richieste parziali sono utili per file di grandi dimensioni o per mettere un download in pausa e riprenderlo successivamente.

- -

Controllare se un server supporta richieste parziali

- -

Se l'header {{HTTPHeader("Accept-Ranges")}} è presente nelle risposte HTTP (e il suo valore non è "none"), il server supporta richieste HTTP range. E' possibile controllarlo creando una richiesta {{HTTPMethod("HEAD")}} con cURL, ad esempio.

- -
curl -I http://i.imgur.com/z4d4kWk.jpg
-
-HTTP/1.1 200 OK
-...
-Accept-Ranges: bytes
-Content-Length: 146515
-
- -

In questa risposta, Accept-Ranges: bytes indica che i bytes possono essere usati come unità base per definire un range (intervallo). Qui anche l'header {{HTTPHeader("Content-Length")}} è utile perché indica la dimensione dell'intero file contenente l'immagine.

- -

Se il sito omette l'header Accept-Ranges, probabilmente non supporta richieste parziali. Alcuni siti mandano esplicitamente "none" come valore, indicando che non supportano la funzionalità. In questo caso, i download managers di alcune app disabiliteranno i loro pulsanti di pausa.

- -
curl -I https://www.youtube.com/watch?v=EwTZ2xpQwpA
-
-HTTP/1.1 200 OK
-...
-Accept-Ranges: none
-
- -

Richiedere un range specifico

- -

Se il server supporta richieste range, è possibile effettuare questa richiesta tramite l'header {{HTTPHeader("Range")}}, che indica la parte o le parti di un documento con le quali il server dovrà rispondere.

- -

Range formato da una singola parte

- -

Possiamo richiedere un singolo range da una risorsa. Possiamo fare una richiesta di prova tramite cURL. L'opzione "-H" appenderà una riga all'header alla richiesta, in questo caso l'header Range che richiede i primi 1024 bytes.

- -
curl http://i.imgur.com/z4d4kWk.jpg -i -H "Range: bytes=0-1023"
- -

La richiesta effettuata è la seguente:

- -
GET /z4d4kWk.jpg HTTP/1.1
-Host: i.imgur.com
-Range: bytes=0-1023
- -

Il server risponde con lo stato {{HTTPStatus("206")}} Partial Content:

- -
HTTP/1.1 206 Partial Content
-Content-Range: bytes 0-1023/146515
-Content-Length: 1024
-...
-(binary content)
-
- -

L'header {{HTTPHeader("Content-Length")}} ora indica la dimensione dell'intervallo richiesto (non la dimensione totale dell'immagine). L'header {{HTTPHeader("Content-Range")}} nella risposta indica la posizione del messaggio parziale all'interno del file.

- -

Range formato da più parti

- -

L'header {{HTTPHeader("Range")}} permette anche di ottenere più di un intervallo alla volta. Gli intervalli sono separati da una virgola.

- -
curl http://www.example.com -i -H "Range: bytes=0-50, 100-150"
- -

Il server risponde con lo stato {{HTTPStatus("206")}} Partial Content e l'header {{HTTPHeader("Content-Type")}}: multipart/byteranges; boundary=3d6b6a416f9b5, indicando che un range multiparte segue. Ogni parte contiene il proprio campo Content-Type and Content-Range.

- -
HTTP/1.1 206 Partial Content
-Content-Type: multipart/byteranges; boundary=3d6b6a416f9b5
-Content-Length: 282
-
---3d6b6a416f9b5
-Content-Type: text/html
-Content-Range: bytes 0-50/1270
-
-<!doctype html>
-<html>
-<head>
-    <title>Example Do
---3d6b6a416f9b5
-Content-Type: text/html
-Content-Range: bytes 100-150/1270
-
-eta http-equiv="Content-type" content="text/html; c
---3d6b6a416f9b5--
- -

Richieste di range condizionali

- -

Quando la richiesta è in pausa e viene successivamente ripresa, è necessario garantire che la risorsa remota non sia stata modificata da quando l'ultimo frammento è stato ricevuto.

- -

L'header della richiesta HTTP {{HTTPHeader("If-Range")}} rende una richiesta range condizionale: se la condizione è verificata, la richiesta verrà effettuata e il server restituirà lo stato {{HTTPStatus("206")}} Partial Content con il corpo appropriato. Se la condizione non è verificata, il server restituirà l'intera risorsa con status {{HTTPStatus("200")}} OK. Questo header può essere usato in combinazione con un validatore {{HTTPHeader("Last-Modified")}} oppure un {{HTTPHeader("ETag")}}, ma non entrambi.

- -
If-Range: Wed, 21 Oct 2015 07:28:00 GMT
- -

Risposte alle richieste parziali

- -

Quando si lavora con richieste range, esistono tre stati rilevanti:

- - - -

Confronto con Transfer-Encoding frammentato

- -

L'header {{HTTPHeader("Transfer-Encoding")}} permette la codifica a frammenti, che è utile quando grandi quantità di dati sono mandati al client e la dimensione totale della risposta non è conosciuta fino a quando la richiesta è stata processata. Il server manda dati al client immediatamente senza fare buffering della risposta o determinare la lunghezza esatta, migliorando la latenza. Richieste range e chunking sono compatibili e possono essere usate contemporaneamente.

- -

Vedi anche

- - diff --git a/files/it/web/http/session/index.html b/files/it/web/http/session/index.html new file mode 100644 index 0000000000..e414eb9d19 --- /dev/null +++ b/files/it/web/http/session/index.html @@ -0,0 +1,171 @@ +--- +title: Una tipica sessione HTTP +slug: Web/HTTP/Sessione +translation_of: Web/HTTP/Session +--- +
{{HTTPSidebar}}
+ +

Nei protocolli client-server come l’HTTP, la sessione è composta da tre fasi:

+ +
    +
  1. Il cliente stabilisce una connessione TCP (o l’appropriata connessione nel caso non sia TCP).
    2. +
  2. Il cliente manda la sua richiesta e aspetta per la risposta.
    3. +
  3. Il server processa la richiesta, mandando poi la sua risposta, con al suo interno il codice di stato e un dato appropriato.
    4. +
+ +

Da quando è uscito HTTP/1.1, la connessione non si chiude più dopo la terza fase, e il cliente può fare un altra richiesta: questo significa che la seconda e terza fase possono essere usate molte volte.

+ +

Stabilire una connessione

+ +

Nei protocolli client-server è il client che stabilisce la connessione. Aprire una connessione in HTTP significa avviare una connessione nel livello di trasporto sottostante, che di solito è il TCP.

+ +

Con TCP la porta di default, per un server HTTP su un computer, è la porta 80. Possono essere usate anche altre porte, come la 8000 o la 8080. L’URL della pagina da raggiungere contiene sia il nome del dominio che la numero di porta, anche se quest’ultimo può essere omesso se è 80. Vedi identificare le risorse sul web per maggiori dettagli.

+ +
Nota: Il modello client-server non permette al server di inviare dati al client senza una specifica richiesta da parte di esso. Per aggirare questo problema, gli sviluppatori web usano varie tecniche: pingare il server periodicamente con XMLHTTPRequest, Fetch APIs, usando il WebSockets API, o protocolli simili.
+ +

Mandare una client request

+ +

Una volta che la connessione si è stabilita, il programma utente può mandare la richiesta (un programma utente è tipicamente un web browser, ma può essere tante cose, per esempio un motore di ricerca). Una client request consiste nelle direttive testuali, separate dal CRLF (carriage return line feed), divise in 3 blocchi:

+ +
    +
  1. La prima riga contiene un request method seguito dai suoi parametri: +
      +
    • il percorso di un documento, quindi l’URL assoluto senza protocollo o dominio.
      • +
    • Versione del protocollo HTTP.
      • +
    +
    2. +
  2. righe susseguenti rappresentano un header HTTP, che danno al server le informazioni su quale tipo di dato è più appropriato (ad esempio  che liguaggio o tipo di MIME) o altri dati che alterano il suo comportamento (ad esempio non mandare una risposta anche se già   memorizzata nella cache). Gli header HTTP formano un blocco che termina con una riga vuota.
    3. +
  3. L’ultimo blocco è facoltativo, e contiene dati superflui usati principalmente dal POST method.
    4. +
+ +

Esempi:

+ +

recuperare la pagina radice di developer.mozilla.org , e dire al server che il programma utente preferirebbe, se possibile, avere la pagina in lingua francese.

+ +
GET / HTTP/1.1
+Host: developer.mozilla.org
+Accept-Language: fr
+
+ +

Si osservi che l’ultima riga è vuota, questo separa il blocco data da quello header. Dato che non c’è nessuna content-lenght nell’ header HTTP, questo blocco di dati si presenta vuoto, marcando la fine degli headers, permettendo così al server di processare la richiesta dal momento in cui riceve quella riga vuota.

+ +

Per esempio, mandando il risultato di un form:

+ +
POST /contact_form.php HTTP/1.1
+Host: developer.mozilla.org
+Content-Length: 64
+Content-Type: application/x-www-form-urlencoded
+
+name=Joe%20User&request=Send%20me%20one%20of%20your%20catalogue
+
+ +

Metodi di richiesta

+ +

L’HTTP definisce un set di richieste metodo che indicano l’azione desiderata da fare a seconda della risorsa. Anche se possono essere nomi, queste richieste sono alcune volte riferite come dei verbi HTTP. La richieste più comuni sono GET e POST:

+ + + +

Struttura di una risposta server

+ +

Dopo che l’agente connesso ha inviato la richiesta, il web server lo processa, e alla fine restituisce una risposta. Analogamente alla richiesta client, una risposta server è formata da direttive, separate dal CRLF, sebbene divise in tre blocchi:

+ +
    +
  1. La prima linea, lastatus line, consiste in un riconoscimento della versione http usata, seguita da un status request (e il suo breve significato in parole comprensibili dall’uomo).
    2. +
  2. Le righe successive rappresentano specifici header HTTP, che danno al client informazioni riguardanti i dati inviati (per esempio: tipo, dimensione dei dati, algoritmo di compressione usato, note sul caching). Analogamente al blocco di header HTTP di una richiesta client, questi header HTTP formano un blocco finale con una linea vuota.
    3. +
  3. Il blocco finale è un blocco di dati, che contieni i dati opzionali.
    4. +
+ +

Esempio di risposte

+ +

Risposta pagina web riuscita:

+ +
HTTP/1.1 200 OK
+Content-Type: text/html; charset=utf-8
+Content-Length: 55743
+Connection: keep-alive
+Cache-Control: s-maxage=300, public, max-age=0
+Content-Language: en-US
+Date: Thu, 06 Dec 2018 17:37:18 GMT
+ETag: "2e77ad1dc6ab0b53a2996dfd4653c1c3"
+Server: meinheld/0.6.1
+Strict-Transport-Security: max-age=63072000
+X-Content-Type-Options: nosniff
+X-Frame-Options: DENY
+X-XSS-Protection: 1; mode=block
+Vary: Accept-Encoding,Cookie
+Age: 7
+
+
+<!DOCTYPE html>
+<html lang="en">
+<head>
+  <meta charset="utf-8">
+  <title>A simple webpage</title>
+</head>
+<body>
+  <h1>Simple HTML5 webpage</h1>
+  <p>Hello, world!</p>
+</body>
+</html>
+
+ +

Notifica che la risorsa richiesta è stata definitivamente trasferita:

+ +
HTTP/1.1 301 Moved Permanently
+Server: Apache/2.4.37 (Red Hat)
+Content-Type: text/html; charset=utf-8
+Date: Thu, 06 Dec 2018 17:33:08 GMT
+Location: https://developer.mozilla.org/ (questo è il nuovo link della risorsa; ci si aspetta che l’utente agente lo prenda)
+Keep-Alive: timeout=15, max=98
+Accept-Ranges: bytes
+Via: Moz-Cache-zlb05
+Connection: Keep-Alive
+Content-Length: 325 (Il contenuto è una pagina di default da mostrare se l’utente agente non è in grado di seguire il link)
+
+
+<!DOCTYPE html... (contiene un pagina personalizzata che aiuta l’utente a trovare la risorsa mancante)
+
+ +

Notifica che la risorsa richiesta non esiste:

+ +
HTTP/1.1 404 Not Found
+Content-Type: text/html; charset=utf-8
+Content-Length: 38217
+Connection: keep-alive
+Cache-Control: no-cache, no-store, must-revalidate, max-age=0
+Content-Language: en-US
+Date: Thu, 06 Dec 2018 17:35:13 GMT
+Expires: Thu, 06 Dec 2018 17:35:13 GMT
+Server: meinheld/0.6.1
+Strict-Transport-Security: max-age=63072000
+X-Content-Type-Options: nosniff
+X-Frame-Options: DENY
+X-XSS-Protection: 1; mode=block
+Vary: Accept-Encoding,Cookie
+X-Cache: Error from cloudfront
+
+
+<!DOCTYPE html... (contiene un pagina personalizzata che aiuta l’utente a trovare la risorsa mancante)
+
+ +

Status code di risposta

+ +

HTTP response status codes indica se una specifica richiesta HTTP sia stata completata con successo. Le risposte sono suddivise in cinque classi: risposte informative, risposte di successo, reindirizzamenti, errori client, ed errori server.

+ + + +

Vedi anche

+ + diff --git a/files/it/web/http/sessione/index.html b/files/it/web/http/sessione/index.html deleted file mode 100644 index e414eb9d19..0000000000 --- a/files/it/web/http/sessione/index.html +++ /dev/null @@ -1,171 +0,0 @@ ---- -title: Una tipica sessione HTTP -slug: Web/HTTP/Sessione -translation_of: Web/HTTP/Session ---- -
{{HTTPSidebar}}
- -

Nei protocolli client-server come l’HTTP, la sessione è composta da tre fasi:

- -
    -
  1. Il cliente stabilisce una connessione TCP (o l’appropriata connessione nel caso non sia TCP).
    2. -
  2. Il cliente manda la sua richiesta e aspetta per la risposta.
    3. -
  3. Il server processa la richiesta, mandando poi la sua risposta, con al suo interno il codice di stato e un dato appropriato.
    4. -
- -

Da quando è uscito HTTP/1.1, la connessione non si chiude più dopo la terza fase, e il cliente può fare un altra richiesta: questo significa che la seconda e terza fase possono essere usate molte volte.

- -

Stabilire una connessione

- -

Nei protocolli client-server è il client che stabilisce la connessione. Aprire una connessione in HTTP significa avviare una connessione nel livello di trasporto sottostante, che di solito è il TCP.

- -

Con TCP la porta di default, per un server HTTP su un computer, è la porta 80. Possono essere usate anche altre porte, come la 8000 o la 8080. L’URL della pagina da raggiungere contiene sia il nome del dominio che la numero di porta, anche se quest’ultimo può essere omesso se è 80. Vedi identificare le risorse sul web per maggiori dettagli.

- -
Nota: Il modello client-server non permette al server di inviare dati al client senza una specifica richiesta da parte di esso. Per aggirare questo problema, gli sviluppatori web usano varie tecniche: pingare il server periodicamente con XMLHTTPRequest, Fetch APIs, usando il WebSockets API, o protocolli simili.
- -

Mandare una client request

- -

Una volta che la connessione si è stabilita, il programma utente può mandare la richiesta (un programma utente è tipicamente un web browser, ma può essere tante cose, per esempio un motore di ricerca). Una client request consiste nelle direttive testuali, separate dal CRLF (carriage return line feed), divise in 3 blocchi:

- -
    -
  1. La prima riga contiene un request method seguito dai suoi parametri: -
      -
    • il percorso di un documento, quindi l’URL assoluto senza protocollo o dominio.
      • -
    • Versione del protocollo HTTP.
      • -
    -
    2. -
  2. righe susseguenti rappresentano un header HTTP, che danno al server le informazioni su quale tipo di dato è più appropriato (ad esempio  che liguaggio o tipo di MIME) o altri dati che alterano il suo comportamento (ad esempio non mandare una risposta anche se già   memorizzata nella cache). Gli header HTTP formano un blocco che termina con una riga vuota.
    3. -
  3. L’ultimo blocco è facoltativo, e contiene dati superflui usati principalmente dal POST method.
    4. -
- -

Esempi:

- -

recuperare la pagina radice di developer.mozilla.org , e dire al server che il programma utente preferirebbe, se possibile, avere la pagina in lingua francese.

- -
GET / HTTP/1.1
-Host: developer.mozilla.org
-Accept-Language: fr
-
- -

Si osservi che l’ultima riga è vuota, questo separa il blocco data da quello header. Dato che non c’è nessuna content-lenght nell’ header HTTP, questo blocco di dati si presenta vuoto, marcando la fine degli headers, permettendo così al server di processare la richiesta dal momento in cui riceve quella riga vuota.

- -

Per esempio, mandando il risultato di un form:

- -
POST /contact_form.php HTTP/1.1
-Host: developer.mozilla.org
-Content-Length: 64
-Content-Type: application/x-www-form-urlencoded
-
-name=Joe%20User&request=Send%20me%20one%20of%20your%20catalogue
-
- -

Metodi di richiesta

- -

L’HTTP definisce un set di richieste metodo che indicano l’azione desiderata da fare a seconda della risorsa. Anche se possono essere nomi, queste richieste sono alcune volte riferite come dei verbi HTTP. La richieste più comuni sono GET e POST:

- - - -

Struttura di una risposta server

- -

Dopo che l’agente connesso ha inviato la richiesta, il web server lo processa, e alla fine restituisce una risposta. Analogamente alla richiesta client, una risposta server è formata da direttive, separate dal CRLF, sebbene divise in tre blocchi:

- -
    -
  1. La prima linea, lastatus line, consiste in un riconoscimento della versione http usata, seguita da un status request (e il suo breve significato in parole comprensibili dall’uomo).
    2. -
  2. Le righe successive rappresentano specifici header HTTP, che danno al client informazioni riguardanti i dati inviati (per esempio: tipo, dimensione dei dati, algoritmo di compressione usato, note sul caching). Analogamente al blocco di header HTTP di una richiesta client, questi header HTTP formano un blocco finale con una linea vuota.
    3. -
  3. Il blocco finale è un blocco di dati, che contieni i dati opzionali.
    4. -
- -

Esempio di risposte

- -

Risposta pagina web riuscita:

- -
HTTP/1.1 200 OK
-Content-Type: text/html; charset=utf-8
-Content-Length: 55743
-Connection: keep-alive
-Cache-Control: s-maxage=300, public, max-age=0
-Content-Language: en-US
-Date: Thu, 06 Dec 2018 17:37:18 GMT
-ETag: "2e77ad1dc6ab0b53a2996dfd4653c1c3"
-Server: meinheld/0.6.1
-Strict-Transport-Security: max-age=63072000
-X-Content-Type-Options: nosniff
-X-Frame-Options: DENY
-X-XSS-Protection: 1; mode=block
-Vary: Accept-Encoding,Cookie
-Age: 7
-
-
-<!DOCTYPE html>
-<html lang="en">
-<head>
-  <meta charset="utf-8">
-  <title>A simple webpage</title>
-</head>
-<body>
-  <h1>Simple HTML5 webpage</h1>
-  <p>Hello, world!</p>
-</body>
-</html>
-
- -

Notifica che la risorsa richiesta è stata definitivamente trasferita:

- -
HTTP/1.1 301 Moved Permanently
-Server: Apache/2.4.37 (Red Hat)
-Content-Type: text/html; charset=utf-8
-Date: Thu, 06 Dec 2018 17:33:08 GMT
-Location: https://developer.mozilla.org/ (questo è il nuovo link della risorsa; ci si aspetta che l’utente agente lo prenda)
-Keep-Alive: timeout=15, max=98
-Accept-Ranges: bytes
-Via: Moz-Cache-zlb05
-Connection: Keep-Alive
-Content-Length: 325 (Il contenuto è una pagina di default da mostrare se l’utente agente non è in grado di seguire il link)
-
-
-<!DOCTYPE html... (contiene un pagina personalizzata che aiuta l’utente a trovare la risorsa mancante)
-
- -

Notifica che la risorsa richiesta non esiste:

- -
HTTP/1.1 404 Not Found
-Content-Type: text/html; charset=utf-8
-Content-Length: 38217
-Connection: keep-alive
-Cache-Control: no-cache, no-store, must-revalidate, max-age=0
-Content-Language: en-US
-Date: Thu, 06 Dec 2018 17:35:13 GMT
-Expires: Thu, 06 Dec 2018 17:35:13 GMT
-Server: meinheld/0.6.1
-Strict-Transport-Security: max-age=63072000
-X-Content-Type-Options: nosniff
-X-Frame-Options: DENY
-X-XSS-Protection: 1; mode=block
-Vary: Accept-Encoding,Cookie
-X-Cache: Error from cloudfront
-
-
-<!DOCTYPE html... (contiene un pagina personalizzata che aiuta l’utente a trovare la risorsa mancante)
-
- -

Status code di risposta

- -

HTTP response status codes indica se una specifica richiesta HTTP sia stata completata con successo. Le risposte sono suddivise in cinque classi: risposte informative, risposte di successo, reindirizzamenti, errori client, ed errori server.

- - - -

Vedi anche

- - -- cgit v1.2.3-54-g00ecf