The Caribbean Weblog

Je code "un truc cool" en ruby ces jours-ci, et je dois me pencher sur le multi-threading, donc j'ai lu ceci et cela. Mais étant donné que je portais un t-shirt Pretty Hot Programmer au moment où je commencais cette lecture, j'étais dans l'obligation de trouver l'équivalent pour PHP... Eh bien non.

Pas de multi-thrading pour moi, j'ai juste trouvé un semblant traitement asynchrone de connexion, que l'on pourrai difficilement qualifier de traitement en parallèle.

Bref, rUby t3h r0×0rz.

Après avoir vaillement configuré vos certificats, votre propre autorité de certification, certifié tout ce qu'il y a à certifier, vous voulez en profiter. Mais vraiment quoi. En profiter de façon exclusive et crier à tue-tête 'ouais moi laisse rien circuler en clair, c'est ringard et dangereux', alors que vous le faisiez sans honte pendant des années. Vous vous sentez beau, fort et intelligent à ce moment. Et là, vous pouvez aller vous faire soigner, parce que vous craignez "grave"... mais qu'importe, reprennons.
Ceci tiens plus de l'astuce, donc c'est bien connu chez certaines catégories de développeurs :

RewriteEngine On
RewriteCond %{SERVER_PORT} !^443$
RewriteRule ^(.*)$  https://%{SERVER_NAME}/admin/? [R=301,L]

Vous noterez le code 301, qui est une redirection permanente. Évidemment les lignes qui suivent devraient constituer une identification HTTP (avec AuthName, AuthType, etc... voir documentation du core d'httpd 2.2).

Il y a des fois, je me demande (une demi-seconde) si je devrais vraiment utiliser un bon navigateur, tout comme le font 29% de ceux qui lisent ce blog... voici ma mésaventure qui peut être la vôtre :

1. Vous avez un dossier /foo
2. Vous avez un navigateur pas frais (internet explorer et lynx)
3. Vous avez un script (certes codé rapidement) qui vous dirige vers monsite.com/../foo ou monsite.com/./foo

Eh bien vous aurez une belle erreur 400 (Bad Request)...
Aussi étonnant que cela puisse paraître, ce n'est pas (directement) la faute d'Internet Explorer, comme le prouvent ces quelques lignes ci-dessous :

christophe@monica:~$ telnet domtomconnection.com 80
Trying 80.248.209.100...
Connected to domtomconnection.com.
Escape character is '^]'.
GET /../../../foo HTTP/1.0

HTTP/1.1 400 Bad Request

Donc "à qui la faute" ?

• à Apache qui ne sait pas bien gérer une requête un peu bizarre ? (notez que cd ../../../ à partir de / marchera très bien avec bash, donc la notion de (Virtual)DocumentRoot n'est pas gérée de la même façon que le root unix)
• à Firefox et aux autres navigateurs de qualité qui réécrivent les URL et font croire aux développeur naïf que c'est normal ?
• à Internet Explorer qui ne réécrit pas ces URL ?
• à O.J. Simpson qui n'a (toujours) pas d'alibi dans cette affaire ?

Quoiqu'il en soit, cela prouve bien que, même lors de modifications tout à fait mineures pour le développeur, il faut **toujours** retester son site sous Internet Explorer, on est toujours surpris par des phénomènes de tout ordre, personne n'est à l'abri.

Créer une copie d'une table

CREATE TABLE nouvelle_table SELECT * FROM ancienne_table

Cette simple ligne ci-dessus fait une copie quasi-conforme de table_originale, à l'exception de l'attribut AUTO-INCREMENT qui n'est pas reproduit, et du fait qu'aucun index n'est créé dans la nouvelle table. Notez qu'il est plus intéressant de faire ceci :

CREATE TABLE nouvelle_table LIKE ancienne_table
INSERT INTO nouvelle_table SELECT * FROM ancienne_table

Cette dernière est très utile pour toute restauration rapide (non, pas McDonald's) de tables.

Pour sauvegarder toute une base de donnée, l'on peut utiliser mysqldump (ne fonctionne que pour des bases MyISAM) :

$ mysqldump -u login -p --lock-all-tables base_de_donnee > database_backup

... ce qui crée le fichier "backup" contenant toutes les données nécessaires à une restauration, qui se déroule aussi simplement :

$ mysqldump -u login -p base_de_donnee < database_backup

De bon matin, je transferais un de mes sites sur mon dédié (eva pour les intimes), je teste, quand soudain, une erreur : Warning: Header may not contain more than a single header, new line detected.. Jamais vu ça de ma vie, mais comme le code du site n'est pas de moi, je suis près au pire à toutes les surprises.

Je googlise un peu, et je trouve ceci :

BTW, this is from the PHP documentation:

Note: Since PHP 4.4.2 and PHP 5.1.2 this function prevents more than one header to be sent at once as a protection against header injection attacks.

Je vais donc vérifier ça en allant sur php.net/header, je suis redirigé vers la version française à http://fr2.php.net/header, mais rien.
Je vais donc regarder la version anglaise dans la cache de google, et effectivement, c'est bien là, en deuxième paragraphe. Notez que ces deux pages ont la même date de "Last Update" (08 mars 2006) ...

wtf ?