ForHosting KIT · Veille et lecture de sites web

Vérifier ETag faible ou fort

Collez un ETag et sachez aussitôt s'il est faible ou fort : W/"abc123" est faible, avec abc123 comme étiquette interne, tandis que "v1-hash" est fort. Des guillemets manquants ou un w/ minuscule sont signalés au lieu d'être devinés. Gratuit dans votre navigateur.

Gratuit
Fonctionne dans votre navigateur
Sans inscription
Vos données restent sur votre appareil

Lancer gratuitement Voir l’API

Utilisez-le depuis WebAPIE-mailTelegramApp bientôt

Exemple résolu

Si vous saisissez

ETag: W/"abc123"

Vous obtenez

Intensité: weak
Balise opaque: abc123
Balise entre guillemets: "abc123"
Préfixe: W/

Un validateur fort affirme une correspondance exacte octet par octet ; un validateur faible, marqué par le préfixe W/ sensible à la casse avant l'opaque-tag entre guillemets, n'affirme qu'une équivalence sémantique. Mal analyser ce préfixe ou accepter un jeton non cité conduit à de mauvaises décisions If-Match et If-None-Match, à des frappes de cache périmées et à des mises à jour conditionnelles perdues. Cette capacité accepte une seule valeur d'en-tête ETag (ou une ligne ETag: complète), vérifie que l'opaque-tag est correctement entouré de guillemets doubles selon la RFC 9110, classe le validateur comme faible ou fort et renvoie les parties normalisées de la balise.

Ce que signifient les ETags faibles et forts selon la RFC 9110

Un entity-tag est une chaîne opaque entre guillemets qu'un serveur associe à une représentation précise d'une ressource. Lorsque le serveur vise un validateur fort, il émet uniquement la balise entre guillemets, par exemple "v3-a1b2c3". Lorsqu'il vise un validateur faible, il préfixe cette balise du jeton sensible à la casse W/, de sorte que la valeur complète ressemble à W/"v3-a1b2c3".

Les validateurs forts peuvent servir à la revalidation de cache comme aux décisions sûres de contenu partiel ou de plages exigeant une correspondance exacte. Les validateurs faibles garantissent seulement que les représentations sont équivalentes à des fins de cache ; ils ne doivent pas être pris pour une preuve que chaque octet est identique. Les en-têtes de requête conditionnelle tels que If-Match, If-None-Match et If-Range comparent les balises fournies par le client à la balise actuelle du serveur selon ces règles.

Si un client ou un intergiciel retire par accident le préfixe W/, une balise faible est traitée comme forte et peut autoriser à tort une requête de plage ou une écriture conditionnelle. Si les guillemets sont omis, intermédiaires et analyseurs divergent sur la fin du jeton. Ce vérificateur existe pour que vous validiez une chaîne ETag stockée ou journalisée avant de la comparer, de la documenter ou de l'injecter dans un autre système qui attend la forme stricte de la RFC.

Contrat d'entrée, champs de réponse et règles de rejet

Vous pouvez coller l'entity-tag nu ou une ligne d'en-tête complète telle que ETag: W/"abc". Les espaces en tête et en queue sont supprimés ; un préfixe optionnel ETag: est retiré sans distinction de casse. La valeur restante doit être "opaque" pour un validateur fort ou W/"opaque" pour un faible.

Le W doit être en majuscule ; un w/ minuscule est rejeté car la RFC 9110 définit le marqueur faible comme sensible à la casse. L'opaque-tag doit commencer et finir par des guillemets doubles, ne doit pas contenir de guillemet double interne non échappé et ne peut utiliser que des caractères etagc : ASCII imprimable sauf guillemet, plus obs-text. Exemple : "v1-hash" donne strong true et strength strong.

Cas d’usage

Audits d'en-têtes CDN et passerelles

Collez des échantillons d'ETag de production et confirmez quelles réponses utilisent des validateurs faibles ou forts avant d'ajuster les règles de cache et de revalidation.

