jcaron

http://www.php.net/manual/en/function.parse-str.php Jacques.

Tu as toujours une virgule de trop (ou alors l'exemple d'URL incorrecte que tu as donné au début n'est pas exact)... Jacques.

Pourquoi faire le "\,"? Et si tu utilises du rewrite par ailleurs, le [L] c'est pas un trop bonne idée, à moins de mettre un R=301 (qui serait probablement une bonne idée). Evidemment le "ça ne fonctionne pas", ça manque aussi un peu de détails... Jacques.

Un exemple, une URL? Jacques.

A moins que tu n'utilises une option php qui est fortement déconseillée, les variables de ton formulaire sont dans $_POST['nom_du_champ'], pas dans $nom_du_champ... Jacques.

Euh non... Si tu modifies juste le "A" de ton www pour le faire pointer sur le nouveau serveur, la zone DNS va continuer à être gérée au même endroit (dans le manager OVH). Si tu veux que la zone soit sur ton serveur, il faut modifier les NS (un NS qui pointe sur ton serveur, où tu aurais un named qui tourne et configuré pour répondre pour la zone en question, et le deuxième NS qui pointe probablement sur un secondaire OVH qui doit être configuré pour). Jacques.

Par contre je ne crois pas que passer '' soit très standard SQL, je conseillerais plutôt d'utiliser "default", ou de ne pas inclure la colonne dans la liste des colonnes. Jacques.

Dans le cas emerge, il dit que le fichier ebuild de imagemagick dit qu'il veut la version 2 de EAPI, alors que la version de emerge installée ne supporte que EAPI 1. Il faut donc commencer par upgrader emerge. Dans le cas de la compilation directe, je sèche un peu, parce que configure arrive bien à trouver et à tester (donc utiliser) libX11. Bizarrement il pense qu'il faut utiliser /usr/lib, mais à la compilation ça gueule que c'est dans lib64, mais peut-être que c'est le même endroit? Je n'ai pas de machine Linux 64 bits sous la main, donc je ne sais pas trop. Si tu n'as pas besoin de X11, tu peux essayer avec un petit ./configure --with-x=no puis make clean ; make install pour voir si ça passe mieux. Jacques.

Mon petit doigt me dit que c'est un problème de mélange 32/64 bits quelque part, mais je ne sais pas comment ça marche tout ça sous Linux (je suis plutôt FreeBSD...). Il y a une discussion ici: http://forum.ovh.com/archive/index.php/t-35412.html avec des gens qui ont eu le même problème, et a priori une solution (même si j'ai un gros doute que la solution soit la bonne pour une machine 64 bits, bien au contraire). Tu as le log complet de ce que racontent configure et make? (à mettre en ligne quelque part plutôt qu'à poster ici, ça doit être un peu long). Peut-être que si Dan passe par là il pourra t'aider plus... Jacques.

Que disent: ls -l /usr/lib64/libX11.so et: file -L /usr/lib64/libX11.so ? Jacques.

Et il te dit quoi quand tu fais ces manips? Ou alors tu as quoi comme erreur par la suite? Parce que là, "ça ne marche pas", ça ne nous avance quand même pas beaucoup dans la moindre direction. C'est un peu comme dire "je suis monté dans ma voiture et je ne suis pas arrivé à Marseille, une idée?". Jacques.

Très variable suivant ce que tu vends... Certains ont des taux de conversion inférieurs à 1%, d'autres peuvent dépasser les 10%. C'est évidemment plus facile si tu vends un produit pas cher, disponible immédiatement, et que tu es le seul à le vendre, que si tu vends quelque chose de très très cher et qu'il y a beaucoup de concurrence. Jacques.

Les noms, prénoms, numéro de téléphone, etc, pas de problème. Le numéro de sécu, j'aimerais bien savoir quelle justification tu as pour ça, parce que sans autorisation explicite de la CNIL, ça me paraît extrêmement risqué de demander ce genre d'info! Jacques.

La meilleure solution est probablement que les informations en question soient passées à Paypal, puis que Paypal te les transmette (uniquement si le client a payé, donc). Tu peux passer l'adresse de livraison, la description, la quantité et la référence des objets commandés, une "note", etc. Jacques.

Ce n'est pas vraiment une réécriture, mais plutôt une redirection (même si tu peux le faire avec mod_rewrite). Ca devrait le faire avec ça: RedirectMatch ^(/..*)$ http://destination$1 Sinon avec mod_rewrite quelque chose comme ça: RewriteRule ^(..*)$ http://destination$1 [R] Je n'ai testé ni l'un ni l'autre. Ca renvoie tout ce qui a un URL avec au moins un caractère après le http://domaine/. Evidemment ça suppose que ta page racine ne contienne aucun fichier externe (image, CSS, JS...) hébergé sur le même domaine. Sinon il va falloir trouver quelque chose d'un tantinet plus discriminant (tout dépend du format des URLS à rediriger). Jacques.

Mets les utf8_decode autour de $nom et $prenom directement dans la ligne où tu composes le "From". Note que même si ça marche dans ton cas particulier, ce n'est pas la "bonne vraie méthode qui marche à tous les coups". La bonne méthode est bien d'utiliser des encoded words (normalement mb_encode_mimeheader mais les commentaires laissent penser que la fonction est bugguée). Jacques.

...dont il est utile de préciser que si ce qui tu lui fournis n'est pas très strictement vérifié et contrôlé, tu ouvres un énoooooorme trou de sécurité. En plus de ça, l'exécution d'un eval prend nettement plus de temps que le même code sans eval. Vu que le test va très vraisemblablement être dans une boucle pour un tri, c'est à proscrire... Jacques.

Plein de possibilités if (($ordre == 'croissant' && $var1 > $var2) || ($ordre == decroissant' && $var1 < $var2)) if (($ordre == 'croissant')?($var1 > $var2)$var1 < $var2)) if ((($ordre == 'croissant')?1:-1)*($var2-$var1)) > 0) (il est possible que le dernier soit à l'envers, j'ai la flemme d'y réfléchir plus que ça) Et probablement beaucoup d'autres... Jacques.

Aouch. C'est une page générée par Office telle quelle, ou tu as fais du copier-coller de code venant de plusieurs endroits? C'est un sale mélange de HTML et de XHTML (et des bouts qui ne sont conformes ni en HTML ni en XHTML), plus du VML et je ne sais quelles autres choses bizarres... Je pense qu'il faudrait que tu trouves un autre outil pour générer des pages HTML si tu veux obtenir un bon résultat. Jacques.

Les headers doivent normalement être transmis entièrement en 7 bits (pour des raisons historiques), et donc "tout ce qui dépasse" doit être encodé en base-64 ou quoted-printable. Plus de détails ici: http://fr.wikipedia.org/wiki/Multipurpose_Internet_Mail_Extensions#Mots_encod.C3.A9s Jacques.

En effet, ce que tu reçois montre que c'est de l'UTF-8 interprété comme de l'ISO-8859-1. Ajoute un header Content-Type: text/plain; charset=UTF-8 (ou text/html si c'est du HTML, mais je ne crois pas que ce soit le cas), et ça devrait fonctionner correctement. Jacques.

La doc n'est pas très explicite sur la validation effectuée, et les notes semblent indiquer qu'il s'agit juste d'une regexp (j'ai la flemme d'aller vérifier), alors que la version Zend vérifie le MX et tout ça. Jacques.

La latence augmente avec la distance, puisque les informations sont transmises au mieux à la vitesse de la lumière (c=3.10^8 m/s dans le vide, environ 2.10^8 m/s dans de la fibre). Donc tu ajoutes environ 1 ms (aller simple) tous les 200 km, et 1 ms (A/R, comme dans un ping) tous les 100 km. Là dessus, il faut ajouter le fait que les fibres font des détours par rapport au chemin de le plus court entre les deux extrémités de ton ping, plus la latence introduite par le passage dans les équipements (switches, routeurs...). Paris-New York = 5847 km, donc ça devrait faire environ 60 ms de latence supplémentaire, mais en fait ça fait un bon 80. En gros, depuis l'Europe: - côte Est des US: 80-100 ms - côte Ouest: 150-170 ms - Ouest de la Russie: 50 ms Pour l'Asie la varie plus parce qu'il y a plusieurs chemins possibles (directement Europe->Asie via les SEA-ME-WE, ou plus fréquemment via les US et des câbles transpacifique), et encore plus pour l'Australie, les chemins étant très divers (via les US et Southern Cross, via les US puis HK ou Singapour, via SEA-ME-WE puis Singapour...). Le pire est l'Australie et la Nouvelle-Zélande, il faut compter 320 ms au bas mot, souvent nettement plus. Tout ça c'est hors latence terminale (sur la connexion de l'abonné). Et à ça il faut rajouter la latence induite par la congestion sur certains liens (en particulier vers l'Asie et l'Australie/Nouvelle-Zélande, mais aussi sur certains liens vers les US ou à l'intérieur des US), qui peuvent ajouter beaucoup plus de latence (des centaines voire des milliers de ms dans les pires cas). Et je ne parle pas de la latence induite par les liens satellites (environ 240 ms par satellite), heureusement plus rares de nos jours dans les pays civilisés, mais bon ça existe encore. Maintenant, la latence peut avoir plus ou moins d'effet sur ton application. Pour un site web classique, il y a pas mal de choses à faire pour optimiser ça: - réduire le nombre de fichiers nécessaires pour afficher une page, par exemple en consolidant tous les CSS en un seul fichier (et idem pour les JS) et en utilisant des "sprites" pour les images - s'assurer que le Keep-Alive http est actif et bien utilisé Pour du téléchargement, la latence influe sur le débit (en gros débit max = taille de la fenêtre TCP / latence). Pour optimiser ça, il faut adapter la taille des fenêtres TCP. Pour des applications hautement interactives (jeux en ligne, telnet, ssh, vnc...) pas de miracle, il faut réduire la latence en rapprochant les serveurs des clients et en évitant les liens encombrés. Ceci dit, s'il s'agit de jeux et qu'un gars en Australie peut jouer avec/contre un gars à Paris, quoi qu'il arrive, il va y avoir de la latence pour que l'action de l'un arrive chez l'autre, puisque tu déplaces la latence du lien client-serveur au lien serveur-serveur (et que tu risques de rajouter un petit détour supplémentaire en prime). C'est là que ça peut être intéressant de mesurer avant de signer avec ton hébergeur la latence entre tes différents sites, pour certains endroits comme l'Australie ça peut varier assez significativement (mais il faudrait aussi mesurer la latence de son site vers les clients finaux, ce qui est plus difficile à faire tant que tu n'as pas la main sur une machine sur place - note qu'il y a pas mal d'hébergeurs en Australie qui sont "du mauvais côté", sur la côte Ouest où il n'y a personne...). Pour ce qui te concerne plus précisément: - pour la Russie je ne pense pas qu'il soit indispensable de se rapprocher tant que ça, si? - pour la Chine j'éviterais probablement un serveur en Chine même. Ceci dit tu as vraiment des clients là-bas? Vise plutôt un hébergement à Hong Kong par exemple. - pour les US tu devrais avoir l'embarras du choix Si tu nous disais un peu les specs que tu veux ça pourrait aider à faire le tri. Dans certains pays tu risques d'avoir pas mal de choix en mutualisé à deux balles ou en colo, le segment dédié est bizarrement sous-représenté dans pas mal d'endroits, ou alors à des prix sans commune mesure avec ceux auxquels nous sommes habitués par ici, et avec beaucoup moins de "features". Tu peux aussi regarder du côte des serveurs plus ou moins virtuels, comme les offres d'Amazon (EC2), mais ils ne sont dispo qu'aux US et en Europe malheureusement. Jacques.

C'est une loterie (espérance de gain, participation financière, hasard). Monopole de la FDJ pour le moment, soumis à autorisation de l'ARJEL quand la nouvelle loi sera en vigueur. Jacques.

Tu parles d'un header, ou d'un paramètre dans l'URL? Dans un cas comme dans l'autre, tu peux faire des choses avec mod_rewrite (RewriteCond, RewriteRule...). Sinon comme tu utilises mod_proxy il y a peut-être quelque chose de ce côté-là aussi. Jacques.