[spip-dev] SPIP et IPv6

Dev
1

Depuis que j'ai autorisé l'utilisation de http://www.ada-france.org/,
SPIP ne génère plus de statistiques.

En effet, le REMOTE_ADDR contient soit une véritable adresse IPv6 soit
une adresse IPv4 représentée en IPv6. Voici les deux:

2001:7a8:5af4:3:202:2dff:fe5c:9049 - - [18/Jun/2003:23:06:54 +0200] "GET /ecrire/ HTTP/1.1" 302 26 "-" "Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4b) Gecko/20030524"
::ffff:212.157.227.222 - - [18/Jun/2003:23:21:37 +0200] "GET / HTTP/1.0" 200 10294 "-" "check_http/1.32.2.6 (netsaint-plugins 1.2.9-4)"

Une adresse IPv6 est stockée sur 128 bits, contre 32 pour une adresse
IPv4. Je pense à utiliser une chaîne de longueur fixe de 128
octets. Une meilleure idée ?

  Sam

2

En effet, le REMOTE_ADDR contient soit une véritable adresse IPv6 soit
une adresse IPv4 représentée en IPv6. Voici les deux:

2001:7a8:5af4:3:202:2dff:fe5c:9049 - - [18/Jun/2003:23:06:54 +0200] "GET /ecrire/ HTTP/1.1" 302 26 "-" "Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4b) Gecko/20030524"
::ffff:212.157.227.222 - - [18/Jun/2003:23:21:37 +0200] "GET / HTTP/1.0" 200 10294 "-" "check_http/1.32.2.6 (netsaint-plugins 1.2.9-4)"

joli

Une adresse IPv6 est stockée sur 128 bits, contre 32 pour une adresse
IPv4. Je pense à utiliser une chaîne de longueur fixe de 128
octets. Une meilleure idée ?

on avait dans l'idée de mettre les trucs temporaires de stats dans un
fichier, ce qui éviterait d'avoir à ouvrir une connexion MySQL à chaque hit
générant une stat. Ca pourrait se faire dans le même temps ? Du coup la
vérification de l'adresse est moins stricte.

Actuellement ça se trouve dans inc-stats.php3

    // Conversion IP 4 octets -> entier 32 bits
    if (ereg("^([0-9]+)\.([0-9]+)\.([0-9]+)\.([0-9]+)$", $log_ip, $r)) {
        $log_ip = sprintf("0x%02x%02x%02x%02x", $r[1], $r[2], $r[3], $r[4]);
    }
    else return;

y'a plus qu'à ! :wink:

-- Fil

3

on avait dans l'idée de mettre les trucs temporaires de stats
dans un fichier, ce qui éviterait d'avoir à ouvrir une connexion
MySQL à chaque hit générant une stat. Ca pourrait se faire dans
le même temps ? Du coup la vérification de l'adresse est moins
stricte.

J'ai regardé le code avant de poster, et j'ai l'impression que
l'adresse est enregistrée dans la base pour compter le nombre de
visiteurs « uniques » (pour autant que ça ait un sens avec tous les
proxys des fournisseurs, il faudrait vérifier le header
X-Forwarded-For et utiliser le champ présent le cas échéant). Le fait
de passer dans un fichier (indépendamment du format d'adresse) risque
de compliquer cela. Ou alors, on peut utiliser un fichier séparé (un
dbm ?) pour stocker les IPs uniques.

y'a plus qu'à ! :wink:

:slight_smile:

  Sam

4

Salut,

on avait dans l'idée de mettre les trucs temporaires de stats dans un
fichier, ce qui éviterait d'avoir à ouvrir une connexion MySQL à chaque
hit

Je suis toujours dubitatif sur ce point à moins qu'il soit clairement
démontré que cela allège beaucoup les choses. Traiter un équivalent
de requête SQL en PHP à partir d'un fichier plat, c'est en général
beaucoup plus coûteux que d'utiliser MySQL. De plus, cela concentre
encore plus les calculs sur une exécution précise alors qu'on avait déjÃ
des problèmes à ce sujet (calculs trop lourds, timeouts....).

Je suis aussi dubitatif sur l'impact de l'"ouverture de connexion
MySQL" sur un système bien paramétré. Pour moi c'est largement une
légende soutenue par aucune étude sérieuse (la connexion à MySQL est
réputée légère par rapport à d'autres systèmes de gestion de base
de données).

a+

Antoine.

5

Je suis aussi dubitatif sur l'impact de l'"ouverture de connexion
MySQL" sur un système bien paramétré. Pour moi c'est largement une
légende soutenue par aucune étude sérieuse (la connexion à MySQL est
réputée légère par rapport à d'autres systèmes de gestion de base
de données).

Bon, alors c'est cool. Il serait intéressant de faire un banc d'essais
(microtime()....), comme ça on serait fixé.

-- Fil