Kioob

Ou directement strtr() dans ce cas.

Dans ce qu'on te propose, le raid hardware est plutôt un bon point. Mais le P4 mono coeur, c'est tout vieux, tout lent, ça pue. Et rien que pour le fait de chercher à induire le client en erreur avec son "double coeur logique", j'éviterais cette société à qui on est sensé confier ses sites. Pour ce qui est du tarif, difficile à dire l'infogérance pouvant inclure tellement de chose. Pour la consommation de BP chez OVH c'est malheureusement vrai, et aussi sur le haut de gamme : comme l'a dit Dan au dessus de 100Mbps par client et selon l'offre souscrite, tu peux te faire brider à 10Mbps par machine. Dans tous les cas, ça reste bien au dessus de ta consommation. J'ai eu un client qui consommait plusieurs centaines de Mbits pour son site (pas de streaming du tout d'ailleurs, ni autre download), et qui a du souscrire à l'option "SLA Business VIP". Ce qui est dommage c'est que pour le moment ils ne préviennent pas, ils "brident" et attendent que le client vienne se plaindre. A coté de ça j'ai des clients en Kimsufi (SLA Standard donc) qui n'ont aucun soucis. Coté retours hardware chez OVH, pour ma part j'ai eu de très mauvaises expériences mais je trouve qu'ils ont fortement amélioré ça depuis quelques années. Les machines ne chauffent plus, les coupures réseau sont rares, et le temps d'intervention est court. Et honnêtement, ça fait bien 2 ans que je n'ai pas eu le moindre soucis hardware que ce soit chez OVH, Sivit ou MailClub. Pour le choix de la machine, je laisserais faire Dan. De mon avis, n'importe quelle machine à partir du SP BestOF devrait faire l'affaire dès lors que la configuration suive derrière et que les scripts soient bien fait... Maintenant un forum codé avec les pieds sera lent sur n'importe quel serveur, même un HG Large (j'ai eu le cas ce matin). Le choix de Dan me semble donc plus prudent

Ca repart pas forcément du premier coup. Par exemple avec du RAID soft, OVH utilise du RAID 0 pour le swap si bien qu'en cas de crash d'un disque la machine est HS jusqu'à l'intervention d'un technicien... mais tu ne perds aucune données. Perso je fais sauter ça et mets le swap sur du RAID 1, c'est effectivement plus lent mais au moins j'évite ce genre de soucis (et puis le swap n'est pas vraiment sensé servir sur un serveur).

Arf désolé... Donc dans un fichier .htaccess à la racine de ton site, place ça : ServerSignature off Par contre tu n'as pas accès à la directive ServerTokens en mutualisé. Et pour information il s'agit de la configuration d'Apache (le serveur HTTP), ça n'est absolument pas lié à PHP.

Hello, avec Apache 2 il s'agit de la directive "ServerTokens" que tu peux mettre à "Prod" pour réduire au minimum ce genre d'info (ainsi que "ServerSignature à Off" dans l'élan). Si j'ai bonne mémoire ces directives existaient déjà avec Apache 1, à tenter. PS : mais cela ne t'empêche pas de complètement personnaliser ces pages d'erreurs non plus.

Chaque serveur a son propre "réglage", surtout que cela dépend en grande partie de tes données. A la limite je conseillerais MySQLTuner, qui tente de régler ça de manière automatisée (c'est évidement moins bien qu'une vraie configuration, mais toujours mieux que ce qu'on trouve à l'installation). Sinon même conseil que Dan : il y a quelques infos intéressantes dans les fichiers de conf fournis en exemple par MySQL (sous Debian c'est stocké dans /usr/share/doc/mysql-server-5.0/examples ).

$_SERVER ["HTTP_IF_MODIFIED_SINCE"] : si le navigateur l'envoi, il devrait être présent (à vérifier avec Live HTTP Headers sous Firefox). S'il n'est pas envoyé, c'est probablement à cause d'entêtes Cache-Control ou Pragma qui ne correspondent pas... tu utilises les sessions sur la page en question ? 404 / compression : les serveurs Web gèrent parfaitement la compression à la volée, c'est d'ailleurs probablement déjà activé pour tes fichiers CSS et JS non ? 304 : oui, il suffit d'ajouter un "IF" : // A cause d'un "bug" de PHP il faut désactiver la compression avant d'envoyer une réponse 304 ini_set('zlib.output_compression', false); if( substr(php_sapi_name(), 0, 3) === 'cgi' ) header('Status: 304 Not Modified'); else header('Not Modified', true, 304); exit;

Hello, j'arrive après la bataille désolé, mais j'ai du mal à voir ce que tu cherchais à faire en fait. A moins que tu ais stipulé le contraire dans ton script lors de ta connexion à MySQL, c'est bien de l'ISO que tu récupères. Euh non... "donc de l'html", que ce soit ISO XXXX ou UTF-8... Si tu cherchais juste à encoder en HTML tes accents "ISO", c'est htmlentities() qu'il te faut. Maintenant s'il s'agit d'accents Windows (cp1252), il faut le préciser à htmlentities(). Quant à l'UTF-8, il n'est pas nécessaire d'encoder les accents normalement, mais ça ne pose pas vraiment de soucis non plus.

Hello, pour le SMTP attention : de plus en plus de FAI bloquent le port SMTP par défaut (Orange et Free par exemple). La solution la plus sage à mon avis est d'opter pour la version SSL qui utilise un port différent (465).

Un GIF est forcément en 256 couleurs max, donc il sera compatible en PNG 256 couleurs max, ce qui est 100% compatible avec IE 5 et 6 (aucune idée pour IE 4). C'est la transparence sur les PNG 32bits qui pose problème sous IE 6... c'est tout.

Merci Arlette mais je ne suis pas certain que mes services collent non plus. Enfin quelques remarques : ponctuellement plus de 50 connections simultanées à MySQL Pour ma part je commencerais par corriger les requêtes SQL / le modèle de données si c'est fréquent. Coté prestataire, perso j'aime bien Sivit et je les trouve compétents. Ils ont l'avantage d'être assez nombreux, et peuvent donc couvrir une plage horaire plus large ainsi qu'avoir des personnes "pointues" dans plusieurs domaines. Maintenant je ne suis pas forcément objectif, je n'ai jamais utilisé leur prestation d'infogérance, et je ne connais pas non plus le service fourni par les autres prestataires. Maintenant avec un budget de 200 (HT / TTC ?) par mois chez Sivit en incluant les 100 d'infogérance, ça va pas être folichon coté serveur.

Hello, tu es certain que le register_globals est activé ? si ce n'est pas le cas $HTTP_IF_MODIFIED_SINCE sera toujours vide... De manière générale, active l'affichage des erreurs... ne serait ce que pour débugger, c'est essentiel : error_reporting( E_ALL | E_STRICT ); Et essayes de te passer de register_globals : $_SERVER['HTTP_IF_MODIFIED_SINCE']. Sinon, si j'ai bonne mémoire je t'avais déjà conseillé de remplacer ob_start('ob_gzhandler') par un ini_set('zlib.output_compression', true) qui consomme moins de mémoire et induit moins de "latence" dans l'envoi de la page. === Sinon pendant qu'on y est : *) une autre solution serait de rediriger uniquement les 404 vers ton script PHP. Ainsi Apache/Lighty/NginX/autre gèrerait la mise en cache de son coté, de manière plus fiable et plus rapide qu'un script PHP. *) dans ton script actuel, pourquoi faire un "readfile()" du contenu que tu viens d'écrire, et pas simplement un echo ? *) le code correspondant à la compression du contenu est commun aux deux cas de ton if, donc pourquoi ne pas le sortir du if justement ? Ca t'éviterait la duplication de code. *) le code header("HTTP/1.0 304 Not Modified"); n'est pas compatible avec un PHP en (fast)CGI.

Hello, les règles de "choix de version" dépendent uniquement de ton hébergeur ; donc soit tu nous indiques de quel hébergeur il s'agit soit tu le contactes directement pour savoir.

Ce disque a effectivement des performances énormes (lecture comme écriture), et peut être vraiment source d'un gros gain pour MySQL (où le temps d'accès est très important). Maintenant le soucis c'est qu'OVH a opté pour la version "grand public" du disque, qui n'est pas adaptée aux serveurs et on pourrait donc se heurter au problème de dégradation des performances. Bref je préfère laisser à d'autres le soin d'essuyer les plâtres.

