[Ludo.H]

Après quelques essais, j'ai pondu ça:

//Kill all first party cookies
$wasPresent = false;
if (isset($_COOKIE)) {
    foreach( $_COOKIE as $key => $value) {
        $wasPresent = $wasPresent || ($key==='90planD');
        setcookie($key,'',time()-7200, '/');
    }
}
if (!$wasPresent) {
    setcookie('90planD', '', time()-7200, '/');
} 

Toutefois,
1 Le cookie est aussi ajouté par les requêtes non php (.html .js, .cs, .jpg, etc.)

2 Lorsque je retire le cookie via ce code, le header de réponse contient un delete et un set du cookie dans la même réponse, plutot bizarre, mais ça marche pour certains navigateurs (pas de cookies stocké).

3 En présence de ce code, le serveur commence à répondre très lentement comme vous le signalez mais en plus avec des erreurs 503 sur les fichiers chargés par la page (css, js, jpeg) apparement quelqu'un doit penser que je fait du DDOS...

Il est a remarquer toutefois que le comportement est différent si c'est le browser qui interdit l'usage de cookie sur le site. Dans ce cas tout semble marcher normalement et sans ralentisement, un set cookie est ajouté a chaque requête par le serveur et ignoré par le browser.

Conclusion: Retirer ce cookie via PHP n'est pas vraiment faisable.

@manud, @janus57
Merci, dire aux avocats du client que c'est un cookie technique sans traitement de données personnelles, inévitable et explicitement autorisé par la CNIL serrait vraiment une très très bonne option.
De fait, sans cette exeption technique, il semble même impossible de se mettre en conformité avec les exigences de la cnil.

Le contenu du site étant sensible (communication aux actionnaires) et geo-protégé il a malheureusement un grand nombre d'avocats très attentifs. Si vous avez une référence sur le site de la cnil ce serrait génial, j'ai cherché mais je n’ai pas trouvé
Les mentions de Xiti et Piwik c'est un peu non relevant, et le texte d'amendement de la loi, lui est parfaitement incompréhensible.

Gauthier

Tout est ici : https://www.cnil.fr/fr/recommandatio...quels-conseils

Quels cookies sont exemptés de consentement ?

S'ils servent certaines finalités spécifiques, certains cookies peuvent être déposés ou lus sans recueillir le consentement préalable des personnes. Ce sont les cookies ayant pour finalité exclusive de permettre, ou de faciliter la communication par voie électronique et les cookies strictement nécessaires à la fourniture d'un service expressément demandé par l'utilisateur. Sont concernés par exemple :

les cookies de " panier d'achat " pour un site marchand ;
les cookies " identifiants de session ", pour la durée d'une session, ou les traceurs persistants limités à quelques heures dans certains cas ;
les cookies d'authentification de l'internaute ;
les cookies de session créés par un lecteur multimédia ;
les cookies de session d'équilibrage de charge (" load balancing ") ;
les cookies persistants de personnalisation de l'interface utilisateur.

[Ludo.H]

Voilà.
Comment ça se passe avec les visiteurs qui refusent les cookies? avec les moteurs?
Ça prouve le ridicule de se baser sur une chose que le visiteur peut refuser pour gérer les performances du site.

Cela ne gère pas que les performances. L'infrastructure est tout de même plus complexe qu'un VPS.

Les sites sont donc 50% plus lent pour les moteurs??? Pourtant la vitesse est devenue un critère de référencement important! (le nombre de choses envoyées aussi)

Non, il y a une ferme de web dédié pour les moteurs de recherche.

Du coup une attaque DDOS qui refuse les cookies passe?

Non, justement.

À part host.fr que vous avez cité et que je ne connaissais pas, non.

Il y a deux méthode :

- Sticky cookie
- Sticky IP

Chacun ses avantages et ses inconvénients.
On peut discuter longtemps sur l'utilité d'un cookie ou non, seulement notre infrastructure à besoin du cookie pour le moment (pour beaucoup de raison).

Je l'avais écrit dans la réponse n°13. Pour moi c'est plus pour les robots que pour les visiteurs et ça contribue quand même à la "propreté" du site et de ce qu'il envoie.

Les robots ne voient pas les cookies, pas de soucis.
Avoir des cookies n'a jamais rendu un site "impropre" dans cette façon de l'utilisé.
Avec ce cookie, vous n'aurez pas de publicité intempestive, aucune information personnel, rien de dangereux, c'est juste du 'routage'.

