Je voudrais relever dans ce journal un changement passé sous silence concernant la nouvelle version de Firefox (la 29).
Il implémente désormais un timeout de 5 minutes sur les réponses HTTP : https://bugzilla.mozilla.org/show_bug.cgi?id=947391
Dis comme cela, cela semble anodin. Mais cela est très ennuyeux si votre application web met plus de 5 minutes à commencer de renvoyer un résultat : vous avez un timeout.
Je suis vraiment surpris qu'un tel changement de comportement puisse être introduit comme cela.
Il ne me reste plus que trois solutions :
* demander à mes utilisateurs d'utiliser un autre navigateur
* leur demander de bidouiller le timeout dans leur about:config
* revoir dans l'urgence l'architecture de mon appli !
# Quel est le problème ?
Posté par Victor . Évalué à 10.
Je comprend pas ton problème : ton appli met 5mn à renvoyer un résultat ?
C'était quoi le comportement que ton navigateur avait avant dans ce contexte ?
[^] # Re: Quel est le problème ?
Posté par Xavier Poinsard . Évalué à 4.
Avant Firefox (et les autres navigateurs) attendaient gentiment la réponse.
[^] # Re: Quel est le problème ?
Posté par Space_e_man (site web personnel) . Évalué à 10.
Et les utilisateurs, c'était quoi leur comportement ?
[^] # Re: Quel est le problème ?
Posté par mickabouille . Évalué à 10.
Ils appuyaient 3 fois sur "recharger" puis ils allaient voir ailleurs.
[^] # Re: Quel est le problème ?
Posté par reynum (site web personnel) . Évalué à 3.
Comme tout le monde :-D
kentoc'h mervel eget bezan saotred
# Je suis curieux
Posté par Atem18 (site web personnel) . Évalué à 10.
J'aimerais beaucoup savoir dans quelles conditions, une personne doit attendre 5 minutes avant d'obtenir le résultat de sa requete HTTP.
[^] # Re: Je suis curieux
Posté par Xavier Poinsard . Évalué à 0.
Quand il y a des traitements sur des données volumineuses.
[^] # Re: Je suis curieux
Posté par zebra3 . Évalué à 10.
Dans ce cas-là, je me demande si une appli web est vraiment l'idéal…
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Je suis curieux
Posté par barmic . Évalué à 8.
Pourquoi pas ? Faut juste qu'elle fasse le traitement de manière asynchrone.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Je suis curieux
Posté par zebra3 . Évalué à 10.
Ben si l'utilisateur doit rester cinq minutes avec son navigateur qui mouline, je ne suis pas sûr qu'elle soit asynchrone.
Que se passe-t-il s'il y a coupure, voire une fausse manip comme un appui sur Escape ? Le traitement reprend-il de zéro ? Les données sont-elles cohérentes ?
Bref, à mon avis une appli qui mouline cinq minutes sans aucun retour utilisateur, c'est pourri.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Je suis curieux
Posté par devnewton 🍺 (site web personnel) . Évalué à 9.
Pour une appli grand public. Pour un service interne dans une entreprise, ça peut répondre à 100% au besoin et aux impératifs de coûts.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Je suis curieux
Posté par zebra3 . Évalué à 10. Dernière modification le 13 mai 2014 à 12:15.
Ouais enfin que ça soit une application entreprise ne justifie pas une ergonomie propice aux erreurs et à l'absence de contrôle, bien au contraire.
Ça sent plutôt l'appli faite à la Rache : ça rend bien service dans un premier temps, mais si elle devient critique faut la maintenir.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Je suis curieux
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Sauf que le temps ou le budget qu'on alloue à la maintenance d'une appli ne prends généralement pas en compte mozilla a décidé d'ajouter un timeout sans réfléchir comme ça pour faire chier.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Je suis curieux
Posté par Thomas Douillard . Évalué à 5.
En même temps se baser sur un comportement très probablement non spécifié et qui consiste à rajouter un timeout relativement long pour une appli, et non garanti, c'est le genre de truc qui arrive que ça casse. (oui, le français de cette phrase est déplorable).
[^] # Re: Je suis curieux
Posté par barmic . Évalué à 4.
Ils ont aussi retiré la balise
<blink>il y a quelques temps. Dans les 2 cas ils agissent pour les utilisateurs (combien de temps le budget n'aurait pas était alloué à ça sinon ?).Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Je suis curieux
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Ce n'est pas un changement du même ordre: sans la balise blink, la page reste utilisable.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Je suis curieux
Posté par barmic . Évalué à 8.
Parce qu'une page qui met 5 minutes à charger c'est utilisable ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Je suis curieux
Posté par devnewton 🍺 (site web personnel) . Évalué à 1.
Oui, cf https://linuxfr.org/nodes/102162/comments/1537308
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Je suis curieux
Posté par barmic . Évalué à 9.
Ça ne coûte pas plus chère de faire les choses bien. D'une part ça n'est pas aussi compliqué que ce que certains ont l'aire de croire (le nombre de solutions clef en main pour faire ça a explosé et on pouvait déjà le faire facilement avant), mais tu ne prend pas en compte le coût des utilisateurs qui s'énervent, qui ne font plus confiance à leur DSI (ça devient rapidement un running gag ce genre de comportement), les utilisateurs qu'il faut formé et il faut répéter inlassablement les même consignes,… En gardant ce genre de chose tu nuis à la productivité de l'entreprise, Mozilla t'a donné un argument pour qu'enfin tes chefs veuillent bien corriger ce bug.
Si vraiment il faut perdurer dans ce genre de choses, tu met une page qui explique comment configurer le navigateur avant de faire le traitement, mais j'ai du mal à comprendre comment on peut se complaire dans ce genre de comportement. Tout le monde hurle quand firefox a de microfreeze dans sont interface de temps en temps, là c'est bien plus grave.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Je suis curieux
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Tu penses trop web = site.
Parfois on utilise le "web" pour renvoyer le résultat d'un lourd calcul sans se prendre la tête à développer une gui complexe.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Je suis curieux
Posté par barmic . Évalué à 5.
Que ce soit un site, un webservice ou je ne sais quel terme plus ou moins fumeux (webapp, cloud je ne sais quoi), ça ne change rien là il est question de bouffer de la connexion comme si on était des saoudiens en 4x4 en ville. Tu dirais que des fois faire durée 15 minutes une transaction dans une base de données sans rien en faire, ben ça peut être bien utile et que le moteur qui te plante ta tx c'est pas normal ?
Et ça interdit de faire une requête pour lancer le calcul et de l'avoir à disposition après ? C'est une gui complexe d'avoir une page qui dis que traitement est en cours et qui se recharge toutes les x seconde jusqu'à ce qu'un fichier soit créé ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Je suis curieux
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Non, mais ça demande un espace de stockage (base, cache, fichier…), donc un développement/déploiement/conf supplémentaire.
Attention, je ne dis pas que c'est une bonne pratique de faire des requêtes de 5min comme ça dans l'absolu, juste que ça peut répondre au tu peux me faire un export croisé pour hier sans faute accessible à tous en temps caché?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Je suis curieux
Posté par papatte3 . Évalué à -2.
BO et probablement la plupart des ses concurrents font ça en asynchrone sans que le développeur ait quoi que ce soit à faire de particulier.
Si tu n'as pas BO, tu exécutes la requête en batch et tu affiches le résultat.
[^] # Re: Je suis curieux
Posté par zebra3 . Évalué à 6. Dernière modification le 14 mai 2014 à 09:12.
Euh chez moi on appelle ça des tests.
L'application est validée sur une ou plusieurs versions d'un navigateur.
Puis une nouvelle version d'un navigateur = un test. Si ça ne marche pas, la nouvelle version du navigateur n'est pas déployée.
Ça me paraît pourtant simple, surtout en restant en ESR qui est fait pour ça.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Je suis curieux
Posté par Laurent Cligny (site web personnel) . Évalué à 6.
On parle d'une appli web interne en entreprise. Un peu de sérieux voyons…
[^] # Re: Je suis curieux
Posté par zebra3 . Évalué à 7.
Oui, donc on parle bien d'une appli développée à la Rache. Je n'ai rien contre ça, mais il faut assumer et ne pas reprocher nos choix à Mozilla.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Je suis curieux
Posté par Laurent Cligny (site web personnel) . Évalué à 5.
Tout à fait, surtout que j'ai le même cas chez nous (attente du retour de la requête pendant 5h :D). Nous sommes même passés de IE (qui a un timeout d'1h) à firefox pour cette raison il y a quelques temps. Je considère ce timeout comme un bien, ça va me donner un argument de poids pour consacrer un peu de temps à modifier cette appli.
[^] # Re: Je suis curieux
Posté par barmic . Évalué à 10.
C'est ce que je voulais dire. Il n'y a pas de problème a faire du web faut juste garder en tête qu'une page qui s'ouvre en plus d'une seconde (des fois on met la limite bien plus bas) c'est un bug et qu'il faut faire un batch. Ça n'a aucun rapport avec le web, c'est comme si on bloque l'interface native avec un traitement long. Personne n'accepterait que vlc bloque totalement son interface parce qu'il choisi de faire l'encodage dans le même thread que la boucle d'attente de Qt.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Je suis curieux
Posté par Sébastien Maccagnoni (site web personnel) . Évalué à 2. Dernière modification le 13 mai 2014 à 10:40.
Salut,
Le serveur ne peut-il pas commencer à envoyer sa réponse avant la fin du traitement, au fur et à mesure ?
Ça résoudrait le problème de timeout et tes utilisateurs verraient plus rapidement un résultat…
[^] # Re: Je suis curieux
Posté par claudex . Évalué à 7.
Ça ne marche pas si on veut faire un tri ou une sélection sur les données (genre parser les logs pour afficher les 20 requêtes les plus longues par ordre décroissant).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Je suis curieux
Posté par barmic . Évalué à 4.
En répétant inlassablement l'analyse sur des données déjà traitées et ne jamais créer le moindre index.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Je suis curieux
Posté par pas_moi . Évalué à 1.
tout à fait : http://fr.wikipedia.org/wiki/Chunked_transfer_encoding
[^] # Re: Je suis curieux
Posté par freem . Évalué à 1.
Imaginons une requête SQL particulièrement complexe ou sur une quantité de données particulièrement impressionnante.
Compte tenu du fait que ce n'est pas progressif, comment tu fais pour envoyer les résultats progressivement?
Enfin bon, à mon très humble avis, un site qui mets 5 minutes à renvoyer un résultat, il y a peu de personnes qui vont y rester.
[^] # Re: Je suis curieux
Posté par Xavier Poinsard . Évalué à 3.
On parle d'une application web.
[^] # Re: Je suis curieux
Posté par gnumdk (site web personnel) . Évalué à 5.
Une application web, c'est en entreprise, si l'admin peut pas envoyer la conf firefox avec le bon timeout, c'est qu'il faut changer d'admin…
[^] # Re: Je suis curieux
Posté par barmic . Évalué à 6.
Une appli web ou un site c'est kiff kiff. Si je requête quelques milliers de fois cette page je DOS le serveur ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Je suis curieux
Posté par beleys (site web personnel) . Évalué à 2.
le kif kif, je ne suis pas réellement d'accord.
Une appli et un site, ce n'est pas les mêmes problématiques ni les mêmes principes.
Le seul point commun c'est que les deux utilisent un navigateur pour son IHM.
Après pour la suite, c'est deux domaines différents. Les ergonomies sont différentes, les niveaux d'acceptation aussi. Pour une appli, une fois celle-ci choisie, l'utilisateur n'a plus qu'à la subir et n'a pas réellement le choix de pouvoir en changer (c'est rarement de son ressort) …
S'il doit attendre 5 min sur un traitement … il attendra et on trouvera, au pire, un moyen de le contraindre à attendre (par la formation si on ne trouve pas de contraintes techniques).
Pour ce qui est des attaques DDOS, j'avoue que c'est surement possible … mais comme tout plein d'autres applis ou la sécurité première est de ne pas "sortir" du réseau local … cela ne solutionne pas tout .. c'est une sécurité ridicule … mais cela évite déjà pas mal d'ennui.
[^] # Re: Je suis curieux
Posté par barmic . Évalué à 10.
Sincèrement ? Vous en êtes à dire « j'en ai rien à foutre de faire de la merde de toute manière l'utilisateur n'a pas son mot à dire » ?
Ça donne envie de remercier Mozilla pour le coup.
Par contre du coup http://www.service-public.fr/ c'est une appli ou un site avec ta définition que tu t'es inventé ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Je suis curieux
Posté par beleys (site web personnel) . Évalué à 3. Dernière modification le 13 mai 2014 à 16:58.
C'est moche … mais c'est sur un nombre très limité de fonctionnalités où les contraintes temps de développement disponible, nombres d'utilisateurs font qu'il est plus rentable de livrer en mode "il faut faire avec" qu'autrement.
De manière générale, nous ne sommes pas dans le mode "rien à foutre, pas de le choix" .. mais des fois … si !!
Et à mon avis, nous ne sommes pas les seuls à fonctionner ainsi …
Pour toutes nos fonctionnalités, selon le type d'utilisateurs, tous n'ont pas la même priorité …
[^] # Re: Je suis curieux
Posté par barmic . Évalué à 3.
Je ne dis pas que des problèmes ne peuvent pas arriver. Faire du logiciel de qualité c'est chère et la critique est très facile, non ce qui m'a gêné c'est la manière d'argumenter (« de toute façon c'est une webapp, les utilisateurs n'ont pas le choix, OSEF »). Ça m'est arrivé et ça m'arrivera de ne pas être fier de ce que je produit, mais je préfère éviter les explications jemenfoutistes.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Je suis curieux
Posté par freem . Évalué à 2. Dernière modification le 13 mai 2014 à 14:33.
Ils utilisent tous les deux habituellement les mêmes langages également. HTML+CSS, JS, SQL ( à moins qu'il n'y ait pas de base de données derrière ? ) et [PHP|python|perl|autre].
Ils ont aussi en commun le fait de devoir faire des workaround à cause des différences entre les navigateurs, ou de choisir de n'en supporter qu'un seul.
Au final, même après ton explication, je ne vois pas où est la différence entre un site web ( qui peut être interne ou pas ) et une application web ( même chose ). Que ça mette 5 minutes à réagir, pourquoi pas, mais bon, au final moi quand j'attend 5 minutes après mon PC, déjà je peste, et en plus je me demande: "planté ou pas planté?" avec CTRL+ALT+SUP qui me démange ( enfin, pas tout à fait cette combinaison, mais l'idée est là ).
Je doute que tes utilisateurs ne ressentent pas la même chose, et un utilisateur content est un utilisateur qui cherchera ( et trouveras ) moins de moyens de contourner les procédures établies ( pour de bonnes ou de mauvaises raisons, peu importe ).
Sinon, je me rappelle d'un prof qui disait que la sécurité informatique, c'est pas juste la résistance aux attaques. Son point se défendait en se disant qu'une panne, c'est pas une attaque, idem pour un comportement accidentel de l'utilisateur ( ou d'un admin, une boucle dans un script est si vite arrivée… )
Et pour le coup, la petite image :)
[^] # Re: Je suis curieux
Posté par Zarmakuizz (site web personnel) . Évalué à 4.
Tu peux très bien avoir une page de transition "Le traitement risque d'être long, vous pouvez aller prendre un café" qui arrive immédiatement, et dès que le serveur envoie en ajax "j'ai fini", il y a une redirection automatique. Un poil embêtant pour rester compatible avec des IE un peu vieux, mais faisable.
Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/
[^] # Re: Je suis curieux
Posté par windu.2b . Évalué à 3.
Pourquoi faire une redirection ? Le but d'Ajax, c'est justement de se passer de changement de page…
Donc dans ton exemple, il suffit tout simplement de masquer la div qui contient le message "Le traitement risque d'être long, vous pouvez aller prendre un café" lorsque le traitement Ajax est terminé.
[^] # Re: Je suis curieux
Posté par Zarmakuizz (site web personnel) . Évalué à 3.
La redirection permet par exemple de rediriger l'utilisateur sur une URL qui pointera sur le résultat de la requête, que celle-ci ait été exécutée maintenant ou il y a deux semaine.
Tu as raison, il est aussi possible d'afficher les résultats au sein de la page elle-même, voire de modifier l'URL affichée dans le navigateur tout en montrant les résultats obtenus.
Différentes façons sont possibles, je ne connais pas le besoin initial. Je pensais que récupérer en Ajax un simple "va là" était le moyen le plus rapide et ayant besoin du moins de javascript possible (pour ne pas trop s'épuiser avec les bizarreries d'IE, quand les daicidors ne comprennent pas qu'on veuille refaire une partie du traitement serveur sur le client, ou simplement que stocker un millier de données dans un tableau javascript avec seulement 2 Go de Ram pour toute la machine n'est pas tip-top, limiter le javascript a encore un intérêt). Dans tous les cas, plusieurs moyens assez simples à partir de simplement informer l'employé que, ce traitement étant long, il peut aller courir 5 minutes pendant ce temps.
Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/
[^] # détente
Posté par AgentSteel (site web personnel) . Évalué à 4.
Ou un petit Tetris ou Pacman en HTML5/JS/CSS, le temps que la requête se termine!
Un peu comme chez talky.io et le coup de la fusée :)
[^] # Re: Je suis curieux
Posté par Sygne (site web personnel) . Évalué à 10.
C'est un défaut bien connu d'Ipot, qui fait que les requêtes reçues du futur arrivent encore légèrement dans le futur: Plus la requête vient de loin, plus le décalage avec le présent est important.
[^] # Re: Je suis curieux
Posté par Sébastien Le Ray . Évalué à 4.
C'est une technique qui est parfois utilisée en développement Web lorsque l'interface doit se mettre à jour selon des événements, tu as une réponse Ajax qui n'arrive qu'en cas d'événement ça fait de l'attente passive, plus réactif que du polling (sauf si on déplace le polling côté serveur :-) )
[^] # Re: Je suis curieux
Posté par Le Pnume . Évalué à 6.
C'est vrai que 5 min c'est vraiment long mais par exemple j'ai des scripts R utilisant "shiny server"(serveur d'application R qui permet de générer des interfaces web pour des scripts R)qui peuvent mettre plusieurs minutes à répondre selon la taille du jeux de données à récupérer (via JDBC) puis à traiter.
[^] # Re: Je suis curieux
Posté par barmic . Évalué à 3.
Est-ce vraiment fait pour de la prod ? Est-ce qu'il ne transmet aucune donnée pendant ce temps ? Est-ce qu'il ne devrait pas lui aussi revoir son intégration et séparer la partie présentation du moteur de calcul ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Je suis curieux
Posté par Le Pnume . Évalué à 4. Dernière modification le 13 mai 2014 à 17:07.
Est ce que c'est optimal, c'est sur que non. Est ce que ça pourrait être amélioré bien sur ! Mais j'ai décrit une situation extrême, dans la quasi totalité des conditions d'utilisation (c'est pas souvent qu'on demande un traitement sur 10 ans de données avec une donnée par 1/4 d'heures sur 20 sites de mesures), les temps de réponse sont de quelques dizaines de secondes et comme mon boulot consiste plus à traiter ces données (et là j'utilise R directement) qu'à mettre à disposition de mes collègues un moyen de réaliser des traitements courants sans avoir à apprendre R, la situation actuelle convient à tout le monde. Facilité et rapidité de développement avec Shiny pour moi au dépens des performances mais c'est en connaissance de cause et simplicité pour mes collègues.
[^] # Re: Je suis curieux
Posté par barmic . Évalué à 2.
Je ne parle pas particulièrement pour toi, mais pour Shiny. Ce serait bien qu'ils mettent en place une architecture moderne, c'est très positif pour l'experience utilisateur.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# revoir dans l'urgence l'architecture de mon appli !
Posté par PapsOu . Évalué à 7.
Bonjour, je pense en effet qu'il y a un problème au niveau conception.
As-tu tenté de passer par de l'ajax ? Genre :
- appel asynchrone (on attends pas la réponse) de la tâche coûteuse (en temps et/ou en ressources)
- polling ou autre qui se chargera de vérifier l'état de la tâche en cours / achevée et de rapatrier le résultat une fois la tâche terminée.
[^] # Re: revoir dans l'urgence l'architecture de mon appli !
Posté par Xavier Poinsard . Évalué à 1.
L'ajax ça n'existait pas au moment de la conception de l'appli !
[^] # Re: revoir dans l'urgence l'architecture de mon appli !
Posté par Anthony Jaguenaud . Évalué à 2.
Si l'accès à la base pose problème, il faut peut-être optimiser :
* Améliorer le serveur,
* Optimiser les requêtes.
Optimiser chez developpez, Optimiser ORACLE chez developpez, et Un pour MySql.
Je ne suis pas spécialiste, mais j'avais lu que sur des grosses bases, l'ordre d'une requète peut aider à passer du simple au triple.
[^] # Re: revoir dans l'urgence l'architecture de mon appli !
Posté par zebra3 . Évalué à 5.
C'est peut-être l'occasion de revoir un peu l'appli. Le premier draft officiel d'AJAX ne date que de 2006, après tout.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: revoir dans l'urgence l'architecture de mon appli !
Posté par CrEv (site web personnel) . Évalué à 3.
Oui mais ça veut pas dire grand chose.
XMLHttpRequest date de 1998 et l'implémentation dans firefox date de 2002 (2004 pour safari et 2005 pour opera).
Et même sans ça rien n'empêche d'avoir des traitements serveurs et du polling à base d'iframe (c'est peut-être crade mais c'est possible)
[^] # Re: revoir dans l'urgence l'architecture de mon appli !
Posté par barmic . Évalué à 3.
Tu peux même le faire de façon statique sans js, tu arrive sur une page « le traitement est en cours, on vous envoi un mail/sms quand ce sera fini (ou revenez dans 5 minutes) ».
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# La bonne réponse
Posté par barmic . Évalué à 10.
La bonne réponse est :
Les traitements longs devraient être fait en arrière plan. Tu peut très bien avoir un worker qui fait le boulot et qui notifie l'utilisateur quand il a terminé (par mail ou via l'interface web). Je pense :
Tu peux regarder une architecture relativement sophistiquée avec JQM (pour Java) (mais tu peux avoir pleins de chose, tu peut utiliser JMS en Java, 0MQ ailleurs,…).
Si tu veux des exemples de la vie réelle c'est ce que fait google dans drive et dans takeout quand tu veux télécharger des volumes un peu trop gros.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: La bonne réponse
Posté par Xavier Poinsard . Évalué à 4.
C'est dans les projets de revoir la conception de l'appli, mais là on est dans l'urgence avec des Firefox qui se mettent à jour tout seuls !
[^] # Re: La bonne réponse
Posté par claudex . Évalué à 10.
Il y a les version ESR pour éviter ce genre de surprise.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: La bonne réponse
Posté par beleys (site web personnel) . Évalué à 0.
en fait non, on y a cru aussi .. mais quand ta version ESR n'est plus maintenu … et que tu as laissé les mises à jour de sécurités d'activer … tu passes automatiquement en version maintenue.
Ce comportement est logique … mais gênant quand tu as repoussé plusieurs fois de prendre en compte que ton extension ne serait pas valide à l'ESR suivante par exemple :D
[^] # Re: La bonne réponse
Posté par zebra3 . Évalué à 6.
Ben quand ta version ESR n'est plus maintenue, tu mets à jour sur la dernière ESR. Où est le problème ?
C'est pareil que de mettre à jour à la dernière version, sauf qu'on le fait moins souvent et on est moins surpris par ce genre de changement.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: La bonne réponse
Posté par beleys (site web personnel) . Évalué à 2.
oui c'est logique … mais par exemple pour nous, nous avons construit une extension sur une fonctionnalité qui a été supprimé entre la 17 ESR et la 24 ESR …. et donc à partir de la 24 ESR, notre extension est out …
Après, nous savions que cela allait arrivée … ne fonctionnalité n'est pas supprimée du jour au lendemain … nous avions juste laissé filé le temps .. et nous avons perdu ^
[^] # Re: La bonne réponse
Posté par claudex . Évalué à 3.
En plus, tu as 3 mois entre la sortie de l'ESR suivante et la fin du support de la précédente.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: La bonne réponse
Posté par freem . Évalué à 6. Dernière modification le 13 mai 2014 à 11:42.
En parlant de configuration… ce n'est pas désactivable, la MaJ automatique? Et je pense que faire des MaJ automatiques en prod, c'est quand même pas terrible comme process de dev, non? ( enfin, sûrement pas pire que ce qui se fait dans ma boîte actuelle… on a même pas de dépôt de source, et je suis le seul à préferer git à cpold :/ ==> œil, paille, poutre, tout ça… )
[^] # Re: La bonne réponse
Posté par Xavier Poinsard . Évalué à 1.
On maîtrise le serveur, pas les postes clients.
[^] # Re: La bonne réponse
Posté par netchaiev . Évalué à 1.
A propos de la gestion des mise à jour firefox il y a truc que j'ai expérimenté qui marche bien.
Nous sommes en environnement Full Windows. (En environnement Serveur Linux un montage CIFS pourrait faire l'affaire et si les client sont aussi du linux cela peut être un peu plus tiré par les cheveux [wine, recompilation, FirefoxPortable Linux, …])
Le cas général :
1) Placement du dossier des exécutable sur un rep partagé
2) droit de lecture/exécution pour les utilisateurs potentiels.
3) Distribution du lien (icône) vers l'exécutable Firefox
4) Un fichier de conf bien calé pour gérer tous les paramétrages du navigateur
Avantages : tu es maitre de la situation
-> Si tu as des mises à jour sécurité à faire seul celui qui a les droits d'écriture sur le répertoire peut faire cela.
-> Pour les mises à jour majeures c'est le même topo (j'utilise un petit logiciel libre "unlocker" qui me permet de déverrouiller les fichiers ouverts me permettant de faire une copie de la nouvelle version préalablement testée.
-> Les données de conf des utilisateurs restent stockées sur leur poste
Inconvénient :
-> l'ouverture sur le réseau est un peu plus lente que si firefox était installé sur le poste
-> Si l'utilisateur a une version de firefox déjà installée sur son poste il peut avoir quelques problèmes pour gérer son profil.
Le cas particulier :
-> On reprend le même principe
-> j'ai fait un .bat qui permet d'ouvrir firefox sur un autre profil sur le poste client
-> le lien donné aux utilisateurs pointe vers ce .bat (qui a été compilé en exe)
Avantages :
-> on peut gérer plusieurs profils (donc aussi plusieurs versions de firefox), il n'y a donc plus aucun conflit entre des versions installées sur le poste client et celle utilisée depuis le réseau.
Au final, je distribue mon/mes appli(s) avec un client que je maitrise et l'utilisateur garde son navigateur préféré pour surfer [dans pas mal de cas j'ai aussi désactivé l'accès internet pour ces clients customisés]
[^] # Re: La bonne réponse
Posté par tyoup . Évalué à 2.
en gros un client lourd…
[^] # Re: La bonne réponse
Posté par netchaiev . Évalué à 1.
Exact mais plus simple à gérer que le "client lourd classique" puisque le "lourd" se résume à un navigateur web pré-configuré et localisé à un seul endroit. Avec cette configuration, je peux au moins me concentrer un peu plus sur l'appli sans les subtilités (oh combien emmerdantes et chronophages [je le sais par expériences …]) des gestions css, javascripts et autres incongruités rencontrés lorsque le parc navigateur est hétérogène.
Comme tout bricolage, cette solution a ses avantages et ses inconvénients …
```
[^] # Re: La bonne réponse
Posté par ckyl . Évalué à 3.
C'est une super idée ça. Comme ça on est bien sur que le code est crado et que le jour où il y a a le porter on est bien dans la merde et qu'il faut tout refaire.
En règle générale même si officiellement tu supportes une seule chose, côté dev tu fais tourner tes tests sur autant de plates-formes possible et tu designs pour que ça soit portable. Qu'on parle de navigateur, de DB ou autre le combat est le même. En général ça coûte moins cher de concevoir portable du début à la fin que de devoir porter au bout de 5 ans par ce qu'on a décidé de passer de X à Y ou de version N à N + 2. La politique et les choses supportées ça fini toujours par changer.
Au passage il faudra penser à sortir des années 2000, et arrêter avec un seul navigateur supporté, une seule plate-forme supportée etc. Ça va peut être faire mal aux développeurs d'applis internes moisies incapables de pondre des trucs correctement réalisés mais BOYD, qualité, choix du poste de travail tout ça tout ça.
[^] # Re: La bonne réponse
Posté par netchaiev . Évalué à 1.
Certes, certes …
Mais comme je l'ai dit auparavant la méthode a ses avantages et ses inconvénients . Le choix a été fait en connaissance de ces 2 points.
Je ne suis pas développeur à 100% j'ai aussi une autre vie d'informaticien ce choix est donc le choix de la raison
Je ne suis pas maso au point de reprendre l'intégrité d'un code fait il y a 5 ans .
Mais au moins je suis sereinement de l'évolution des versions Firefox et je peux mettre à jour régulièrement mon client "lourd" sans m'encombrer des éternelles questions autour du navigateur du poste client.
Je développe biensûr en pensant au plan B (IE & Chrome) mais l'optimisation (css en gros avec quelques subtilités js) est pour mon "Firefox Client lourd" pour les autres cela sera un mode dégradé.
[^] # Re: La bonne réponse
Posté par ʭ ☯ . Évalué à 2.
L'appli ne marchait déjà plus avec Chromium etc?
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: La bonne réponse
Posté par Xavier Poinsard . Évalué à 2.
Chromium n'implémente pas ce timeout.
[^] # Re: La bonne réponse
Posté par Maxime (site web personnel) . Évalué à 6. Dernière modification le 13 mai 2014 à 20:48.
Dans l'immédiat, ce n'est pas possible de faire en sorte que l'url qui faisait le traitement long fasse le boulot en background ?
Genre tu mets en place un worker qui dépile les trucs à faire et mets le résultat quelque part. Et ta page actuelle tu fais en sorte que son comportement soit :
Après, pour le mettre en place, ça dépend de l'appli…
# Bonne réponse
Posté par titi_pas_cool . Évalué à 1.
Pour ma part dans une entreprise, tous navigateurs (et version de navigateurs) doivent être validés par les autorités compétentes. Donc pour ma part, refaire l'appli en utilisant Ajax ou autres et interdire Firefox 29 le temps que ce problème soit résolu.
# Ah les mises à jour.
Posté par Layus . Évalué à 2.
C'est marrant, aujourd'hui je me suis pris la tête avec la nouvelle version de Chrome.
Comme ils ont décidé d'ignorer l'attribut autocomplete, les administrateurs qui utilisent notre interface (web) de configuration se retrouvent à soumettre leurs mots de passe admin dans les codes pin des utilisateurs.
Comme le dit très bien mon collègue : "Les application web, c'est toujours la m**** pour supporter tous les navigateurs" (fin de citation :-).
Dans ton cas, le transfert en blocs (Chunked transfer encoding) semble être une solution simple et facile.
Dans mon cas, il semble qu'il faille mettre des champs login et password invisibles en haut du formulaire pour leurrer la saisie automatique du mot de passe. Dire que cette technique est utilisée pour leurrer les bots…
VDM.
# ça existe pas
Posté par steph1978 . Évalué à 0.
ça existe pas une application qui met 5 minutes (300 secondes!) à répondre à un utilisateur web.
tout simplement parce que ça existe pas un utilisateur qui attend 300 secondes devant une page blanche.
et puis ça se change : network.http.pipelining.read-timeout
donc tu peux toujours expliquer à tes utilisateurs "mon application étant toute pourrie, merci de régler le timeout de votre navigateur à 30000 secondes".
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.