Support et triage HAR

Classez des ETags issus de fichiers HAR ou de tickets dans l'outil gratuit du navigateur pour diagnostiquer les bogues de requêtes conditionnelles sans scripts sur mesure.

Questions fréquentes

Comment savoir si un ETag est faible ou fort ?

Envoyez la valeur ETag (par exemple W/"abc" ou "abc"). Si elle commence par le préfixe W/ sensible à la casse avant la balise entre guillemets, strength est weak ; sinon une balise correctement citée est strong.

Que se passe-t-il si l'ETag n'est pas entre guillemets ?

La RFC 9110 exige que l'opaque-tag soit entouré de guillemets doubles ; les jetons non cités sont rejetés plutôt que devinés.

Le préfixe W/ est-il sensible à la casse ?

Oui. Seul W/ en majuscules est le marqueur faible. Des valeurs comme w/"tag" sont rejetées afin de ne pas traiter en silence un préfixe non conforme comme fort ou faible.

Puis-je coller une ligne d'en-tête ETag: complète ?

Oui. Un nom initial ETag: est retiré sans distinction de casse ; l'entity-tag restant est ensuite classé.

Quand la différence entre ETag faible et fort compte-t-elle ?

Quand un cache ou un client compare des étiquettes pour savoir si quelque chose a changé. Un ETag fort prouve une correspondance exacte octet par octet et peut servir aux téléchargements partiels ou aux écritures sûres ; un faible indique seulement une équivalence pour le cache.

Outils associés

Pour les développeurs — accès API

Tout sur cette page est disponible par programmation. Cette section s'adresse aux équipes qui veulent l'intégrer à leurs systèmes ; les autres peuvent simplement utiliser l'outil ci-dessus.

Endpoint

POSThttps://api.kit.forhosting.com/web/etag-weak-strong-check

Authentification par jeton Bearer : un seul POST met la tâche en file d’attente, et le résultat vous parvient par webhook ou lien signé.

Appeler depuis votre stack

curl -X POST https://api.kit.forhosting.com/web/etag-weak-strong-check \
  -H "Authorization: Bearer $KIT_KEY" \
  -H "Content-Type: application/json" \
  -d '{"etag":"W/\"abc123\""}'