Cdt,

[Gauthier1967]

Bonjour,

Il vous est possible de supprimer le cookie avec PHP.

Cdt,

Après quelques essais, j'ai pondu ça:

//Kill all first party cookies
$wasPresent = false;
if (isset($_COOKIE)) {
    foreach( $_COOKIE as $key => $value) {
        $wasPresent = $wasPresent || ($key==='90planD');
        setcookie($key,'',time()-7200, '/');
    }
}
if (!$wasPresent) {
    setcookie('90planD', '', time()-7200, '/');
} 

Toutefois,
1 Le cookie est aussi ajouté par les requêtes non php (.html .js, .cs, .jpg, etc.)

2 Lorsque je retire le cookie via ce code, le header de réponse contient un delete et un set du cookie dans la même réponse, plutot bizarre, mais ça marche pour certains navigateurs (pas de cookies stocké).

3 En présence de ce code, le serveur commence à répondre très lentement comme vous le signalez mais en plus avec des erreurs 503 sur les fichiers chargés par la page (css, js, jpeg) apparement quelqu'un doit penser que je fait du DDOS...

Il est a remarquer toutefois que le comportement est différent si c'est le browser qui interdit l'usage de cookie sur le site. Dans ce cas tout semble marcher normalement et sans ralentisement, un set cookie est ajouté a chaque requête par le serveur et ignoré par le browser.

Conclusion: Retirer ce cookie via PHP n'est pas vraiment faisable.

@manud, @janus57
Merci, dire aux avocats du client que c'est un cookie technique sans traitement de données personnelles, inévitable et explicitement autorisé par la CNIL serrait vraiment une très très bonne option.
De fait, sans cette exeption technique, il semble même impossible de se mettre en conformité avec les exigences de la cnil.

Le contenu du site étant sensible (communication aux actionnaires) et geo-protégé il a malheureusement un grand nombre d'avocats très attentifs. Si vous avez une référence sur le site de la cnil ce serrait génial, j'ai cherché mais je n’ai pas trouvé
Les mentions de Xiti et Piwik c'est un peu non relevant, et le texte d'amendement de la loi, lui est parfaitement incompréhensible.

Gauthier

[janus57]

Bonjour,
J'espérais faire l'économie du formulaire de consentement requis par la législation européenne en n'utilisant pas de cookie, et mauvaise surprise, mon plan d'hébergement (performance 2) en ajoute un dans mon dos.
Puisque apparemment, techniquement je ne peux empêcher son apparition, quelles sont les alternatives d'hébergement chez OVH qui me permet de respecter la loi sans ennuyer mes visiteur avec un formulaire qui dans mon cas est inutile (car pas d'analytics et pas de session utilisateur) ?

Gauthier

Bonjour,

comme l'a dit @manud seul les cookies de suivie (ici ce sont des cookies "technique") sont concerné par la loi et encore seulement si le réglage de l'outil est trop "précis", un piwik configuré selon les "normes" de la CNIL (voir leur site) échappe aussi au petit bandeau sur les cookies.

Cordialement, janus57

[manud]

Bonjour,
J'espérais faire l'économie du formulaire de consentement requis par la législation européenne en n'utilisant pas de cookie, et mauvaise surprise, mon plan d'hébergement (performance 2) en ajoute un dans mon dos.
Puisque apparemment, techniquement je ne peux empêcher son apparition, quelles sont les alternatives d'hébergement chez OVH qui me permet de respecter la loi sans ennuyer mes visiteur avec un formulaire qui dans mon cas est inutile (car pas d'analytics et pas de session utilisateur) ?

Gauthier

Ce genre de cookie technique n'est pas concerné par la loi "cookie".

[buddy]

Bonjour,

tout ce qui est dédié, soit VPS ou serveur dédiés.

[Gauthier1967]

Bonjour,
J'espérais faire l'économie du formulaire de consentement requis par la législation européenne en n'utilisant pas de cookie, et mauvaise surprise, mon plan d'hébergement (performance 2) en ajoute un dans mon dos.
Puisque apparemment, techniquement je ne peux empêcher son apparition, quelles sont les alternatives d'hébergement chez OVH qui me permet de respecter la loi sans ennuyer mes visiteur avec un formulaire qui dans mon cas est inutile (car pas d'analytics et pas de session utilisateur) ?

Gauthier

