IBM Cloud Docs
Risoluzione degli errori di classe 400

Risoluzione degli errori di classe 400

Le risposte con codice di errore di classe 4xx si verificano quando il problema riguarda il client ed è potenzialmente un problema di rete.

  • i codici 4xx possono essere utilizzati come risposta a qualsiasi metodo di richiesta.
  • Il server di origine dovrebbe includere una spiegazione che dovrebbe essere visualizzata dallo User-Agent, ad eccezione di una richiesta HEAD.
  • Le regole personalizzate possono restituire qualsiasi codice di risposta nell'intervallo 400-499 nella pagina HTML, se il proprietario del sito ha creato una regola con azione Block e configurato un codice di risposta personalizzato.

Errore 400: richiesta errata

Il client non ha inviato una richiesta corretta al server. Si tratta di un errore del client, come una sintassi di richiesta malformata, una richiesta non valida, un framing del messaggio o un instradamento ingannevole della richiesta. Ad esempio, se la richiesta contiene un carattere speciale che non è codificato correttamente con l' URL (o con la percentuale), viene restituito l'errore " HTTP 400 ".

Se si riceve un errore " HTTP " quando si utilizza l'API " CIS ", assicurarsi di utilizzare la sintassi corretta, i parametri corretti e il corpo corretto per la chiamata API.

Errore 401: non autorizzato

La richiesta è stata inviata senza le corrette credenziali di autenticazione.

Errore 403: Vietato

Se si vede un errore 403 senza il marchio CIS, questo viene sempre restituito direttamente dal server web di origine, non da CIS, ed è generalmente legato alle regole di autorizzazione sul server. I motivi principali di questo errore sono:

  • Regole di autorizzazione impostate sul server web di origine (ad esempio, nel file .htaccess Apache )
  • Regole di sicurezza Mod_security
  • Regole di rifiuto IP. Assicurarsi che gli intervalli IP di CIS non siano bloccati.

CIS servirà risposte 403 se la richiesta ha violato una regola gestita dal WAF predefinita o una regola gestita dal WAF abilitata per quella particolare zona.

Risoluzione Se viene visualizzata una risposta 403 che contiene un marchio CIS nel corpo della risposta, questo è il codice di risposta HTTP restituito insieme alle funzionalità di sicurezza:

  • Regole personalizzate o gestite WAF con l'azione di sfida o blocco
  • Livello di sicurezza impostato per default su Medio
  • La maggior parte dei codici di errore 1xxx CIS
  • Il controllo di integrità del browser

Errore 404: Non trovato

Il server di origine non ha potuto o voluto trovare la risorsa richiesta. Questo di solito significa che il server host non è riuscito a trovare la risorsa. Per servire una versione più permanente di questo errore, utilizzare un codice di errore " 410.

Questi errori si verificano in genere quando qualcuno digita erroneamente un indirizzo URL sul tuo sito quando c'è un link interrotto da un'altra pagina, quando una pagina che esisteva in precedenza viene spostata o rimossa, o c'è un errore quando un motore di ricerca indicizza il tuo sito. Per un sito tipico, questi errori rappresentano circa il 3% delle visualizzazioni totali delle pagine, ma spesso non vengono rilevati dalle piattaforme di analisi tradizionali.

I proprietari dei siti web di solito implementano una pagina personalizzata da servire quando viene generato questo errore.

Risoluzione CIS non genera errori '404 per i siti web dei clienti. CIS limita a proxyare la richiesta dal server di origine. Quando vedete un " 404 per il vostro sito, contattate il vostro provider di hosting per chiedere aiuto.

Errore 405: Metodo non consentito

Il server di origine è a conoscenza della risorsa richiesta, ma il metodo di richiesta non è supportato.

Risoluzione Il server di origine deve anche fornire un'intestazione Allow con un elenco di obiettivi supportati per quella risorsa.

Errore 406: non accettabile

Il server non può produrre una risposta che corrisponda all'elenco dei valori accettabili definiti nelle intestazioni di negoziazione del contenuto della richiesta e il server non è disposto a fornire una rappresentazione predefinita.

Risoluzione Invece di generare questo errore, si può servire il metodo meno preferito all'User-Agent.

Errore 407: è richiesta l'autenticazione

Il client non ha inviato l'autenticazione richiesta con la richiesta.

Risoluzione Riprovare la richiesta con l'autenticazione necessaria.

Errore 408: Timeout della richiesta

Il server di origine non ha ricevuto la richiesta completa in un tempo ragionevole. Questo errore indica che il server non vuole aspettare e continuare la connessione.

Risoluzione Questo errore non è comune perché i server di solito utilizzano l'opzione di connessione "close".

Errore 409: conflitto

La richiesta non è stata completata a causa di un conflitto con lo stato attuale della risorsa. Questo errore si verifica tipicamente su una richiesta 'PUT in cui più client tentano di modificare la stessa risorsa.

Risoluzione Il server deve generare un payload che includa informazioni sufficienti al client per riconoscere l'origine del conflitto. I clienti possono e devono riprovare la richiesta.

CIS genera e serve una risposta '409 per un 'Error 1001: DNS Resolution Error.

Errore 410: Andato

La risorsa richiesta manca permanentemente all'origine.

Risoluzione Il server suggerisce di rimuovere i collegamenti alla risorsa. Il server non è qualificato per utilizzare questo codice di stato al posto di una risposta " 404, né è tenuto ad avere questa risposta per un periodo di tempo specifico.

Errore 411: Lunghezza richiesta

Il client non ha definito la lunghezza del contenuto del corpo della richiesta nelle intestazioni e questo parametro è necessario per ottenere la risorsa.

Risoluzione Il client può inviare nuovamente la richiesta dopo aver aggiunto il campo di intestazione.

Errore 412: Condizione preliminare fallita

Il server nega la richiesta perché la risorsa non soddisfa le condizioni specificate dal client.

Per un esempio di controllo di versione, un client sta modificando una risorsa esistente e imposta l'intestazione " If-Unmodified-Since in modo che corrisponda alla data in cui il client ha scaricato la risorsa e ha iniziato a modificarla. Se la risorsa è stata modificata (probabilmente da un altro cliente) dopo questa data e prima del caricamento delle modifiche, questa risposta viene generata perché la data dell'ultima modifica è successiva alla data impostata in 'If-Unmodified-Since dal cliente.

La risoluzione CIS servirà questa risposta.

Errore 413: carico utile troppo grande

Rifiuto da parte del server di elaborare la richiesta perché il payload inviato dal client è più grande di quello accettato dal server. Il server può chiudere la connessione.

Se questo rifiuto avviene solo temporaneamente, il server dovrebbe inviare un'intestazione " Retry-After per specificare quando il client dovrebbe riprovare la richiesta.

Il limite di upload per il CIS dipende dal vostro piano. Se si supera questo limite, la chiamata API riceve un errore " 413 Request Entity Too Large.

| Standard aziendale |-|--------|----------| |Disponibilità: Sì, Sì |Caricamento massimo 'size|200 'MB|500 MB|

Risoluzione Se avete bisogno di un upload maggiore, suddividete le richieste in parti più piccole, cambiate il vostro record DNS in solo DNS o aggiornate il vostro piano.

Errore 414: URI troppo lungo

Rifiuto da parte del server: l'URI è troppo lungo per essere elaborato. Ad esempio, se un client tenta una richiesta " GET " con un URI insolitamente lungo dopo un POST, questo può essere interpretato come un rischio per la sicurezza e viene generato un errore " 414.

La risoluzione CIS genererà questa risposta per un URI più lungo di 32KB.

Errore 415: Tipo di supporto non supportato

Rifiuto del server di elaborare il formato del payload corrente. Un modo per identificare e risolvere questo problema consiste nell'esaminare le intestazioni " Content-Type o " Content-Encoding inviate nella richiesta del client.

Errore 416: Intervallo non soddisfabile