Attention : que les textes aient été ajoutés n'est pas le plus gros problème, mais le fait qu'il y ait une faille sur le site / serveur qui permette d'en ajouter est beaucoup plus inquiétant à mon sens ; d'autant plus que ce sera certainement à nouveau exploité, et pas forcément de manière aussi "gentille" cette fois.

Hello, pour que l'affectation d'un utilisateur à un groupe soit prise en compte par une application il faut parfois la relancer ; as tu redémarré Apache depuis ta modification ?

Hello, amha à moins que tu ais un trafic titanesque, augmenter le nombre de connexions MySQL simultanées est rarement une bonne idée. Il faudrait déjà commencer par regarder à quoi ressemblent ces fameuses 100 connexions. Si c'est un problème de verrou, tu auras beau augmenter la limite à 2000 (et ajouter la mémoire nécessaire) que ça n'y changera probablement rien. Par contre maintenant que la machine a planté, une réparation des tables est probablement nécessaire.

Si ça peut te rassurer même sur un système faisant de l'hébergement gratuit, sans safe mode, je n'utilise pas de chroot. Le chroot je le réserve à applications posant vraiment problème (comme bind par le passé) ou des systèmes vraiment exposés.

Le tableau je le crée de manière automatique hein, j'y stocke les résultats des requêtes SQL et autres traitements. Pour simplifier, l'exécution de chaque script donne à peu près cela : 1 - chargement du coeur "framework" 2 - traitement des entrées utilisateurs (formulaires, paramètres d'URL, voir cookies) 3 - récupération des données nécessaires à l'affichage 4 - transmission de ces données au moteur de template 5 - affichage Toutes les requêtes SQL sont faites dans les phases 2 et 3, et c'est tout. La connexion à la base de données n'est pas faite avant ces phases, et elle est coupée après la phase 3 (bon techniquement, elle est coupée durant la phase 4, par fainéantise). Après comme je disais moi je procède comme cela et n'ai jamais eu de soucis en utilisant un moteur de template, mais tu peux t'organiser comme tu le sens.

Oui un chroot est toujours délicat/chiant à mettre en place : le principe c'est que l'utilisateur n'a plus accès à rien (du moins uniquement au dossier que tu indiques), et c'est à toi de recopier tout ce dont il est susceptible d'avoir besoin. Rien qu'avec PHP il y a des dizaines à de librairies à prévoir ; il y a bien des outils pour aider à préparer la prison (jail) mais ça reste assez pénible à faire (à mon goût).

Normalement le fait que la configuration soit visible ne devrait pas poser de problème de sécurité. Et au contraire comme le dit Dan c'est parfois nécessaire au bon fonctionnement du système. Après si tu veux tout cacher aux personnes qui se loggent sur ta machine il y a diverses solutions, comme le "chroot".

Moi je vois surtout deux trucs "bourrins" : - le verbe "includer" qui pique les yeux - le fait d'avoir "plein" de variables globales à "transmettre"... les variables globales "c'est le mal". A partir de là toutes les solutions paraîtront forcément "bourrines", le contexte l'obligeant.

Il ne s'agit pas ici d'être convaincu ou non, mais de savoir que c'est techniquement impossible étant donné qu'il n'y a rien coté client (navigateur / browser) qui permette de faire la différence. Comme déjà dit X fois au dessus, au mieux il y aura des doutes pour certains cas de rewriting "mal faits". Le seul moyen de communication disponible pour un site Internet est le protocole "HTTP", et celui ci ne permet en aucun cas de distinguer les URL modifiées à la volée des URL non modifiées. Rien que le fait de faire pointer "http://tondomaine.tld/toto/" vers "http://tondomaine.tld/toto/index.php" c'est du rewriting. Et tu peux vérifier les entêtes HTTP (en utilisant Live HTTP Headers par exemple), il n'y aura strictement pas la moindre différence entre les deux.

Hello, cela dépend surtout de quelques entêtes HTTP particuliers : Last-Modified, ETag, Expires, Cache-Control et Pragma. Chacun ayant plus ou moins son rôle, expliqué dans les différentes RFC du protocole HTTP. Par défaut PHP n'en envoie aucun, ce qui force la plupart des navigateurs à télécharger l'intégralité de la page en permanence, même si celle ci n'a pas été modifiée. Et pour peu que tu utilises les sessions PHP (avec les paramètres par défaut) alors toute mise en cache sera complètement désactivée. Quand aux fichiers statiques (css, js, images, etc) gérés directement par Apache, par défaut ils ont l'entête Last-Modified et ETag mais pas les autres, ce qui conduit à un résultat "aléatoire" : soit le navigateur demande en permanence au serveur si le "fichier" a changé, soit il ne le fait que de temps en temps ; il me semble que Firefox ne redemande validation au serveur que toutes les X minutes, alors qu'un IE 6 va systématiquement redemander. (je n'ai pas fait de test depuis longtemps, donc je ne suis pas certain du comportement de chaque navigateur pour ce cas précis) Il y a pas mal de techniques à mettre en place et de règles à respecter que ce soit coté "statique" (Apache) et coté "dynamique" (PHP) pour que tout cela fonctionne au mieux. Mais c'est très rarement employé, depuis le haut débit on a tendance à faire retélécharger tout et n'importe quoi à l'internaute.

Hello, ce n'est que mon opinion, mais pour ma part il ne me serait jamais venu à l'idée de chercher à exécuter une requête au beau milieu de l'affichage d'un template. C'est certes contraignant d'un point de vue de mémoire (et encore, selon le contexte), mais je récupère toutes les données dans des variables/tableaux avant de faire le moindre affichage. Le seul traitement que j'ai fonctionne différemment est encapsulé dans une méthode (ou fonction si tu préfères) et est alors transparent pour le moteur de template. PS : je précise quand même que je n'ai jamais eu à utiliser Smarty.