[DJiK]

rectification: parce que VOUS VOULEZ qu'il fonctionne ainsi
il y a d'autres moyens moins intrusifs qu'un cookie pour avoir un fonctionnement similaire
ex: redirection vers le serveur le moins chargé lors de l’établissement d'une nouvelle connexion, puis redirection vers le même serveur par filtrage d'IP une fois la connexion établie. ça donne un fonctionnement identique et la plupart des LB font ça de base.

Voilà.
Comment ça se passe avec les visiteurs qui refusent les cookies? avec les moteurs?
Ça prouve le ridicule de se baser sur une chose que le visiteur peut refuser pour gérer les performances du site.

sans le cookie, vos performance risque de diminuer de 50% voir plus.

Les sites sont donc 50% plus lent pour les moteurs??? Pourtant la vitesse est devenue un critère de référencement important! (le nombre de choses envoyées aussi)

On vous a bien entendu, mais on ne pourra pas faire grand chose, le matériel et notre anti-DDoS fonctionne comme cela.

Du coup une attaque DDOS qui refuse les cookies passe?

Vous risquez fortement de trouver le même fonctionnement sur un autre hébergeur.

À part host.fr que vous avez cité et que je ne connaissais pas, non.

Ton site a probablement pour but d'être visité par des centaines, des milliers de personnes. Peux-tu me dire combien de visiteurs seront déçus de ton site parce qu'un cookie dont personne (hormis nous les techniques) ne comprend l'existence ?

Je l'avais écrit dans la réponse n°13. Pour moi c'est plus pour les robots que pour les visiteurs et ça contribue quand même à la "propreté" du site et de ce qu'il envoie.

[david6996]

Bonjour,

@romainovh, je suis au régime :P

@Ludo.H, merci pour votre réponse et votre franchise. Je vais réfléchir du coup

Cordialement.

David…

[romainovh]

@ romainovh, même si une majorité d'internaute ce moque des cookies, le premier intéressé est l'auteur du site et si ça le gêne (ce qui est mon cas) il est normal d'en faire part à son prestataire. Si ce dernier lui explique avec diplomatie que rien ne changera, alors… Ai-je besoin de conclure ?

No souci, je respecte et comprends totalement les visions de chacun ;-)
Auteur du site et visiteur, les deux points de vue sont à prendre en compte.

Et pi les cookies, c'est bon, avec les pépites de chocolat

[Ludo.H]

Bonjour,

Il vous est possible de supprimer le cookie avec PHP.
Pour nous il est difficile de laisser le choix du je veux un cookie ou non, personne ne comprend son implication.
Même si vous avez qu'un site vitrine, sans le cookie, vos performance risque de diminuer de 50% voir plus.
Le load balancer devant à chaque fois vous trouvez le serveur web qui va le moins charger, sans erreur et disponnible, alors qu'avec un cookie il le trouve une fois et vous envoie toujours dessus ensuite (il y a un reset auto du cookie).

On vous a bien entendu, mais on ne pourra pas faire grand chose, le matériel et notre anti-DDoS fonctionne comme cela.

Cdt,

[david6996]

Bonjour,

Tout d'abord, merci Ludo.H pour votre réponse, même si vous confirmez que rien ne changera, vous expliquez votre choix technique.
Donc si j'ai bien compris, c'est une question de cession, mais pourquoi alors ne pas laisser le choix pour qui ne veulent qu'un site vitrine (sans administration, base de données, etc.) ?

@ romainovh, même si une majorité d'internaute ce moque des cookies, le premier intéressé est l'auteur du site et si ça le gêne (ce qui est mon cas) il est normal d'en faire part à son prestataire. Si ce dernier lui explique avec diplomatie que rien ne changera, alors… Ai-je besoin de conclure ?

Cordialement.

David, un client qui croit encore au miracle d'être entendu :P

[romainovh]

Ah oui en effet,
honte à moi sd82979, j'ai mélangé les participants au débat !

Bref, ma question tient toujours pour DJiK alors !

[sd82979]

Bonjour,

je ne suis pas l'auteur du sujet, ma réponse était purement technique.
Ludo a d'ailleurs complété ses précédentes réponses en argumentant les choix qu'a fait OVH.

j'ai travaillé sur des infras assez grosses avec load balancer avec d'autres choix techniques, sans cookie (en fait si mais pas pour ça), ce qui explique ma réponse

bref, perso m'en fiche, j'utilise pas les mutualisés

[romainovh]

Hello sd82979,

Je ne suis ni pour ni contre ce cookie, mais je voudrais te poser une question.

Ton site a probablement pour but d'être visité par des centaines, des milliers de personnes. Peux-tu me dire combien de visiteurs seront déçus de ton site parce qu'un cookie dont personne (hormis nous les techniques) ne comprend l'existence ?

Après, tu le considères comme intrusif, je respecte ta vision, pas de souci ;-)

Cordialement

[Ludo.H]

Bonjour,

C'est une raison technique qui nous fait choisir le cookie.
Les algorithmes utilisés pour determiner le serveur web ne sont pas compatible avec les autres façons de faire.
De plus si nous passons sans cookie, nous ne suivons plus ces algo or ce sont eux qui faut le DDoS aussi.
C'est un choix certe, mais nous sommes limité à cette utilisation si nous voulons rendre le bon service.

Cdt,

[sd82979]

C'est pas que nous mettons de la mauvaise volonté à vouloir supprimer ou non un cookie, c'est que le load balancing fonctionne ainsi.

rectification: parce que VOUS VOULEZ qu'il fonctionne ainsi
il y a d'autres moyens moins intrusifs qu'un cookie pour avoir un fonctionnement similaire
ex: redirection vers le serveur le moins chargé lors de l’établissement d'une nouvelle connexion, puis redirection vers le même serveur par filtrage d'IP une fois la connexion établie. ça donne un fonctionnement identique et la plupart des LB font ça de base.

[Ludo.H]

Bonjour,

Autre explication du cookie de session (aussi nommé sticky cookie) :

- Sur un cluster nous avons une ferme de ~500 serveur webs
- En frontal nous avons un load balancer (distributeur de charche)

1/ sans cookie de session :

Vous arriverez aléatoirement sur le sereveur web 1, au prochain click d'un lien sur le serveur web 2, au prochain click sur le 3, etc...
Votre site ne pourra avoir aucune session, wordpress/prestashop/etc.. ne fonctionneront pas bien, reset du login par exemple (aucune session possible).

2/ avec un cookie de session :

Vous arriverez toujours sur le même serveur web, tout fonctionnera normalement, les sessions php, etc...


C'est pas que nous mettons de la mauvaise volonté à vouloir supprimer ou non un cookie, c'est que le load balancing fonctionne ainsi.
Vous risquez fortement de trouver le même fonctionnement sur un autre hébergeur.
Sauf si celui-ci dédie un serveur pour votre site (mutualisé peut-être avec d'autre client), mais en cas de panne du serveur... pas de load balancing.
Dommage que vous partiez à cause d'un cookie, surtout qu'il ne contient aucune information sur vous.
Désolé que vous soyez obliger de partir.

Cdt,

[david6996]

Bonjour,

Je cherchais moi aussi à me débarrasser de ce cookie que je considère comme intrusif. Je fais en sorte que mes sites respectent le W3C, WAI, etc.
Il m’arrive souvent de naviguer avec lynx (navigateur pour console) et ça m’attriste vraiment que ce dernier me demande d’accepter un cookie de mon propre site.

Vous dîtes qu’il est impossible de se débarrasser de ce cookie et j’ai compris le pourquoi du comment technique, mais je n’ai pas à pallier à ce choix technique ; vous ne voulez pas faire l’effort ; je n’ai pas l’impression que ce soit une bonne politique envers votre clientèle.

Je vais donc à regret faire un transfert de mon site, chez un autre prestataire, c’est dommage, car j’ai vraiment autre chose à faire.

Cordialement.

David, un client déçu.

[Ludo.H]

Bonjour,

Universel? Dans quel univers? Je n'ai pas vu de cookie chez d'autres hébergeurs mutualisés.

Beaucoup l'utilise pourtant.
Le cookie peut avoir plusieurs forment et n'est pas facilement identifiable.
Sur host.fr par exemple, le cookie s'appel : SN4cbc4cd8d3bc9

.
J'ai choisi OVH pour tester l'effet des IP internationales sur le référencement mais si c'est pour avoir une telle contrepartie, c'est inutile.

Ce n'est en aucun cas de la mauvaise foi de ma part.
C'est juste que le matériel que nous utilisons fonctionne comme décrit.
Je ne pourrais pas changer le fonctionnement de HA-proxy ou des CISCO.

Les cookies sont certes écrits sur disque, mais que s'il change, sinon les tests sont fait en RAM, c'est le travail du navigateur.
Il est demandé aux navigateurs de supporter a minima (et sans pénaliser l'utilisateur) :
300 cookies simultanés ;
4096 octets par cookie ;
20 cookies par hôte ou par domaine.

Tout est décrit dans la RFC suivante : http://tools.ietf.org/html/rfc2965

Je ne pense pas que votre référencement en subisse une quelconque conséquence.

Cdt,

[DJiK]

P.S.: je ne vois pas en quoi cela gène le référencement, c'est un fonctionnement universel.

Ça c'est de la mauvaise foi.
Universel? Dans quel univers? Je n'ai pas vu de cookie chez d'autres hébergeurs mutualisés.


J'ai choisi OVH pour tester l'effet des IP internationales sur le référencement mais si c'est pour avoir une telle contrepartie, c'est inutile.
Cela gêne le référencement comme je l'ai dit parce que ça ralentit l'usage du site: un cookie doit être écrit sur le disque dur à chaque élément des pages!
C'est évident qu'un site sans cookie est plus propre, plus léger, plus rapide, des critères devenus primordiaux en référencement.


Cela fait parties des recommandations quand on teste un site sur Dareboost. Google n'en parle plus directement sur ces sites, mais ça a été le cas, si vous cherchez vous trouverez des anciens liens.

Éviter l'envoi de cookies sur des ressources statiques

Les requêtes effectuées pour récupérer les ressources d'une page peuvent contenir de nombreuses données inutiles. Par exemple, il n'y a aucune raison d'envoyer des cookies sur des fichiers statiques (images, fichiers JavaScript et CSS, etc).

Certains noms de domaines demandent l'envoi de cookies pour les ressources statiques. Si possible, faites appel à d'autres domaines n'appliquant pas cette restriction.

http://www.ravelrumba.com/blog/stati...ieless-domain/

The concept is simple—don’t serve static content like images and stylesheets from a domain that sets cookies

https://productforums.google.com/for...rs/VEbVqz2HQzE

The idea behind a cookieless domain is that it can speed up transferring static files by the browser not having to send cookies with every request. This is something that can help to reduce the time needed to render a page, if you have static, shared content.

Quoi qu'il en soit, je fais mes sites pour les visiteurs, pas pour les moteurs, et là vraiment cela ne fait pas propre de créer un cookie par élément, je n'en veux pas. Ce n'était pas précisé quand j'ai signé.

[Gaston_Phone]

Merci Ludovic pour ces explications très claires.

[Ludo.H]

Bonjour,

Explication technique :

1/ Browser -> 1er requête vers le site : pas de cookies

- La requête est traiteé par notre matériel, routé vers un serveur par défaut, qui fait le calcul et forge le cookie
- Reponse HTTP avec le cookie

2/ Browser -> nième requêtes vers le site : avec cookies

- Nos routeurs/loadbalancer ont le cookie et trouvent directement le chemin vers le serveur web. (gain de temps et de performance).

C'est ce qu'on appelle un cookie de session, plus de documentation des plus grand load balancer (haproxy, F5 networks, cisco...) :

- http://blog.haproxy.com/2012/03/29/l...-need-to-know/
- https://support.f5.com/kb/en-us/prod...lb_cookie.html
- http://docwiki.cisco.com/wiki/Sessio...ration_Example

Donc il n'est pas possible de le supprimer de notre infrasctrure par design.
De plus si nous le supprimons vos requêtes deviendront beaucoup plus lente.

Cdt,

P.S.: je ne vois pas en quoi cela gène le référencement, c'est un fonctionnement universel.

[DJiK]

,Les cookies servent aux equiments (cisco/F5/alteon/etc...) afin d'identifier sur quel serveur du cluster votre site se situe.

... Bizarre. Lors de la 1ère visite de la page la requête trouve bien son chemin. Ainsi que pour les visiteurs qui n'acceptent pas les cookies.

Le soucis n'est pas de l'enlever de chez moi, mais de ne pas l'envoyer aux visiteurs et aux moteurs. Comment faire?
Réponse immuable chez OVH: "c'est impossible" c'est ça?

[Ludo.H]

Bonjour,

Les cookies servent aux équipements (cisco/F5/alteon/etc...) afin d'identifier sur quel serveur du cluster votre site se situe.
Le Rxxxxxxx correspond à un serveur, il sera souvent identique mais peu changer.
Si vous le supprimez, il sera reconstruit.

Cdt,

[DJiK]

Quand tu affiches le source de ta page affichée, trouves-tu le mot « Cookie » ?

Ça n'a aucun rapport. Un cookie est dans les entêtes HTTP.

Le trafic réseau occasionné doit être négligeable (même si on aime toujours le réduire au strict minimum).

Ça écrit toujours sur le disque dur des visiteurs, et pas à seulement chaque page mais à chaque élément! Chaque image, icone, CSS, JS a son propre cookie!
Comme disais ce n'est pas "propre" et autant pour les visiteurs que pour les moteurs c'est négatif. En plus à ce niveau là c'est ridicule.

C'est une très très vielle histoire ces cookies OVH
On an parlait déjà ici en 2010 ! : https://forum.ovh.com/showthread.php...domaine-90plan

Oui, j'ai vu!
D'ailleurs ça provoque des problèmes et le support OVH ne sait même pas expliquer à quoi ils servent: https://forum.ovh.com/showthread.php...BAK-qui-plante

Quand je lis "hébergement performance: les hébergements pensés pour les sites techniques" et qu'il y a ce genre de daube (et je ne parle même pas de la configuration des sous-domaines ou de PHP), je me sens un peu lésé!

[Abazada]

En fait, tu as raison, j'ai aussi des cookies déposés par OVH : 60gp:R122419 . . .

C'est une très très vielle histoire ces cookies OVH
On an parlait déjà ici en 2010 ! : https://forum.ovh.com/showthread.php...domaine-90plan

@DjiK : en quoi est-ce gênant pour toi ?

Ca va à l'encontre des recommendations Google : utilisation de domaines cookieless pour le contenu statique.

[manud]

@DjiK : en quoi est-ce gênant pour toi ?
Par exemple, s'agissant d'un cookie technique, il ne rentre pas en compte dans la "loi cookies" de la CNIL.
Le trafic réseau occasionné doit être négligeable (même si on aime toujours le réduire au strict minimum).

[Gaston_Phone]

Quand tu affiches le source de ta page affichée, trouves-tu le mot « Cookie » ?

Je viens de regarder dans le source de mes pages affichées et je ne vois rien.

[DJiK]

Des variables de session sur des images ou du contenu statique (css, js) ce n'est pas possible. Ce cookie n'est pas créé par moi mais rajouté par OVH après.

Merci, je sais ce qu'est un cookie. Ce n'est pas parce qu'il n'est pas stocké qu'il n'est pas envoyé dans les entêtes HTTP.

En l'occurrence oui, il est envoyé aussi aux robots (à moins que ça ne soit pas basé sur le nom d'agent mais j'en doute). Exemple sur cette présente page qui l'a aussi: http://www.webrankinfo.com/outils/he...4&ua=googlebot

-> Set-Cookie: 720planD=R1415262906; path=/; max-age=900


Bravo OVH... je regrette déjà (puis faut pas compter sur son droit de rétractation ici).

[Gaston_Phone]

En fait, tu as raison, j'ai aussi des cookies déposés par OVH : 60gp:R122419 . . .

- - - Mise à jour - - -

Sur un hébergement performance, sur toutes les pages, y compris les images, etc... j'ai un cookie 90plan=R987654... qui est créé.
Apparemment c'est rajouté ensuite par OVH et inaltérable, mais dites Monsieur OVH... est-ce vraiment nécessaire? Ça ne fait pas très propre.

Utilises-tu des variables de session ?

Les robots des moteurs de recherches reçoivent aussi ces cookies? y'a-t-il moyen de ne pas les envoyer?

Je ne le pense pas.
Les cookies sont en général des petifichiers déposés en local sur un PC (ou autre) et qui servent :

• A gérer les variables de session
• A concerver une trace de la dernière visite sur le site

[Gaston_Phone]

Url ?

[DJiK]

Bonjour,

Sur un hébergement performance, sur toutes les pages, y compris les images, etc... j'ai un cookie 90plan=R987654... qui est créé.
Apparemment c'est rajouté ensuite par OVH et inaltérable, mais dites Monsieur OVH... est-ce vraiment nécessaire? Ça ne fait pas très propre.

Les robots des moteurs de recherches reçoivent aussi ces cookies? y'a-t-il moyen de ne pas les envoyer?