const res = await fetch("https://api.kit.forhosting.com/web/etag-weak-strong-check", {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${process.env.KIT_KEY}`,
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    "etag": "W/\"abc123\""
  })
});
const { task_id } = await res.json();

import os, requests

res = requests.post(
    "https://api.kit.forhosting.com/web/etag-weak-strong-check",
    headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
    json={
    "etag": "W/\"abc123\""
},
)
task_id = res.json()["task_id"]

<?php
$res = file_get_contents("https://api.kit.forhosting.com/web/etag-weak-strong-check", false, stream_context_create([
  "http" => [
    "method"  => "POST",
    "header"  => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
    "content" => '{"etag":"W/\\"abc123\\""}',
  ],
]));
$task = json_decode($res, true);

body := bytes.NewBufferString(`{"etag":"W/\"abc123\""}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/web/etag-weak-strong-check", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)

Exemple de requête

{
  "etag": "W/\"abc123\""
}

Exemple de réponse

{
  "task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
  "type": "web.etag_weak_strong_check",
  "status": "queued",
  "_links": {
    "result": "/tasks/tsk_…/result"
  }
}

L’API est asynchrone : chaque appel renvoie un task_id immédiatement, puis vous interrogez l’état à raison d’une requête par seconde.

Tarifs

par requête$0.002

Le prix est publié, sans tokens ni crédits. Une tâche qui échoue n’est pas facturée.

Limites

`timeout_sec`	30
`max_crawl_pages`	25

Erreurs

HTTP	Code	Signification
`401`	`unauthorized`	Clé API absente ou invalide : vérifiez l’en-tête Authorization.
`402`	`insufficient_balance`	Solde insuffisant : rechargez votre compte pour lancer cette tâche.
`404`	`unknown_type`	Type de tâche inconnu : vérifiez le champ type de votre requête.
`429`	`rate_limited`	Trop de requêtes : ralentissez la cadence, puis réessayez.

Notes techniques

Les balises d'entité HTTP (ETags) indiquent aux caches et aux clients si deux représentations d'une ressource sont identiques. Guillemets invalides, valeurs vides et préfixes faibles non conformes à la RFC échouent avec invalid_input au lieu d'une fausse classification silencieuse. La même logique d'analyse pure alimente l'outil gratuit du navigateur et le chemin API prépayé.

Contrat d'entrée, champs de réponse et règles de rejet

Envoyez un corps JSON avec un champ chaîne obligatoire nommé etag (les alias value, header, tag et entity_tag sont acceptés). En cas de succès la réponse inclut etag (forme normalisée avec W/ et guillemets, ou seulement entre guillemets), les booléens weak et strong, strength comme la chaîne weak ou strong, opaque_tag (contenu intérieur sans guillemets), quoted_tag, prefix (vide ou W/), valid true et une courte note sur la classe du validateur. Entrée manquante, chaînes vides après suppression du nom d'en-tête, balises non citées comme abc123, guillemets mal appariés, caractères illégaux et mauvais préfixes faibles lèvent invalid_input et ne sont pas facturés. Exemple : W/"abc123" donne weak true, strength weak, opaque_tag abc123.

Où un vérificateur de force d'ETag apporte de la valeur

Une validation en échec ne consomme pas le solde. Gardez l'opaque-tag opaque dans votre documentation produit : ce point de terminaison ne hache jamais votre corps à votre place ; il classe seulement le format de balise que vous avez déjà, et figez les goldens lorsque vous intégrez le vérificateur en CI. Les revues de configuration de passerelles API et de CDN collectent souvent des échantillons d'en-têtes de réponse et ont besoin d'une réponse rapide et déterministe sur le caractère faible ou fort de chaque ETag avant de rédiger des politiques de cache. Des tests de contrat automatisés pour services REST peuvent affirmer que des documents JSON versionnés émettent des balises fortes tandis que des pages HTML rendues utilisent volontairement des balises faibles, faisant échouer le build lorsque les guillemets ou le préfixe W/ dérivent. Les sites de contenu ciblant des requêtes telles que validateur etag faible fort gagnent un outil vivant dont le chemin client gratuit correspond au chemin API payant sur le même module pur. Comme l'implémentation est un parse pur de niveau A, chaque appel réussi coûte le prix de base publié $0.002 sans jetons de modèle ni réseau sortant.

Cas d'intégration

Contrats API et contrôles CI

Affirmez dans les tests qu'un service émet des ETags forts ou faibles correctement entre guillemets et que le pipeline échoue si les guillemets manquent ou si le préfixe W/ est incorrect.

Questions techniques

Combien coûte la vérification ETag faible ou fort ?

L'outil navigateur est gratuit. Les requêtes API utilisent le solde KIT prépayé à $0.002 par appel réussi ; une entrée invalide n'est pas facturée.

Consulter la documentation complète du KIT →

Lancer gratuitement

Exemple résolu

Ce que signifient les ETags faibles et forts selon la RFC 9110

Contrat d'entrée, champs de réponse et règles de rejet

Cas d’usage

Audits d'en-têtes CDN et passerelles

Support et triage HAR

Questions fréquentes

Outils associés

Pour les développeurs — accès API

Endpoint

Appeler depuis votre stack

Exemple de requête

Exemple de réponse

Tarifs

Limites

Erreurs

Notes techniques

Contrat d'entrée, champs de réponse et règles de rejet

Où un vérificateur de force d'ETag apporte de la valeur

Cas d'intégration

Contrats API et contrôles CI

Questions techniques

merci