comment effacer les redirections http mises en cache par winsock (301 permanently moved)

Question

J'utilise winsock pour envoyer des requêtes http à internet. J'ai découvert que quelque chose dans le système de mon ordinateur met en cache les réponses http 301 déplacées de façon permanente. Ainsi, si j'envoie une requête GET pour une certaine URL, elle renvoie une ancienne réponse sans rien envoyer sur le web. Le problème, c'est que la réponse mise en cache est erronée. Je veux vider le cache, mais je ne sais même pas qui s'occupe de la mise en cache.

Je sais comment effacer ce cache dans mon navigateur. De même, lorsque j'utilise wininet au lieu de winsock, il n'y a pas de problème. Où se trouve le cache pour winsock et comment l'effacer ?

EDIT : La réponse d'Andreas ci-dessous occasionne quelques remarques. Mon programme fonctionne comme un proxy sur localhost, recevant des requêtes de Firefox et les envoyant sur le web. Les requêtes sont donc préparées par Firefox et l'en-tête host est toujours présent. La raison pour laquelle je pense que cela a quelque chose à voir avec winsock sur mon propre ordinateur est que Firefox obtiendra la page correctement si je n'utilise pas mon serveur proxy. Il n'y a pas de réponse 301 dans ce cas. Mais Firefox avait aussi ce problème (sans proxy) jusqu'à ce que j'efface son historique (oublier ce site). C'est pourquoi je pense qu'il doit s'agir d'un problème de cache winsock.

Puisque Firefox réussit (sans proxy) à vider son cache, ce n'est pas mon fournisseur d'accès qui fait la mise en cache. Notez que la requête envoyée est identique, qu'elle passe par mon proxy ou non. Je ne change rien. De plus, comme je l'ai dit, wininet fonctionne.

Je suis d'accord pour dire que winsock ne sait rien de http. Pourtant, il semble qu'il y ait un lien entre winsock et le fait que le web ait une fonction de cache. Quelle autre explication peut-il y avoir ? Mon proxy fonctionne correctement avec de nombreux autres sites, mais sur certains d'entre eux, j'obtiens cette réponse 301 permanently moved avec un en-tête location défectueux. Comment puis-je en savoir plus sur ce qui se passe ?

Answer 1

Winsock ne met pas les pages web en cache. Il ne connaît pas le protocole HTTP et ne peut donc pas mettre en cache les réponses HTTP.

Si vous n'utilisez effectivement que Winsock pour envoyer une requête HTTP, et si vous le faites directement (pas par l'intermédiaire d'un proxy), alors il doit s'agir d'un proxy transparent qui met en cache les demandes. Certains fournisseurs de services Internet les utilisent, ce qui entraîne souvent des problèmes techniques.

Cependant, je ne suis pas convaincu qu'il s'agisse d'un problème de cache. Si vous utilisez Winsock pour envoyer une requête HTTP, je pense qu'il est plus probable qu'il y ait un problème avec votre requête HTTP. Par exemple, de nos jours, de nombreux serveurs utilisent l'hébergement virtuel et exigent donc que le client envoie le champ "Host" dans l'en-tête HTTP, afin que la demande puisse être affectée au serveur virtuel correct. Si vous ne le faites pas, vous serez servi par le mauvais serveur virtuel. C'est peut-être la raison pour laquelle vous recevez une réponse HTTP 301 définitivement déplacée et c'est peut-être aussi la raison pour laquelle cela fonctionne avec WinInet (parce qu'il envoie un champ d'en-tête "Host" correct).

Toutefois, cela contredit votre affirmation selon laquelle l'envoi d'une requête GET pour une certaine URL n'envoie rien sur l'internet. Qu'est-ce qui vous fait penser que c'est le cas ? Utilisez-vous un renifleur de paquets réseau ?

Answer 2

Je crois que je l'ai trouvé. Ce n'est pas un problème de cache après tout. Il y a un bogue dans certains serveurs ou sous-serveurs. Certains frameworks de serveurs courants comme PHP. Le problème est le suivant : Si je demande le document racine du site avec l'url complète (GET http://example.com ), il renvoie une réponse 301 définitivement déplacée avec un en-tête de localisation erroné. Si je le demande avec GET /, cela fonctionne et le document est renvoyé avec le statut 200 OK.

Ce que je fais maintenant, c'est de vérifier si la cible est une url absolue. Si c'est le cas, je vérifie si le chemin est vide. Si c'est le cas, je change la cible en /.

Maintenant, cela fonctionne et je ne reçois plus de réponses 301.