En bref. Une requête à l’API Brave Search peut envoyer Cache-Control: no-cache, mais Brave précise que le traitement s’effectue dans la mesure du possible.
Définition : Oui. La documentation de référence de l’API Web Search de Brave, consultée le 17 octobre 2026, indique que l’en-tête de requête
Cache-Control: no-cachepermet de demander des contenus sans cache. Brave précise que ce traitement s’effectue dans la mesure du possible (« best effort ») : cet en-tête demande donc une validation, sans promettre un nouvel ensemble de résultats.
Points clés
- La documentation de référence de l’API Web Search de Brave indique que Brave Search renvoie par défaut du contenu en cache.
- La même documentation indique de donner la valeur
no-cacheà l’en-têteCache-Controlpour empêcher la mise en cache. - Brave qualifie ce traitement de « best effort » : son résultat dépend donc de l’implémentation du service.
- La RFC 9111 définit les directives de cache des requêtes comme indicatives : les caches peuvent les appliquer sans y être tenus.
- Dans cette norme,
no-cachedemande qu’une réponse stockée ne serve pas à satisfaire la requête sans validation réussie auprès du serveur d’origine.
Quel en-tête Brave documente-t-il ?
Brave place ce réglage parmi les en-têtes de requête de l’API Web Search. Sa documentation indique que le contenu en cache constitue le comportement par défaut et présente Cache-Control: no-cache comme le moyen d’empêcher la mise en cache. Une requête peut donc inclure cet en-tête aux côtés de l’en-tête d’authentification de l’API figurant dans l’exemple de Brave :
curl "https://api.search.brave.com/res/v1/web/search?q=brave+search" \
-H "Cache-Control: no-cache" \
-H "X-Subscription-Token: <YOUR_API_KEY>"
La documentation nuance ce comportement par la mention « best effort ». Brave ne décrit aucun champ de réponse confirmant un contournement du cache, et la documentation ne précise aucun intervalle de fraîcheur pour cette option de requête.
Que signifie no-cache en HTTP ?
La RFC 9111 décrit Cache-Control comme un champ d’en-tête contenant des directives destinées aux caches le long de la chaîne de requête et de réponse. Sa section consacrée aux directives de requête précise qu’elles sont indicatives. Selon la définition de la directive de requête no-cache donnée par la norme, une réponse stockée ne devrait pas servir à satisfaire la requête sans validation réussie auprès du serveur d’origine.
Cette définition concerne la réutilisation d’une réponse stockée. Elle n’exige pas que la réponse soit absente de tous les caches une fois la requête terminée. La RFC 9111 attribue un sens distinct à no-store : un cache ne doit stocker aucune partie de la requête ni d’aucune réponse à celle-ci. La documentation Web Search de Brave mentionne no-cache : il s’agit donc du réglage documenté pour cette requête à l’API.
Que permet d’établir une vérification des résultats ?
L’envoi de l’en-tête atteste que le client demande à Brave d’éviter de satisfaire la requête à partir d’une réponse stockée non validée. La réserve « best effort » du fournisseur permet au client de considérer cet en-tête comme une demande de fraîcheur, les données renvoyées restant les éléments dont il dispose pour effectuer sa vérification.
La norme HTTP distingue également une réponse fraîche d’une réponse périmée en comparant son âge à sa durée de fraîcheur. Une réponse fraîche peut satisfaire des requêtes ultérieures sans contacter le serveur d’origine. La documentation de Brave ne décrit aucun en-tête de réponse, aucune valeur de statut ni aucun champ JSON permettant de savoir si cette requête à l’API a déclenché une nouvelle opération de recherche : ce point de vérification reste donc ouvert.
Termes associés
- Brave Search API
- Cache-Control
- Comment filtrer les résultats de l’API Brave Search par date ?
- Localisation de Brave Search
Questions fréquentes
Dois-je envoyer Cache-Control: no-cache comme paramètre de requête ?
Non. Envoyez-le comme en-tête de requête HTTP. La documentation de référence de l’API Web Search de Brave place Cache-Control parmi les en-têtes de requête et indique no-cache comme valeur.
Cet en-tête assure-t-il la production d’un nouvel ensemble de résultats ?
Non. Brave qualifie ce comportement de « best effort », et la RFC 9111 décrit les directives de requête comme indicatives. Selon la définition HTTP de no-cache, cet en-tête demande une validation avant la réutilisation d’une réponse stockée.
no-cache et no-store ont-ils le même sens ?
Non. La RFC 9111 emploie no-cache pour la validation avant réutilisation et no-store pour une interdiction de mise en cache couvrant la requête et sa réponse. La documentation de référence de l’API de Brave indique no-cache pour cette requête.
Sources
Vérifiez comment une page se lit pour les moteurs de réponse. Ouvrir l’analyseur de score GEO