Progettare casi di errore con un proxy di debug
Scegli modifiche HTTP, ritardi e scambi interrotti in base al comportamento del client che un test basato su proxy deve esercitare.
Un proxy di debug è utile quando un client deve incontrare una risposta che il server normale raramente produce. Definire prima il comportamento del client, poi scegliere l'intervento che produce quella condizione.
«La richiesta non è riuscita» è un caso di test troppo ampio. Una risposta di errore HTTP valida, una risposta che non arriva mai e una connessione interrotta a metà di un download chiedono cose diverse all'applicazione.
| Caso | Comportamento da esaminare |
|---|---|
| Una risposta di errore HTTP completa | Se il client legge lo stato e applica la politica di errore prevista |
| Una risposta ritardata | Se l'utente può annullare e il timeout si applica nella fase prevista |
| Un campo di intestazione o di corpo inatteso | Se l'analisi e la convalida falliscono in modo chiaro |
| Uno scambio interrotto | Se i dati incompleti restano distinguibili da un risultato concluso |
Usare un intervento al livello giusto
Charles fornisce punti di interruzione che sospendono una richiesta o una risposta prima di inoltrarla. Il messaggio intercettato può essere esaminato e modificato, lasciato passare o interrotto. Il suo strumento Rewrite applica modifiche ripetibili a intestazioni, URL o corpi corrispondenti. La limitazione controlla la larghezza di banda e la latenza aggiunta.
Questi controlli possono esercitare il comportamento di un client HTTP, ma un limite di larghezza di banda non è un modello preciso della perdita casuale di pacchetti IP. Un proxy può memorizzare i dati in un buffer, riutilizzare le connessioni e aprire una connessione upstream separata. Scegliere uno strumento di degrado della rete quando la condizione richiesta è specificamente sotto HTTP.
Mantenere ogni caso interpretabile
Far corrispondere strettamente l'host e il percorso previsti. Iniziare con uno scambio normale, abilitare una sola modifica e annotare cosa è stato cambiato. Se un nuovo tentativo raggiunge un secondo endpoint, decidere se la stessa regola debba influenzare quel tentativo. Altrimenti una riscrittura incondizionata può trasformare ogni percorso di ripristino nell'errore originale.
In un caricamento o in un'operazione simile a un pagamento, una risposta persa non dimostra che il server abbia rifiutato la richiesta. Includere tale ambiguità nel caso di nuovo tentativo invece di affermare che ogni errore di trasporto sia sicuro da ripetere.
Ispezionare o modificare contenuti HTTPS richiede che il client partecipi alla configurazione di ispezione TLS del proxy di debug. Un proxy che trasporta solo CONNECT vede byte applicativi cifrati. Usare una configurazione di test isolata e ripristinare poi il routing e le impostazioni di fiducia, così che le osservazioni successive descrivano il client normale.