Network: richiesta, payload, risposta

In parole semplici

Tra il tuo codice e il server c’è una linea: la rete. Quando qualcosa non funziona, il pannello Network del browser ti permette di guardare ogni richiesta nei dettagli e capire dove si rompe il flusso: nel codice client, nella richiesta inviata, nella risposta del server o nel decodificarla.

Parole nuove

• request (richiesta): messaggio che il client invia al server.
• response (risposta): messaggio che il server rinvia al client.
• payload: corpo del messaggio (request body, response body).
• header: meta-informazioni del messaggio (Content-Type, Authorization).
• preflight: richiesta OPTIONS automatica per controllare permessi CORS.
• throttling: simulazione di una connessione lenta.

Cosa impari

• Aprire e leggere il pannello Network.
• Distinguere bug nel client (non ho mai mandato) da bug nella request (ho mandato male), nella response (ho ricevuto male) e nel parsing (ho letto male).
• Replicare una richiesta (replay) con e senza modifiche.
• Usare throttling per riprodurre bug “solo con rete lenta”.

Le quattro stazioni

Una richiesta passa per quattro punti dove può rompersi:

[1. CLIENT] → [2. REQUEST] → [3. SERVER/RESPONSE] → [4. PARSING CLIENT]

1. CLIENT: il codice client costruisce la chiamata. Se sbaglia URL, header, body, il bug è qui.
2. REQUEST: la chiamata parte e attraversa la rete (e i gateway). Se non parte o non arriva, il bug è qui.
3. SERVER/RESPONSE: il server elabora e risponde. Se la risposta è sbagliata, il bug è qui.
4. PARSING CLIENT: il client legge la risposta. Se la legge male, il bug è qui.

Il pannello Network ti dice quale delle quattro stazioni è quella rotta.

Layout del pannello Network

Apri DevTools → tab Network → ricarica la pagina o esegui l’azione.

Vedi:

• Lista richieste: ogni riga è una request.
• Filtri: All / XHR-Fetch / JS / CSS / Img / Doc / WS.
• Throttling: dropdown con “No throttling”, “Fast 3G”, “Slow 3G”, “Offline”.
• Disable cache: utile durante il debug.
• Preserve log: mantieni richieste anche dopo refresh.

Per ogni richiesta:

• Headers: header inviati e ricevuti.
• Payload / Request: cosa hai mandato.
• Response / Preview: cosa hai ricevuto (preview formatta JSON).
• Timing: quanto tempo è durata ogni fase (DNS, connection, TTFB, content download).

Caso 1: la richiesta non parte (bug nel CLIENT)

In Network non vedi nessuna richiesta legata all’azione.

Cause tipiche:

• Errore JS prima del fetch (vedi Console).
• Condizione che impedisce la chiamata.
• Listener non collegato (vedi modulo 7).

Diagnosi: console, breakpoint sul punto in cui dovresti fare fetch.

Caso 2: la richiesta parte male (bug nella REQUEST)

In Network vedi la richiesta. Apri “Headers” e “Payload”:

• URL giusto? metodo giusto (GET/POST)?
• Content-Type corretto?
• Authorization presente?
• Body con i campi attesi?

Diagnosi: confronta con la documentazione o con una chiamata “buona” passata.

Caso 3: il server risponde con errore (bug SERVER)

Status 4xx o 5xx. Apri “Response”:

• 4xx → cosa hai mandato? Spesso il body contiene il motivo (modulo 2.4).
• 5xx → chiedi i log del server in quel timestamp.

Diagnosi: replicare con curl per escludere il browser.

Caso 4: il client decodifica male (bug PARSING)

Risposta 200 con dati corretti, ma l’interfaccia non li mostra.

Cause tipiche:

• Campo con nome diverso (user_name vs userName).
• Tipo diverso (stringa vs numero).
• Array vuoto inatteso.
• JSON.parse su un body non-JSON.

Diagnosi: confronta “Response Preview” con quello che il tuo codice prova a leggere.

Replay e modify

Click destro su una richiesta → “Replay XHR” (Chrome) o “Resend” (Firefox). La richiesta viene rifatta identica.

Per modificarla: “Copy as fetch” → incolla in console → modifica un parametro → esegui. Diagnosi rapida per bug specifici di un campo.

Throttling

Se il bug si vede solo con rete lenta, simula:

1. Network → dropdown → “Slow 3G”.
2. Ricarica.
3. Osserva timing e ordine.

Bug tipici: race condition (modulo 7), timeout, doppi submit.

CORS in 30 secondi

Quando il client e il server stanno su origin diversi (host, porta, protocollo), il browser fa un preflight OPTIONS per chiedere permesso.

Sintomi tipici:

• Console: Access to fetch at '...' has been blocked by CORS policy.
• Network: una richiesta OPTIONS precede la “vera” e fallisce.

Cause possibili:

• Header Access-Control-Allow-Origin mancante o sbagliato.
• Metodo non in Access-Control-Allow-Methods.
• Cookie senza credentials: "include" + Access-Control-Allow-Credentials.

Approfondimento nel modulo 8.

Esercizio guidato

1. Apri una web app reale che fai una POST.
2. Esegui l’azione: cattura la richiesta in Network.
3. Annota: URL, metodo, header Content-Type, body.
4. “Copy as cURL” → incolla in terminale → esegui. Ottieni la stessa risposta? Se no, perché?
5. Attiva “Slow 3G” e ripeti. Cosa cambia? Quante richieste partono? In che ordine?

Errori frequenti del principiante

• Guardare solo la status code. Anche con 200, la response può essere sbagliata.
• Confondere request e response. Quale dei due hai sbagliato? Il pannello li mostra entrambi.
• Ignorare gli header. Spesso il bug vive in Content-Type o Authorization.
• Pensare che “il browser sbagli”. Quasi mai. Quasi sempre è il client che chiede male.