Ca marche en wifi pas en 3G

[Hubert]

Je cherche de l'aide dans la communauté des développeurs android francophones.

J'ai un projet d'appli android : une partie serveur que j'installe sur un tomcat qui a pignon sur internet et une partie cliente sur android.

J'ai donc fait une servlet qui renvoie "Hello World" que j'ai déployée. J'ai fait avec l'HttpClient du SDK une appli android qui se connecte sur cette servlet et affiche la réponse.

Ca marche en wifi et pas en 3G. Le symptôme est simple : dans les deux cas, ma servlet est atteinte et répond avec succès. Mais dans le cas de la 3G, la réponse se perd en chemin.

Je suis chez SFR et j'ai l'impression qu'un proxy squid sur proxy.cwg.net drop cette réponse.

Du coup, j'aimerais me rapprocher de personne qui ont de l'expérience sur le sujet voire carrément de SFR.

Des conseils ?

[shino]

As-tu un forfait Full Illmythics (en utilisant l'APN "sl2sfr") ou un forfait avec l'APN "wapsfr" ? Le wapsfr est limité et fonctionne avec un proxy, en TCP et sur http et https uniquement. Il peut potentiellement bloquer la connexion à la servlet typiquement.

[Hubert]

Erreur ICAP

[dekans]

Supprime le user agent, et ça ne sera plus bloqué par le firewall d'SFR.

[julien04]

Bonjour,

Je suis arrivé sur cette page grâce à une recherche, car hier soir j'ai eu un problème de proxy.cwg.net alors que je naviguais normalement avec le navigateur intégré.

Ca confirme donc que SFR nous fait passer dans un proxy à l'autre bout du monde, malgré l'option full-internet, ça ne choque personne ?

Ca me donne envi d'appeler le service client, mais je ne sais même pas quel service demander pour tomber sur qq1 qui comprenne le problème.

[Prydalol]

900 1/5/3 pour le service technique ^^ Mais soit l'interlocuteur va pas comprendre, soit il va faire l'ignorant et te dire qu'ils vont enquéter et envoyer une réponse sous 5 jours pour au final dire qu'ils peuvent rien faire :D

[Hubert]

Je déteste quand ça fait ça : ça s'est mis à marcher subitement. Je n'arrivais pas à supprimer le header "Vary: User-Agent" que rajoute Tomcat selon la suggestion de Dekans... Par dépit, j'ai refait un essai avant de remettre ça à demain ...et hop ! J'ai reçu ma réponse. Mon code n'a pas bougé, ni la config serveur ni rien.

Et à présent, je réessaye en boucle et les résultats alternent entre ERR_ICAP_FAILURE, rien du tout et de temps en temps la réponse attendue. En dehors de ce dernier cas où tout va très vite, c'est le timeout Android qui me rend la main (ou bien je kill le process depuis l'ADT) ou j'attends jusqu'à ce que NoHttpResponseException s'en suive.

Modifié 18 janvier 2010 par Hubert

[dekans]

Le header que tu dois virer, c'est celui de ton appli android, celui de Tomcat n'a aucune importance.

[Hubert]

Dekans, je n'ai pas de header dans mon code à part le ContentType qui est nécessaire :

resp.setContentType("text/plain");
resp.setCharacterEncoding("utf-8");
PrintWriter out = resp.getWriter();
out.append("Salut à tous !");
out.flush();
out.close();

[Hubert]

Ca y est, je l'ai eu. Je tire mon chapeau à Dekans qui m'a mis sur la voie et à l'équipe de la devzone des ateliers SFR (http://devzone.ateliersfr.fr/) qui m'ont vraiment filé un chouette coup de main.

j'ai du rajouter cette ligne de code dans mon client http :

HttpProtocolParams.setUseExpectContinue(httpClient.getParams(), false);

En effet, j'ai fini par tracer tout le dialogue TCP sur mon serveur. En parallèle, je suis parvenu à faire marcher en 3G une page HTML qui était censée faire exactement la même requête en Ajax que ce que je fais dans mon code. J'ai ensuite adapté mon programme pour incrémentalement lui ajouter exactement les mêmes headers HTTP que la requête ajax telle que vue par mon serveur. C'est quand j'en suis venu à ce header que le problème a stoppé :

Expect: 100-Continue

Ce header figurait dans la requête de mon client et pas dans la requête émise en Ajax. Avec la ligne de code citée plus haut, je l'ai supprimée. Apparemment, il y est par défaut avec le DefaultHttpClient du SDK d'android. Je ne pense pas qu'en soit ce header soit très néfaste. Clairement, après tous mes tests, j'arrive à la conclusion que le serveur squid de proxy.cwg.net n'est sans doute pas très clean...

Encore merci à Guillaume de l'équipe SFR, j'ai beaucoup apprécié.

[dekans]

C'est bon à savoir.

en faisant une recherche sur "Expect: 100-Continue", je vois que ça ne concerne pas qu'Android ce problème.

According to the HTTP 1.1 protocol, when this header is sent, the form data is not sent with the initial request. Instead, this header is sent to the web server which responds with 100 (Continue) if implemented correctly. However, not all web servers handle this correctly, including the server to which I am attempting to post data.

Je vais appliquer ta solution sur mes requêtes aussi maintenant.

[p1erstef]

Merci Hubert !

Ca faisait plusieurs mois que mon envoi de fichiers en HttpPost ne fonctionnait plus sur la 3G de SFR, alors qu'il fonctionnait très bien avant, et qu'il fonctionnait encore parfaitement en wifi et sur la 3G d'Orange...

Je me suis bien pris la tête à cause de ce truc...

Mais l'ajout de ta ligne de code à résolu mon pb, cool !

[rorolepro]

Merci beaucoup, je me prenais la tête sur ce problème depuis un moment !!!!

[davestar]

Merci beaucoup, j'ai perdu pas mal de temps sur cette connerie.

J'avais le même genre de problème sur windows mobile, il fallait rajouter le user agent à la main de sfr ....

[Pixel166]

Merci beaucoup pour ce post, qui m'a permis d'avancer un peu pour mon appli actuelle ;)

[jerome73]

C'est bon à savoir.

en faisant une recherche sur "Expect: 100-Continue", je vois que ça ne concerne pas qu'Android ce problème.

Je vais appliquer ta solution sur mes requêtes aussi maintenant.

Bonjour

Je suis très intéressé par ce sujet ; je travaille actuellement sur un site web mobile, déployé sur un serveur Tomcat (J2EE / Spring).

Avant le tomcat, il y a bien sûr des niveaux de sécurité (firewall, loadbalancer)

Le site mobile depuis les iphones fonctionne très bien en WIFI, en 3G Orange et Bouygues.

En 3G SFR, nous avons régulièrement des popups dans Safari indiquant qu'il ne peut pas ouvrir la page (ensuite, la popu s'efface et la page résultat arrive quand même !)

Avez-vous la solution à ce problème dans un environnement J2EE de ce type ? Car ce n'est pas une application, mais bien un site web mobile accessible depuis Safari.

Merci d'avance pour votre aide

Jerome