Il codice di risposta all'errore " 416 " indica che un server non può servire gli intervalli richiesti. Ad esempio:

  • HTTP/1.1 416 Range Not Satisfiable
  • Content-Range: bytes */12777

Risoluzione Il motivo più comune dell'errore '416 è che il file non include tali intervalli. I browser di solito richiedono nuovamente l'intero file o interrompono l'operazione.

Errore 417: aspettativa fallita

Il server non ha soddisfatto i requisiti specificati nell'intestazione 'Expect della richiesta del cliente.

Errore 429: Troppe richieste

Il client ha inviato un numero eccessivo di richieste nel tempo specificato, secondo il server (spesso noto come "rate-limiting"). Il server potrebbe rispondere con informazioni che consentono al richiedente di riprovare la richiesta dopo un determinato periodo di tempo.

Il limite di velocità globale per l'API CIS È di 1200 richieste ogni cinque minuti per utente e si applica in modo cumulativo, indipendentemente dal fatto che la richiesta sia effettuata tramite dashboard, chiave API o token API. Se si supera questo limite, tutte le chiamate API per i cinque minuti successivi vengono bloccate, ricevendo una risposta di tipo " HTTP 429.

Alcune chiamate API specifiche hanno i propri limiti e sono documentate separatamente, come le API di Cache Purge, le API di GraphQL, e le API di rulesets.

Risoluzione I clienti Enterprise possono contattare l'assistenza per aumentare il limite.

CIS genera e invia questo codice di stato quando una richiesta viene limitata. Se i visitatori del vostro sito ricevono questi codici di errore, è possibile vederlo in Rate Limiting Analytics.

Errore 451: Non disponibile per motivi legali

Il server non è in grado di consegnare la risorsa a causa di azioni legali.

In genere sono i motori di ricerca e gli ISP a essere interessati da questo codice di risposta, non il server di origine. La risposta deve includere una spiegazione nel corpo della risposta con i dettagli della richiesta legale.

Errore 499: Richiesta di chiusura del client

L'errore " 499 è un codice di risposta specifico di nginx che indica quando la connessione è stata chiusa dal client mentre il server sta ancora elaborando la richiesta, il che rende il server incapace di inviare un codice di stato.

Questo errore viene visualizzato nei log CIS e nelle analisi dei codici di stato per i clienti Enterprise.

Poiché il partner di CIS Cloudflare è basato su nginx, nei registri e nelle analisi di Cloudflare è presente un codice 499 HTTP per le connessioni, che vengono interrotte prima che CIS abbia terminato l'elaborazione della richiesta. È un comportamento atteso quello di vedere questi dati nei log quando i client chiudono le connessioni.

Per fornire un contesto più ampio, deve essere stabilita una connessione TCP tra CIS e il server di origine del sito web prima che qualsiasi protocollo superiore inizi la "conversazione". Per stabilire una connessione, il TCP utilizza un handshake a tre vie:

  1. SYN: CIS invia tre pacchetti SYN al server di origine.
  2. SYN+ACK: in risposta, il server di origine risponde con un SYN+ACK.
  3. ACK: infine, CIS invia un ACK al server di origine.

A questo punto, sia CIS che il server di origine hanno ricevuto una conferma della connessione e la comunicazione è stabilita. Tuttavia, se il server di origine non invia un SYN+ACK a CIS entro 15 secondi, CIS ritenta un'altra volta.

A seconda del valore di timeout sul lato client, si possono vedere tre diversi scenari con i rispettivi codici di stato generati.

  • Se il client ha un timeout più breve (meno di 30 secondi), abbandona la connessione e CIS registra l'errore " 499.
  • Se il client ha un timeout più lungo (più di 30 secondi), dopo che la connessione TCP è stata stabilita, la transazione di tipo " HTTP " continua. In questo caso, CIS restituisce un normale codice di stato di HTTP 200.
  • Se il client ha un timeout più alto e CIS non è stato in grado di stabilire l'handshake TCP con il server di origine, CIS restituisce 'HTTP 522.