5139 sujets

Le Bar du forum

Extension Fasterfox : une plaie pour les serveurs ?

Pages :
(reprise du message précédent)

Laurent Denis a écrit :
Re-bonjour,

<provocateur, mais...>
Cette extension et ses effets pervers sont très sains, finalement : ils invitent à limiter le nombre de liens disponibles par page
</>


<mode provoc toi-même>
Même sur les plans de site et les pages d'annuaires ?
</mode provoc toi-même>

Mon meilleur taux de visites concerne quand même mon carnet d'adresses moto Smiley cligne
Bob (MC Melun) a écrit :


<mode provoc toi-même>
Même sur les plans de site et les pages d'annuaires ?
</mode provoc toi-même>


<mode provoc assumé>
Evidemment, quelqu'un n'a pas pu s'empêcher de faire une remarque intelligente... Ne vous y arrêtez pas Smiley cligne
</>
@Laurent Denis> Oui, mais personne n'a répondu à ma question :'( alors je la repose Smiley langue :

Comment faire un lien avec les caractéristiques suivantes:
* Invisible à l'utilisateur, y compris avec navigation au clavier : style="display:none;" suffit ?
* Invisible au moteurs de recherche, afin de ne pas mettre en liste noire les moteurs de recherche. Solution alternative: vérifier l'identifiant utilisateur dans le PHP
* Que pour FasterFox en fait.

?

Bon, je vais faire ma lessive et je pond ce script après...
Merci. Décidément, ce Laurent Denis m'étonnera toujours! <mode=lèche>Merci pour être ici bas, parmi nous pour diluer ton immense savoir (et surtout ton immense répertoire de signets Smiley lol )</mode>
Bonsoir.
D'avance excusez mon newbisme. Mais ce fléau suit seulement les liens de premier niveau de la page en visite ou toutes les pages du site tant qu'il trouve un lien à suivre ? Second, troisième niveau etc ?
Sinon ça ne concerne que les liens html ? Pas les php non urlrewrités ? Et qu'en est-il des images ? Elles sont mises en cache systématiquement aussi ? Smiley decu
Les hébergements mutualisés, voire les fai, risquent pas d'en prendre également une claque ? Merci de vos avis.
//edit : vu sur le site de Fasterfox :
a écrit :
Donations to date: $69 - Special thanks to PCS Intel!!

Il est pas chié celui là, je vais lui envoyer les huissiers oui ! Suçage de bande passante, ça va chercher loin ? Smiley eek
Modifié par globy (09 Dec 2005 - 22:31)
Demander aux développeurs de l'extension qu'elle se manifeste pour la bloquer ou la limiter est totalement stupide : ça va marcher 5 minutes, puis hop, un éditeur peu scrupuleux va ramener sa fraise et dire "regardez, mon préfetcheur préfetche même les sites qui l'interdisent !" et là forcément, il va rameuter la horde de pauvres ignorants que sont nos chéris visiteurs et sucer toute la bande passante.
Pareil pour le respect du robots.txt ou du rel="nofollow". Il ne faut pas oublier que le monde n'est pas tout rose et qu'il y aura toujours des gens assez cons pour développer des logiciels qui feront exprès d'ignorer ce genre de directives.

La seule solution viable se situe côté serveur, mais ça risque d'être une rude bataille : si le préfetcheur tente de se faire passer pour un navigateur normal, nous aurons alors un problème de taille.

Aussi, on tourne en rond si on tente de placer un lien invisible puis de vérifier si le client qui suit ce lien est un moteur de recherche ou pas : le préfetcheur pourrait aussi se faire passer pour un moteur de recherche... bref, une solution de paranoïaque pour cas déséspérés consisterait alors à vérifier que l'adresse IP du client qui télécharge le lien invisible provient bien de Google, avec tous les inconvénients que cela entraîne pour les moteurs de recherche peu connus et autres types de robots "utiles"...

En conclusion, je pense qu'on ne pourra finalement compter que sur l'éducation, le civisme et la compréhension des visiteurs. Sucer toute la bande passante d'un site qui procure de l'aide au visiteur est pour moi d'un manque de respect et d'un égoïsme incommensurable, mais encore faut-il que l'utilisateurs de tels logiciels soient au courant des dommages qu'ils causent.
e-t172 a écrit :
Sucer toute la bande passante d'un site qui procure de l'aide au visiteur est pour moi d'un manque de respect et d'un égoïsme incommensurable, mais encore faut-il que l'utilisateurs de tels logiciels soient au courant des dommages qu'ils causent.

tout à fait d'accord avec cette remarque ! Smiley cligne
HoPHP a écrit :
Pour ce qui est du robots.txt, je ne vois pas le rapport, en fait... Ce fichier est là pour définir quel fichier doit être indexé par les moteurs de recherche, je ne vois pas ce que ça vient faire avec le prefetching...
Depuis quand le robots.txt devrait-il s'appliquer uniquement aux moteurs de recherche ? Il est prévu pour tous les robots Smiley cligne
Sur la FAQ de Fasterfox il est maintenant indiqué ceci :
a écrit :
I'm a webmaster, how can I prevent prefetching?

Because some websites may not have the resources available to support the enhanced prefetching feature, it may be easily blocked by webmasters.

Prior to generating any prefetching requests, Fasterfox checks for a file named "robots.txt" in your site's root directory (subdirectories are not checked). If this file contains the following 2 lines, no prefetching requests will be made to your domain:

User-agent: Fasterfox
Disallow: /

Je crois que ça va en satisfaire certains Smiley cligne
Merci Calimo, je crois que tu viens de conclure cet intéressant débat Smiley cligne
Afin de me souvenir pour quoi j'ai mis cette commande dans mon robots.txt,
j'ai mis un commentaire le précedent comme ci-dessous
a écrit :
#désactiver fasterfox ( plugin qui "pré-télécharge" les pages dans le cache)
User-agent: Fasterfox
Disallow: /

Modifié par charlynancy (19 Dec 2005 - 10:02)
e-t172 a écrit :
Il ne faut pas oublier que le monde n'est pas tout rose et qu'il y aura toujours des gens assez cons pour développer des logiciels qui feront exprès d'ignorer ce genre de directives.


A mon avis le débat n'est pas clos.

> Aussi je voudrais réagir à M@teo, même si j'aime bien son site etc... il y a quelque cose qui me tracasse; si j'ai bien compris il se plaind que les pages utilisant la réecriture de chemin sont pré-chargés (on est francophone tout de même ^^) ?
Et bien si j'ai bien saisie et après tout je suis là pour comprendre, ne serait il pas plus simple de désactivé la réecriture d'url ? car selon mon expérience elle sert en particulier à être mieu classé dans les moteurs de recherches.

> Egalement si j'ia bien compris, le problème ne se limite pas à FasterFox qui symbolise les méchants qui abusent de nos servers et qui mettent de périle toute l'industrie du net ? (Hyperbolisation^^).
Moi perso, j'ai une petite idée il suffirait (juste pour FasterFox) de le détécter avec PHP, et ensuite d'ajouter un sleep(10); par exemple histoire que l'utilisation de FasterFox ne rende pas inaccessible le site internet, mais ai l'effet inverse de l'effet voulut.
Mais plus généralement, ce que l'on cherche à contrer c'est une navigation trop rapide, limiter à x ou y pages par IP, par seconde, et par ordinateur ?

Egalement j'ai une petite critique par rapport à ce qui avait était proposé plus haut, je pense pas qu'il soit très utile de bloqué une IP particuliére.. enfin si c'est radical, mais il ne faut pas oublier les personnes qui consulte depuis leur lieu de travail, ou depuis un réseau, ainsi il suffit qu'une seule machine du réseau utilise un méthode peu recommandable et tout le réseau est bloqué.
Miouge a écrit :

Mais plus généralement, ce que l'on cherche à contrer c'est une navigation trop rapide, limiter à x ou y pages par IP, par seconde, et par ordinateur ?


Ca a plusieurs inconvénients :

- C'est un algorythme qui consomme pas mal côté serveur, surtout pour les sites (comme le site du zéro) où l'ajout d'une fonction un tant soit peu consommatrice à chaque page pourrait avoir des conséquences désastreuses.

- Pour reprendre tes propres arguments : il suffit que 10 personnes regardent le même site depuis le même endroit (donc depuis la même IP), ce qui peut arriver si elles travaillent ensemble, pour qu'elles rencontrent des problèmes.
Je reprend le topic car je viens de découvrir cette extension par des utilsateurs Firefox et que possédant un serveur ça commence aussi à m'inquiéter...

Apparament, la solution la plus intelligente pour tout le monde serait :

a écrit :
James, si ton site utilise PHP, JSP ou autre langage web, tu peux toujours mettre en début de page un script qui detecte ce genre de chose.. (masi c'est plus compliqué à faire..)


Mais qui peux faire le script ?
Une question au passage sur Fasterfox.

Imaginons, par exemple, un forum; vous êtes sur un sujet.
Un lien indique "surveiller ce sujet".
Si Fasterfox précharge ce lien, le script PHP va indiquer que l'utilisateur veut surveiller le sujet ?
Je veux dire par là: FasterFox peut-il charger des pages contenant des scripts PHP, et ainsi faire de grosses bétises ?
Le mieux c'est d'en parler au développeur pour qu'il abandonne : si un quart des utilisateurs firefox s'y mettent ils deviendront super rapide sur des sites de plus en plus : bref la même chose que si personne ne l'avait utilisé...
Sylvain a écrit :
Une question au passage sur Fasterfox.

Imaginons, par exemple, un forum; vous êtes sur un sujet.
Un lien indique "surveiller ce sujet".
Si Fasterfox précharge ce lien, le script PHP va indiquer que l'utilisateur veut surveiller le sujet ?
Je veux dire par là: FasterFox peut-il charger des pages contenant des scripts PHP, et ainsi faire de grosses bétises ?

Oui, il prend tous les liens... Sauf que là, je serais tenté de dire que ce n'est pas un problème de FasterFox, mais plutôt un problème de conception du forum.

En effet, une action comme "surveiller ce sujet" possède ce qu'on appelle un "effet de bord" : quelque chose est modifié en base de donnée. L'état de l'application est changé. Selon la spécification du protocole HTTP, on sait que (anglais, désolé) :
a écrit :
GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe".

Donc une URI appellée par GET (donc un lien normal standard bidon) ne doit rien faire d'autre que de retourner une page. Or là, on fait autre chose, on active la surveillance d'un sujet.

Il faudrait donc que le lien "surveiller" soit en fait un mini formulaire transmis en POST. Donc au lieu de :
<a href="surveille.php?topic=1234">Surveiller</a>

On ait :
<form action="surveille.php" method="post">
  <div>
    <input type="hidden" name="topic" value="1234" />
    <input type="submit" value="Surveiller" />
  </div>
</form>

Là on est bon Smiley smile Et chose encore plus classe, faudrait que le script surveille.php renvoi un code HTTP "405 Method Not Allowed" s'il est accedé par GET, et là on est vraiment encore plus bon Smiley lol

Y'a eu une histoire là dessus sur je sais-plus-quel CMS qui avait des lien "supprimer cet article" en GET, et pour confirmation juste une boîte de dialogue en JavaScript. Et un gars avait FasterFox (ou google machin, je sais plus), qui s'amusait à tout préloader... Y compris les lien de suppression. Et comme y'avait pas de confirmation côté serveur (juste une confirmation javascript), tous les articles ont disparu d'un coup, jusqu'à ce qu'il se rendent compte de leur erreur...

Moralité : on y gagne toujours à respecter les spécifications Smiley lol
ol' a écrit :
Mouais, 'faut quand même éviter les mini formulaires pour des liens, non?

Ben justement, là c'est pas un lien, c'est un bouton pour activer la surveillance d'un sujet. Faut pas confondre Smiley lol
FlorentG a écrit :

Ben justement, là c'est pas un lien, c'est un bouton pour activer la surveillance d'un sujet. Faut pas confondre Smiley lol


Mouais... C'est vrai...

N'empèche que je trouve que c'est pas aux dev de s'adapter à fasterfox... Mais bien à FasterFox de s'adapter, de faire gaffe et de respecter les normes ou de se retirer du marché...
Pages :
Sujet clos
Aller à