Remi

Pour ma part je préfère systématiquement déclarer un fichier robots.txt. On m'a dit la même chose mais bizarrement l'indexation sur Google ne se faisait pas sans.

Si l'indexation s'est produite alors qu'un fichier robots.txt venait d'être ajouté, c'est certainement un hasard...

Il y a des millions de sites indexés sans robots.txt (je dirais même, au pif, qu'il doit y avoir plus de site sans robots.txt qu'avec).

Il faut bien reconnaître que, dans la plupart des cas, le fichier robots.txt ne sert pas à grand chose.

Quand on désire donner l'accès à tout, on peut aussi mettre

User-agent: *
Disallow: /repertoire_bidon

et accessoirement on peut ainsi repérer dans ses logs les "indélicats" (ceux qui vont essayer d'aller lire ce qui est interdit)

Il n'y a pas d'erreur dans ta ligne, si ce n'est que, utilisée seule, elle devrait te générer une erreur 500 car elle va tourner en rond:

Il faut impérativement écarter les index.php

RewriteCond %{REQUEST_URI} !^/index\.php$ [NC]
RewriteRule ^(.*)$ /index.php?page=$1 [L]

Là on dit : si ce n'est pas 'index.php...' qui est demandé, alors on transforme l'URL.

Si tu as une erreur 404 (et non une 500), je pencherais plutôt pour dire que la ligne n'est tout simplement pas exécutée...

Il y a bien un 'RewriteEngine on' dans le .htaccess ?

Le fichier .htaccess est-il au bon endroit ?

etc...

Url Rewriting avec 301.

C'est le même cas que rediriger "sans www" vers "avec www".

Et sans le '/' de début de la RewriteRule, tu as essayé?

Tout dépend de l'apllication mais...

... stocker des fichiers de type pièce jointe dans une base de données est la meilleure façon de faire exploser la taille de sa base, surtout s'il s'agit de .doc (à propos : un "fichier plat" est normalement un fichier de type texte, un .doc ou .pdf n'est pas vraiment un "fichier plat").

En revanche, on peut stocker dans la base l'emplacement de la pièce jointe pour pouvoir aller la rechercher si besoin est.

Le jour où ton site n'est plus classé "confidentiel défense", n'hésite pas à nous donner une URL...

On pourra peut-être t'aider.

Il n'y a pas d'attribut style height:100px qui fonctionne bien dans tous les navigateurs (on va mettre de côté les solutions à base de tableau... ), il faut ruser.

Peut-être il te faudrait prendre le problème dans l'autre sens : faire en sorte de ton body adopte la hauteur du div :

=> bien mettre le margin-bottom du div à 0 et le padding-bottom du body à 0

=> gérer l'espace libre en bas avec le padding-bottom du Div

Après tu n'auras normalement qu'à examiner le cas où ton div est plus petit que la fenêtre du visiteur, chose qui doit pouvoir se régler élégamment avec un padding-bottom suffisant.

A propos : il faut bien garder à l'esprit que le background n'est pas du contenu.

C'est de la déco, du papier peint...

La taille de l'image du background n'entre pas en ligne de compte.

Hum... on comprend mieux sans l'image...

Mais ce n'est certainement pas dû au 'background', c'est simplement que ton DIV ne va pas jusqu'en bas (le div va se dimensionner en fonction de son contenu)

Calimero, à ta place, je changerais de mot de passe...

car les pointages DNS ne se modifient pas tout seuls.

OVH ne les triture pas et de toutes façons leur config de base c'est pointage A sur le NDD seul et le www en Cname (et non deux pointages A comme c'est le cas quand on veut pointer sur deux choses différentes).

Ca donne une erreur 500 en demandant quelle Url ?

Une url de répertoire sans index ?

Ou n'importe quelle Url ?

Euh...

Moi j'aurais tendance à dire le contraire : à mon avis, les .TEL sont traités différemment par les moteurs de recherche. C'est tout de même une extension très particulière et chercher à se positionner avec un .TEL (sauf sur un annuaire spécifique) me paraît délicat.

De toutes façons, faire du contenu sur un .tel est forcément limité.

C'est un peu comme si, sur une page web, on n'avait que les metadata (descriptions et keywords) et pas de body...

Il y a 2 races de MP4 : ceux qui mettent les metadata en tête et ceux (de loin les plus courants) qui mettent les metadata en queue.

Je n'utilise pas Adobe Media Encoder mais je suppose qu'il fait comme la plupart : il met les metadata en queue (je ne sais qui a eu cette idée brillante mais c'est très ch....)

Daily Motion pratiquant le streaming, je parierais volontiers ma trottinette rouge (que je garde précieusement depuis l'âge de 5 ans) qu'il met les metadata en tête (car sinon, il lui faudrait charger tout le fichier avant de commencer à afficher...)

Le problème pourrait venir de là.

La construction modulaire en php est une solution mais ce n'est pas la seule...

Elle est pas forcément le plus adaptée pour des sites qui ne bougent qu'assez peu leur menu et autres parties fixes.

Dans ce cas, les Templates de Dreamweaver ou équivalents sont parfaits.

Bon, pour avoir une modification qui s'applique à toutes les pages, il faut bien la faire dans le fichier Template .dwt, hein... Et au moment de sauver, il doit demander s'il faut appliquer la modif à toutes les pages ou pas...

Dans une page normale, la partie correspondant au Template doit d'ailleurs être grisée, on ne peut la modifier.

Si ce n'est pas cela que tu vois, alors il y a une c... euh un truc dans le potage.

En tout cas, j'ai bien fait de ne pas faire d'ironie facile du genre "ce n'est pas sur le Hub qu'on trouverait un script pareil..." car, plaf, c'est un script qui vient du Hub.

Même s'il est moins dramatique que la seule ligne extraite ne le laissait supposer (le script travaille directement dans le tableau $_POST... bizarre mais bon, ça fonctionne... ), il n'en a pas moins une faille, effectivement sur l'injection d'en-tête : il ne suffit pas d'enlever les balises html, il faut aussi virer les bcc et consorts.

Je le pense

D'accord, mais c'est là que les soucis commencent :

il y a une différence énorme entre le petit diaporama Flash qui continuent de charger des images en arrière plan pendant 30 secondes et les scripts qui moulinent plein de trucs et qui bloquent la machine.

Sur un PC peu puissant, la différence est énorme...

Ce qu'il faudrait, c'est mesure l'occupation processeur des scripts...

Il y a pas mal de pages sur le sujet :
/>http://www.google.fr/#q=injection+mail

Comme je le disais :

Il ne faut jamais réinjecter dans une fonction mail des champs qui viennent par Post sans faire des vérifications dessus.

Ce genre de script, c'est le délice du sp*m*eur...

La solution est dans le message d'erreur : "unexpected if" veut dire "If inattendu..."

Donc l'erreur est sur la ligne précédente, la plupart du temps un point-virgule qui manque à la fin de la ligne précédente.

Je suppose que le titre du fil de discussion sur le forum en question était "Comment laisser la porte grande ouverte pour se faire pirater son serveur"...

car il ne faut jamais réinjecter dans une fonction mail des champs qui viennent par Post sans faire des vérifications dessus.

Donc mon conseil serait de chercher un script un peu plus sérieux.

Woah...

On peut voir aussi les clics sur les sitelinks assez clairement.

Il est difficile de déterminer le temps d'exécution d'une page, notamment à cause des javascripts qui pourraient ralentir cette exécution.

Oui, c'est très difficile : à quel moment considère t-on que la page est chargée ?

Pas facile, car le site peut redonner la main et continuer à exécuter/charger en arrière-plan : sur une machine lente, on a la main mais le curseur ne répond pas (ou il faut cliquer 15 fois pour que le clic soit pris en compte) car les scripts occupent parfois 100% du temps machine...

C'est un peu comme au démarrage de Windows : il nous donne la main très rapidement, mais en pratique il faut mieux attendre 1 ou 2 minutes qu'il ait fini toutes ses salades. Cela évite de commencer la journée en pestant contre son ordinateur...

Je ne comprends pas l'intérêt de ces lignes

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule (.*) /404.php

Là, on dit : pour tout ce qui n'est pas un fichier existant, ou une directory existante, on affiche la page 404...

Donc on affiche une page 404 avec un code retour 200...

Les lignes correctes me semblent être les lignes "errorDocument", pas besoin de rewriting pour traiter les erreurs.

Non ?

Les meilleures optimisations restent tout de même au niveau de la programmation elle-même : multiples accès à la base de données, construction poussive de la page par petits modules empilés, multiples JS qui bloquent l'affichage chez le client, accès à 45000 modules JS externes, etc...

Bon, mais je ne crois pas trop à cette annonce mais si cela peut sensibiliser les webmasters au problème de la vitesse, cela ne sera pas inutile... En tout cas, c'est une pierre lancée dans le jardin de Macromedia car ceux qui vont avoir le plus peur, ce sont les concepteurs de sites full flash.

Si c'est du spam,

j'en ai déjà reçu plusieurs ainsi.

Je suppose qu'ils prennent une option sur le NDD en question pour le bloquer (je suppose car je n'ai jamais vérifié).

Non, je ne pense pas qu'il s'agisse de Prefetch car le flux est lu seul, indépendamment de tout autre accès, et en plus sur ce site là j'ai débranché le Prefetch (par rewriting).

Non, comme le dit Dadou, il doit s'agit de visiteurs qui veulent suivre le site... Pour une IP donnée, je vois un accès toutes les 30 minutes effectivement. J'ai aussi des accès sur les autres sites qui ont un flux.

Je n'avais jamais remarqué qu'il y avait tant d'accès Apple PubSub dans les logs... Au départ, je regardais cela car je voulais voir les accès Facebook et je me suis trouvé noyé par les Apple PubSub...

(Facebook par contre, lui c'est le contraire, il vient lire quand il a le temps, toutes les 48 à 60 heures environ)