Erreur réseau
Le report network-error envoyé par Network Error Logging quand une requête échoue au niveau réseau, avant de joindre votre serveur.
Dernière mise à jour:
Un report network-error décrit une requête qui a échoué (ou réussi, en cas
d'échantillonnage) au niveau réseau : un échec DNS, une erreur TCP ou TLS, une
connexion réinitialisée ou une erreur HTTP. Comme ces échecs n'atteignent souvent jamais
vos propres journaux, Network Error Logging (NEL) est le moyen de les voir du point
de vue du client.
Expérimental, et lié à l'ancien header
NEL est propre à Chromium et c'est le seul type de report qui exige encore le header déprécié Report-To. Reporting-Endpoints n'achemine pas NEL. Voir Network Error Logging.
Quand le navigateur l'envoie
Lors de l'échec d'une requête, ou lors d'une requête réussie quand le
success_fraction configuré l'échantillonne. Les paramètres failure_fraction et
success_fraction du header NEL contrôlent ce qui est reporté : en général, les échecs
sont capturés à plein taux et les succès seulement échantillonnés, voire pas du
tout.
Configuration
Report-To: {"group":"nel-group","max_age":31536000,"endpoints":[{"url":"https://<Endpoint-ID>.report.centralcsp.com"}]}NEL: {"report_to":"nel-group","max_age":31536000,"include_subdomains":true,"failure_fraction":1.0}Exemple de payload
{
"type": "network-error",
"age": 20,
"url": "https://example.com/bad-request",
"user_agent": "Mozilla/5.0 ...",
"body": {
"sampling_fraction": 1,
"referrer": "https://example.com/previous-page",
"server_ip": "192.0.2.172",
"protocol": "http/1.1",
"method": "POST",
"request_headers": {},
"response_headers": {},
"status_code": 400,
"elapsed_time": 338,
"phase": "application",
"type": "http.error"
}
}Référence des champs
| Champ | Signification |
|---|---|
sampling_fraction | Le taux auquel ce résultat a été échantillonné (0 à 1). |
referrer | Le referrer de la requête échouée. |
server_ip | L'IP du serveur résolue, ou "" si aucune. |
protocol | Le protocole utilisé, par exemple http/1.1. |
method | La méthode HTTP. |
request_headers | Les headers de requête que la politique NEL a choisi d'inclure, indexés par nom. |
response_headers | Les headers de réponse que la politique NEL a choisi d'inclure, indexés par nom. |
status_code | Le statut HTTP, ou 0 quand il n'y a pas eu de réponse. |
elapsed_time | Temps jusqu'à l'échec, en millisecondes. |
phase | Où elle a échoué : dns, connection ou application. |
type | Le code d'erreur précis, par exemple dns.name_not_resolved, tcp.refused, http.error. |
La phase est le triage le plus rapide : dns pointe vers la résolution de nom,
connection vers TCP ou TLS, et application vers une erreur de niveau HTTP.
Comment le recevoir
Associez le header NEL à un groupe Report-To (NEL ne fonctionne pas avec
Reporting-Endpoints). Pointez l'endpoint du groupe vers CentralCSP pour collecter le
flux network-error aux côtés de vos autres reports.
Ce qu'il vous apprend sur la sécurité
La plupart des erreurs réseau sont des signaux de disponibilité, mais leurs schémas comptent : un groupe d'échecs TLS ou de certificat depuis une même région peut indiquer une interception ou un portail captif, et une vague d'échecs DNS ou de connexion est un signal de disponibilité et d'intégrité qu'il vaut mieux creuser avant que les utilisateurs ne se plaignent.
Pièges
Les noms de champs du body sont en snake_case, contrairement aux reports de violation de
politique en camelCase. NEL est réservé à HTTPS et ne passe pas par
Reporting-Endpoints, seulement par l'ancien header Report-To : c'est le seul cas
où ce header reste nécessaire.
Prise en charge par les navigateurs
Navigateurs basés sur Chromium uniquement (Chrome, Edge, Opera). Firefox et Safari n'implémentent pas NEL, et Mozilla maintient une position défavorable au standard, au nom de la confidentialité.
Voir aussi
- Network Error Logging (NEL)
- header Report-To
- Report-To vs Reporting-Endpoints
- Monitoring NEL dans CentralCSP
- Le format de livraison des rapports