Réponse HttpGet cachée pendant 10 minutes sur les Samsung Galaxy Sx/Note

Bonjour à tous,

j'ai un problème avec les smartphone et tablette Samsung Galaxy qui visiblement mettent en cache la réponse à une requête GET pendant dix minutes.
Dans certains cas ce n'est gênant mais dans mon cas il s'agit d'une requête qui vérifie que l'accès Internet est OK de bout en bout.

J'utilise le service de Microsoft à l'url suivante : http://www.msftncsi.com/ncsi.txt

Le test que je fais, c'est que je lance une première fois cette requête (avec le HttpClient Apache embarqué dans Android) quand Internet est KO puis je remet Internet en marche et je fais une deuxième requête identique.

Cela fonctionne très bien sur tous les smartphones ou tablettes de mes utilisateurs SAUF ceux qui ont un Samsung car la réponse de la première requête continue d'être rendue pendant 10 minutes même si Internet est OK.
Le plus drôle c'est que même le navigateur Internet du GS4 est bloqué pour cette requête...par contre, en supprimant le cache dans le navigateur le problème est corrigé...

Les codes HTTP retournés :
- première requête (Internet KO) : 302
- deuxième requête (Internet OK) : 404

Voici donc ma question : comment faire la même chose que le navigateur et supprimer le cache ? Ou comment éviter que ma réponse soit mise en cache ?

Pour info, j'ai tenté plusieurs solutions dans la journée dont :
- appel à une fonction un peu cachée de InetAdress : clearDnsCache().
- ajout d'un paramètre à valeur aléatoire à chaque requête.
- ajout d'un header "no-cache" même si j'ai bien saisi qu'il fallait aussi que le serveur le mette dans sa réponse.
- utilisation de UrlConnection à la place de HttpClient.
- passage en HTTPS avec gestion du fait que le serveur ne donne pas de certif (là j'étais désespéré).


Voilà, c'est chaud...j'ai encore la piste d'exploration des répertoires du cache HTTP pour trouver et virer la partie du cache qui m'embête mais je ne pense pas pouvoir le faire sans être root...

Amis développeurs, à vot' bon cœur ! :)

Et merci d'avance pour votre aide (ou au moins pour m'avoir lu et réfléchi quelques secondes pour m'aider ;))

Tout le monde sèche ? Les experts Android sont en vacances ? :mrgreen:

Salut,


En théorie le "Cache control: no-cache" dans la requête devrait interdire l'utilisation d'un cache... à condition que Samsung respecte bien cela.

Sinon il y a une solution "simple" et souvent utiliser pour passer outre les caches, c'est de générer une URL unique à chaque requête, via un paramètre GET.
Par exemple au lieu d'accéder à la page http://www.msftncsi.com/ncsi.txt, tu demandes la page http://www.msftncsi.com/ncsi.txt?_=123456789 en changeant la valeur du paramètre à chaque appel :

Code:

---

String url = "http://www.msftncsi.com/ncsi.txt?_=" + System.currentTimeMillis();

---

Le serveur va sûrement ignorer le paramètre et te renvoyer les mêmes données, mais les proxy et divers caches traitement cela comme une URL différente...


a++

Est-ce que c'est vraiment un bon plan pour la batterie d'aller interroger une url toutes les 5 minutes? Quand je vois comment ma batterie de tél se vide avec des service qui ne se synchronozent que toutes les 30 minutes, quelque chose me dit qu'un service qui checke auss souvent tuerait ma batterie en 2 heures :aie:

Il ne serait pas préférable d'utiliser des méthodes dédiées à ça? Je trouve ceci avec un recherche rapide sur le net:

Code:

---

1 2 3 4 5 6

private boolean isNetworkAvailable() { ConnectivityManager connectivityManager = (ConnectivityManager) getSystemService(Context.CONNECTIVITY_SERVICE); NetworkInfo activeNetworkInfo = connectivityManager.getActiveNetworkInfo(); return activeNetworkInfo != null && activeNetworkInfo.isConnected(); }

---

La solution de _tchize ne répond pas à ta demande, mais juste histoire de la compléter :
Prendre en compte un protail captif : http://grepcode.com/file/repository....nnection%28%29

Ce qui me dérange plus est l'appli activant le wifi :aie:

Pour le cache Samsung, je ne vois que la solution d'Adiguba.

Rebonjour,

je vais répondre aux trois messages d'un seul coup pour éviter de spamer le thread ;)

Citation:

---

Envoyé par adiGuba

...
En théorie le "Cache control: no-cache" dans la requête devrait interdire l'utilisation d'un cache... à condition que Samsung respecte bien cela.

Sinon il y a une solution "simple" et souvent utiliser pour passer outre les caches, c'est de générer une URL unique à chaque requête, via un paramètre GET.
...

---

J'avais déjà testé ces deux solutions sans succès (cf. mon premier post) mais je veux bien vérifier à nouveau cette semaine. A suivre.

Citation:

---

Envoyé par tchize_

Est-ce que c'est vraiment un bon plan pour la batterie d'aller interroger une url toutes les 5 minutes?
...
Il ne serait pas préférable d'utiliser des méthodes dédiées à ça? Je trouve ceci avec un recherche rapide sur le net:

Code:

---

private boolean isNetworkAvailable() {...}

---

---

Cette fonction rend vrai à partir du moment où tu es connecté sur un routeur....cela ne vérifie pas que la connexion Internet est OK.

Pour info : je n'ai jamais dit que mon application lance cette requête toutes les 5 minutes...en réalité elle est lancée dans une sous-partie de ma vue "à propos" pour vérifier si je peux afficher un formulaire hébergé sur un serveur. Donc assez rare. Par contre, pour constater le bug sur les Samsungs je la lance plusieurs fois, en effet, mais ce n'est que pour étudier/corriger le bug.

Citation:

---

Envoyé par Hizin

La solution de _tchize ne répond pas à ta demande, mais juste histoire de la compléter :
Prendre en compte un protail captif : http://grepcode.com/file/repository....nnection%28%29
Lien SO : http://stackoverflow.com/questions/1...rtal-detection
Ce qui me dérange plus est l'appli activant le wifi :aie:

Pour le cache Samsung, je ne vois que la solution d'Adiguba.

---

J'ai déjà essayé avec UrlConnection également mais je vais retenter le coup.

Merci !

Perso, j'utilise le HttpUrlConnection pour soumettre mes requêtes et tout semble OK.
Par contre l'activation et la connection au Wifi prend quelques secondes, cela m'inquiète :ptdr: