Apache 1.x avec un patch IPv6 sous Linux a la mauvaise idée de noter
une adresse IPv6 sous la forme ::ffff:a.b.c.d.
Le patch suivant, s'il ne comptabilise pas les accès IPv6, permet de
quand-même comptabiliser les accès IPv4.
Sam
patch-ipv6.txt (480 Bytes)
Merci, c'est committé.
@ Antoine Pitrou <antoine@rezo.net> :
Bonjour
J'ai lu dans les innombrables courriers des forums SPIP de la journee du jeudi que le concours etait ouvert pour le logo du site Contrib
A qui dois-je le faire parvenir ?
(Excuser si Hors Sujet, mais je crois que c'est dans cette conference que j'ai lu le message le concernant)
Allez bonne journee ou bonne nuit vu l'heure.
Cordialement
Laurent
J'ai lu dans les innombrables courriers des forums SPIP de la journee du
jeudi que le concours etait ouvert pour le logo du site Contrib
A qui dois-je le faire parvenir ?
Tu peux me l'envoyer.
Benoit
dans l'article 3F6A2FB9.5070801@wanadoo.fr, laurent à
laurent.dubourg@wanadoo.fr a écrit le 19/09/03 2:20 :
Bonjour
J'ai lu dans les innombrables courriers des forums SPIP de la journee du
jeudi que le concours etait ouvert pour le logo du site Contrib
A qui dois-je le faire parvenir ?(Excuser si Hors Sujet, mais je crois que c'est dans cette conference
que j'ai lu le message le concernant)
salut, j'ai lancé l'idée donc je veux bien en assumer les conséquences, je
sais pas encore comment gérer le truc mais je veux bien faire le
"réceptacle" des propositions.
------------oO0o0Oo----------
dorian@3studio.org
::: http://www.3studio.org :::
"L'ennui est la seule excuse du travail" Jules Renard
On peut pas gérer les IPv6 en natif ?
Si, bien sûr, mais il faut de toute façon refaire la manière
d'enregistrer les adresses.
En quoi est-ce différent du reste ?
128 bits au lieu de 32, donc changement de type au niveau MySQL.
Sam
128 bits au lieu de 32, donc changement de type au niveau MySQL.
On peut aussi tronquer le truc à 32 bits ; ce qui importe, c'est qu'un même visiteur qui revient ne soit pas compté deux fois : si par un grand hasard un ipV6 tronqué 'tombe' sur un autre ip (v4 ou v6), eh bien tant pis !
Bof, 32 bits ça ne fait qu'un quart de l'adresse, ce n'est pas énorme.
Quel est le problème pour stocker 128 bits ?
Sam
Bof, 32 bits ça ne fait qu'un quart de l'adresse, ce n'est pas énorme.
Quel est le problème pour stocker 128 bits ?
Euh, non, rien, je ne pense pas qu'il y ait de problème.
-- Fil
Peut-être pas grand'chose, il faut voir si ça nécessite de réécrire
des requêtes MySQL "critiques" (32 bits nécessitent un champ sous
MySQL, 128 bits en nécessitent deux).
Mais d'autre part, qui utilise ipv6 pour des clients Web ? Et est-ce
que les plans d'adressage ne permettent pas de considérer que les
32 derniers bits sont généralement uniques (en particulier s'ils
sont mappés sur l'adresse MAC) ?
a+
Antoine.
Peut-être pas grand'chose, il faut voir si ça nécessite de
réécrire des requêtes MySQL "critiques" (32 bits nécessitent
un champ sous MySQL, 128 bits en nécessitent deux).
Ou un champ de type "chaîne" qui ne mettra peut-être pas beaucoup plus
de temps.
Mais d'autre part, qui utilise ipv6 pour des clients Web ?
De plus en plus de serveurs, et, pour prendre un exemple SPIP + IPv6,
l'association Ada-France (http://www.ada-france.org/).
Et est-ce que les plans d'adressage ne permettent pas de
considérer que les 32 derniers bits sont généralement uniques
(en particulier s'ils sont mappés sur l'adresse MAC) ?
Non, mais les 64 derniers si, la *plupart* du temps (ils se
retrouveront quand-même assez souvent à ::1).
Sam
> Et est-ce que les plans d'adressage ne permettent pas de
> considérer que les 32 derniers bits sont généralement uniques
> (en particulier s'ils sont mappés sur l'adresse MAC) ?Non, mais les 64 derniers si, la *plupart* du temps (ils se
retrouveront quand-même assez souvent à ::1).
Il suffirait de faire un hash md5
-- Fil
Non, mais les 64 derniers si, la *plupart* du temps (ils se
retrouveront quand-même assez souvent à ::1).
Il suffirait de faire un hash md5
Pour obtenir 128 bits 
Sam