Méthylbro Développeur Web PHP - Tutoriels

PHP/MySQL : Enregistrer et lire des fichiers dans une base de données

Méthylbro — Tue, 24 Nov 2009 08:00:00 +0100

Tout au long de la semaine dernière nous avons vu comment enregistrer et consulter des fichiers dans une base de données MySQL avec PHP.

Nous avons appris les principes de bases des Objets Larges Binaires (BLOB) ainsi que les outils mis a notre disposition par PDO pour les manipuler efficacement avec PHP. Nous avons vu également les limites de ce genre de pratiques et comment en résoudre certaines en implémentant un petit système de cache côté PHP.

Au cours de mes exemples j’ai proposé une classe FileFromDB et un ensemble de pages permettant de démontrer comment réaliser tout cela. Vous trouverez aujourd’hui, en annexe à ce billet, l’ensemble des scripts utilisées comme exemple.

Télécharger des sources : exemple.rar

Je n’ai malheureusement pas eu le temps de les commenter proprement mais si vous vous reportez aux articles de la semaine, vous serais alors à même de les comprendre.

Si cela vous intéresse de venir discourir des avantages et des (nombreux) inconvénients que peuvent avoir cette pratique, je vous invites à venir le faire sur le forum dans l’espace dédié au développement.

PHP : Un cache pour nos fichiers stockés dans MySQL

Méthylbro — Sun, 22 Nov 2009 13:00:00 +0100

Tout au long de la semaine, nous avons vu ensemble comment stoker des fichiers dans une base de données MySQL avec PHP et comment les lire par la suite.

Cependant même s'il peut s'avérer pratique de profiter des capacités relationnelles de MySQL pour gérer des fichiers ; le risque d'une consommation de ressources excessive soulevé par cette méthode est élevé.

Nous allons voir aujourd'hui pourquoi cette pratique bien qu'intéressante en apparence n'est que trop rarement utilisée en réalité. Nous verrons également comment proposer certaines solutions qui nous permettrons de résoudre certains des problèmes soulevés.

Au niveau de MySQL

Bien évidemment un serveur de base de données n’a pas été conçu pour stocker massivement des fichiers. Il n’a pas pour vocation de manipuler exclusivement ce type d’informations. Votre système de fichier sera bien évidemment beaucoup plus performant pour effectuer cette tâche.

Stocker des fichiers dans vos tables alourdira considérablement la taille de ces dernières. Le serveur de données aura donc besoin de plus de temps et de ressources pour les parcourir lors de vos requêtes, ce qui peut nuire grandement au temps d’exécution global de vos script.

A contrario centraliser les données est toujours quelque chose de très intéressant pour la maintenance d’une application. Les backups sont plus faciles à gérer lorsque les données nécessaires pour un programme sont réunies au même endroit. Comme cela peut être le cas avec une base de données.

Le débit de données entre le serveur et votre script

Il y a un point primordial que nous devront prendre en compte si nous souhaitons tout de même utiliser MySQL pour stocker nos fichiers : c’est le débit d’information qui va circuler entre le serveur de base de données et notre script.

En effet outre les problèmes directement liés à notre SGBDR a chaque fois que nous allons vouloir faire appel à l’un de nos fichiers stocké en base celui-ci va devoir parcourir un long chemin pour arriver jusqu'à nous.

Pour illustrer mon propos ; jetez un coups d’œil sur le schéma suivant :

La solution que l’on peut facilement envisager c’est de créer un cache au sein de notre application qui stockera dans le système de fichiers nos fichiers tant qu’ils seront valables par rapport à leurs version dans la base de données.

La méthode FileFromDB::headers()

A partir de ce que nous avons fait jusqu'à présent, mettre en place ce petit cache va s’avérer très facile. Commençons par modifier notre classe FileFromDB qui, je vous le rappelle, nous permet de manipuler nos fichiers stockés dans la base de données.

Même si nous ne souhaitons pas faire circuler nos fichiers inutilement entre notre script et la base de données nous auront besoin néanmoins d’un grand nombre d’informations les concernant. Principalement leur nom ainsi que la date de leur dernière modification.

public function headers() {

global $PDO;

$stmt = $PDO->prepare("SELECT name, type, UNIX_TIMESTAMP(updated_date) AS updated_date FROM FILE WHERE name = ?");

$stmt->bindParam(1, $this->filename);

$stmt->execute();

return $stmt->fetch(PDO::FETCH_OBJ);

}

C’est le rôle de cette nouvelle méthode. Elle nous donnera uniquement ces informations sous la forme d’un objet de type sdtClass. Ce qui évitera d’avoir à aller chercher notre fichier inutilement à chaque demandes.

Une nouvelle page de download

Maintenant que nous disposons des outils nécessaires, nous pouvons modifier notre page de téléchargement de fichiers en y ajoutant notre petit système de cache. Par défaut donc, notre script enverra donc au visiteur le fichier contenu dans le cache.

Ce dernier sera néanmoins renouvelé par le fichier contenu dans la base de donnée si l’une de ces trois conditions n’est pas rempli :

Le fichier n’existe pas encore dans le cache
Le fichier stocké dans le cache à dépasser son temps de vie maximum
Le fichier stocké dans le cache n’est plus à jour avec celui stocké dans la base de données

$cache_path = 'cache/';

$cache_lifetime = 3600;



if (isset($_GET['filename'])) {

$File = new FileFromDB($_GET['filename']);

$FileHeaders = $File->headers();

$file_cache = $cache_path.$FileHeaders->name;

if (!file_exists($file_cache)

|| filemtime($file_cache)+$cache_lifetime

|| filemtime($file_cache)<=$FileHeaders->updated_date) {

$File->output($file_cache);

}

header("Content-Type: {$FileHeaders->type}");

header("Content-Disposition: inline; filename={$FileHeaders->name}");

header("Last-Modified: ".date('r', $FileHeaders->updated_date));

readfile($file_cache);

}

Dans un prochain billet je reviendrais sur tout ce que nous avons vu sur le stockage de fichier au sein d’une base de données avant de conclure cet article. Je vous proposerais également les sources utilisées dans nos exemples commentés.

PHP : Lire un fichier stocké dans la base de données

Méthylbro — Fri, 20 Nov 2009 08:00:00 +0100

Nous avons vu précédemment comment stocker un fichier dans une base de données MySQL. Puis nous avons explorer ensemble une méthode pour insérer ce fichier dans la base directement à l’aide d’un petit script PHP. Aujourd’hui nous allons voir comment récupérer ce fichier avec PHP.

Notre exemple sera très simple, nous allons seulement récupérer le fichier là ou il est, c’est a dire dans la base de données MySQL, pour le retourner directement à un visiteur.

Il n’y aura donc pas de traitement sur ce fichier. Cependant cela serait tout à fait possible. Récemment par exemple je me suis retrouver dans un cas ou je devais modifier des images après les avoir récupérer dans une base de données.

La méthode FileFromDB ::output()

Dans notre dernier chapitre sur ce sujet, nous avons commencé l’élaboration d’une classe FileFromDB nous permettant de manipuler des fichiers stockés dans une base de données.

Nous allons poursuivre la conception de cette dernière en lui rajoutant une méthode output() qui nous permettra de lire un fichier vers le flux standard de sortie ou d’enregistrer celui-ci dans le système de fichiers.

Cette méthode acceptera donc un paramètre facultatif $filename. Si celui-ci est fournis nous enregistrerons une copie du fichier stocké dans la base de données vers la destination indiqué au sein du système de fichiers.

Sinon nous afficherons le fichier directement vers le flux standard de sortie. Comme il s’agit d’Apache dans notre exemple, nous prendrons soin d’indiquer certains en-têtes HTTP nécessaire pour que le client comprenne de quel fichier il s’agit.

public function output($filename=null) {

global $PDO;

$stmt = $PDO->prepare("SELECT type, UNIX_TIMESTAMP(updated_date), data FROM FILE WHERE name = ?");

$stmt->bindParam(1, $this->filename);

$stmt->execute();

$stmt->bindColumn(1, $type, PDO::PARAM_STR, 256);

$stmt->bindColumn(2, $updated_date, PDO::PARAM_INT);

$stmt->bindColumn(3, $data, PDO::PARAM_LOB);

$stmt->fetch(PDO::FETCH_BOUND);

if (is_null($filename)) {

header("Content-Type: $type");

header("Content-Disposition: inline; filename={$this->filename}");

header("Last-Modified: ".date('r', $updated_date));

//return fpassthru($data);

return print($data);

} else {

$hdle = fopen($filename, 'wb');

//return stream_copy_to_stream($data, $hdle);

return fwrite($hdle, $data);

}

}

Le bug #40913 de PHP

Comme vous pourrez le voir j’ai laissé deux lignes en commentaires dans la méthode ci-dessus. En effet a ce stade nous ne pourrons malheureusement pas utiliser d’objet large binaire (Binary Large Object) car PHP et PDO sont encore victimes d’un bug non corrigé à ce sujet.

Le problème vient du fait que, malgré que l’on indique à PDO que l’on souhaite recevoir un paramètre de type PDO::PARAM_LOB (Objet Binaire Large) celui-ci nous retourne une chaîne de caractère (PDO::PARAM_STR). Il deviens impossible alors de traiter notre valeur comme une ressource de flux (utilisable notamment avec les fonctions fpassthru() et stream_copy_to_stream().

En attendant que ce problème soit corrigé j’utiliserais donc print() et fwrite() dans mon exemple. Mais attention, cette méthode de remplacement consomme énormément plus en ressource qu’un simple traitement par flux. Ne l’utilisez donc pas en production (surtout sur des sites avec une grosse charge).

La page de download

Maintenant que nous avons une solution nous permettant de récupérer des fichiers stockés dans notre base de données MySQL, nous pouvons facilement créer un petit script pour télécharger ces fichiers.

if (isset($_GET['filename'])) {

$File = new FileFromDB($_GET['filename']);

$File->output();

}

Encore une fois ce script restera simple et l’on omettra toutes les vérifications d’usage en termes de sécurité. Ce n’est pas le sujet abordé.

Dans un prochain article nous verrons que notre solution demande énormément de ressources inutiles. Nous réglerons donc ces problèmes en implémentant un petit système de cache applicatif côté PHP.

PHP : Enregistrer un fichier dans une base de données

Méthylbro — Tue, 17 Nov 2009 08:00:00 +0100

Maintenant que nous disposons d’une base de données prête à stocker nos fichiers directement au sein d’une table nous allons pouvoir commencer à regarder comment faire fonctionner cela proprement avec PHP.

Nous verrons donc aujourd’hui comment enregistrer un fichier au sein d’un champ de type LONGBLOB avec PHP. Ici le fichier proviendra d’un formulaire mais on pourrais très bien étendre le champ d’application de cette méthode à tout type de sources.

L’exemple utilisera PDO (PHP Data Object) ; si vous n’êtes pas à l’aise avec cette extension de PHP je vous conseille vivement de vous mettre à jour. Car comme vous pourrez le voir les fonctionnalités que proposent cette extension sont fort agréables.

La classe FileFromDB

Afin de manipuler les fichiers stockées dans la base de données, je vous propose d’utiliser une classe que nous feront évoluer tout au long de ce tutoriel. Appelons la FileFromDB car chaque instance de cette classe nous permettra de manipuler un de nos fichiers.

class FileFromDB {

private $filename;

public function __construct($filename) {

$this->filename = $filename;

}

}

Le formulaire d’upload

Comme je le disait lors de l’introduction, dans notre exemple les fichiers seront envoyés par les utilisateurs. Cela nécessitera donc un petit formulaire permettant d’envoyer des fichiers.

<?php

$message = null;

if (isset($_FILES['myFile'])) {

$File = new FileFromDB($_FILES['myFile']['name']);

$File->upload($_FILES['myFile']);

$message = 'Votre fichier à bien été ajouté';

}

?>

<html>

<head>

<title>Upload</title>

</head>

<body>

<form method="post" enctype="multipart/form-data">

<?php echo $message; ?>

<fieldset>

<legend>Charger un fichier</legend>

<p>

<label for="myFile">Fichier</label>

<input type="file" id="myFile" name="myFile" />

</p>

<p>

<input type="reset" value="Annuler" />

<input type="submit" value="Envoyer" />

</p>

</fieldset>

</form>

</body>

</html>

Ce formulaire restera simple et l’on omettra toutes les vérifications d’usage en termes de sécurité. Ce n’est pas le sujet abordé.

La méthode FileFromDB::upload()

Enfin nous ajouterons à notre classe FileFromDB une méthode permettant d’enregistrer notre fichier comme un objet large binaire au sein de notre table. L’extension PDO et son système de requêtes préparées nous propose un type de paramètre parfait pour résoudre les problèmes liés : PARAM_LOB.

Ainsi nous passerons comme paramètre un flux vers le fichier que l’on souhaite envoyé à la base de données au lieu de l’intégralité du contenu lui même. En travaillant avec des flux de données nous ne consommerons pas inutilement les ressources disponibles.

public function upload($file) {

global $PDO;

$stmt = $PDO->prepare("REPLACE INTO FILE (name, type, data) VALUES (?, ?, ?)");

$stmt->bindParam(1, $this->filename);

$stmt->bindParam(2, $file['type']);

$stmt->bindParam(3, fopen($file['tmp_name'], 'rb'), PDO::PARAM_LOB);

return $stmt->execute();

}

Dans un prochain article nous verrons comment lire des fichiers enregistrés dans notre base de données.

MySQL : Stocker un fichier dans une base de données

Méthylbro — Sun, 15 Nov 2009 08:00:00 +0100

Techniquement il est tout à fait possible de stocker des fichiers directement au sein d'une base de données.

Cependant peut de développeurs se risquent à ce genre de pratique. Il est vrai que si l'on maîtrise mal certains aspects, ou s'il on en demande trop à cette technique cela peut vite se révéler être un véritable calvaire.

Néanmoins je reste intimement convaincu que dans certains cas et pour des besoins raisonnables il peut être fort agréable de pouvoir stocker des fichiers directement au sein d'une base de données.

Cette semaine je vous propose une série de billets qui va vous permettre de comprendre comment réaliser une telle chose. Mais je vais également essayer de vous amener à bien appréhender les risques et les limites d'une telle pratique ce qui vous permettra de mieux envisager sur quel projet cela peut ou ne peut pas se faire.

Les Objets Larges Binaires (BLOB)

Pour stocker nos fichiers au sein de notre base de données nous allons utiliser un type de données que les néophytes découvriront sans doutes pour la première fois : les Objets Larges Binaires ou BLOB pour Binary Large Object.

Le BLOB est un type de donnée permettant le stockage d’informations sous forme binaire. On l’utilise le plus souvent pour stocker des fichiers en tout genre (images, sons ou videos …) directement dans le champ d'une table d'une base de données.

Pour notre exemple nous utiliserons MySQL comme système de gestion de base de données. Sachez que celui-ci propose plusieurs types différents d’objets larges qui ne diffèrent que par la taille maximale des données qu’ils peuvent stocker.

Parmi eux nous utiliserons le type LONGBLOB car ce dernier propose la capacité maximale de stockage ; mais le choix du type à utiliser variera selon les cas que vous pourrez rencontrer lors d’une application pratique.

Création de la table

La première étape consiste donc à créer la table qui viendra stocker nos différents fichiers. Outre le nom du fichier et le contenu même du fichier, nous conserverons également le type de fichier (« image/jpeg » pour une image par exemple) et la date de la dernière modification du fichier.

Ces informations supplémentaires nous seront utiles par la suite pour envoyer des en-têtes HTTP corrects au visiteurs ainsi que pour gérer un petit cache côté serveur.

CREATE TABLE `FILE` (



`name` varchar(255) NOT NULL,

`type` varchar(255) NULL,

`updated_date` timestamp NOT NULL

DEFAULT CURRENT_TIMESTAMP

ON UPDATE CURRENT_TIMESTAMP,

`data` longblob NULL,



PRIMARY KEY (`name`)



)TYPE=MyISAM;

Un champ de fichier dans PHPMyAdmin

Une fois que vous aurez créer votre table avec la requête SQL CREATE TABLE ci-dessus, vous vous apercevrais sans doutes que PHPMyAdmin vous proposera un formulaire d’insertion un peut particulier.

En effet, vous verrez apparaître un champ d’envoi de fichier pour la valeur data. Comme vous pouvez le voir donc, notre champ data est bien destiné à recevoir un fichier.

Dans un prochain article ; nous verrons comment enregistrer des fichiers au sein de cette table directement depuis un script PHP.

Étude de cas : Une perle dans l'utilisation de la fonction date de PHP

Méthylbro — Fri, 23 Oct 2009 08:00:00 +0200

Toujours plonger dans mes retouches sur un code source magnifiquement drôle depuis ces derniers jours. Je voudrais vous proposer aujourd’hui une nouvelle perle de développement PHP.

Aujourd'hui nous allons voir une implémentation hilarante de la fonction date().

La problématique est la suivante : afin de construire une chaîne de caractères vous avez besoin de connaître trois informations temporelles ; l'année, le mois et le jour courant.

Pour ce faire, voici ce qu'a proposé, écrit et mis en production un développeur :

$today = mktime(0, 0, 0, date("m"), date("d"), date("Y"));

$ladate = date("d / m / Y", $today);

$lemois = date("m", $today);

$lannee = date("Y", $today);

$lejour = date("d", $today);

Vous comprenez le problème ?

Ici l'interpréteur va calculer 8 fois la date. Sans compter bien évidement qu'utiliser la variable $today est inutile vu que la fonction date() retourne déjà la date du jour par défaut (ce que savais apparemment le développeur, puisqu'il utilise la fonction date() pour trouver la valeur de son $today) .

Bien évidement, il aurait été plus pertinent d'écrire quelque chose comme cela :

define('DATE_SEPARATOR', ' / ');

$today = getdate();

$lemois = $today['mon'];

$lannee = $today['year'];

$lejour = $today['mday'];

$ladate = $lejour.DATE_SEPARATOR.$lemois.DATE_SEPARATOR.$lannee;

Un seul calcul de date, on stocke les informations dans un tableau associatif et ensuite c'est juste un jeu d'affection de valeurs.

Étude de cas PHP & MySQL : Connaître le nombre d’occurrences dans une table

Méthylbro — Wed, 21 Oct 2009 13:00:00 +0200

Toujours plongé dans de l'analyse de code depuis quelques jours, je vous propose à nouveau de partager et d'analyser quelques perles avec vous.

Dans ce billet, je vais m'entretenir avec vous d'un cas récurrent en développement web : compter un nombre d'occurrences spécifique dans une base de données ou plus simplement, connaître le nombre d'occurrences enregistré dans une table. C'est ce dernier exemple que nous utiliserons pour illustrer mes propos.

Parmi mes pérégrinations dans les méandres de ce script infâme ; je suis tombé sur diverses méthodes pour compter un nombre d'occurrences dans une base de données qui m'ont fait hurler.

Premier exemple, le développeur qui n'a jamais appris autre chose que les requêtes de base et se limite aux outils les plus simples de PHP :

$sql = "SELECT * FROM maTable";

$res = mysql_query($sql);

while($row[] = mysql_fetch_array($res));

$nb  = count($row);

Remarquez comme c'est magnifique ; lancer une boucle à l'exécution alors que c'est complètement inutile.

Comme deuxième exemple, je vais vous proposer une variante ; le développeur qui n'y connais toujours rien au SQL de base, mais qui c'est quand même penché un minimum sur la documentation de PHP :

$sql = "SELECT * FROM maTable";

$res = mysql_query($sql);

$nb  = mysql_num_rows($res);

C'est presque acceptable. Cependant imaginez le nombre d'informations inutiles que vous allez faire circuler entre le serveur de données (ici MySQL) et votre script ? Si le nombre d'enregistrements dans votre table est conséquent, imaginez le temps que cela va prendre !

Bien évidement, vous avez la réponse en vous. Il faut utiliser la fonction SQL COUNT(). C'est logique. Comme cela on ne récupère que le nombre d'occurrences ; après tout pourquoi pas, c'est la seule chose que l'on veut non ?

En bon développeur consciencieux ; vous écrirez sans doutes quelque chose comme cela :

$sql = "SELECT COUNT(*) FROM maTable";

$res = mysql_query($sql);

$row = mysql_fetch_row($res);

$nb  = $row[0];

Cependant même si vous êtes presque dans le vrai, une dernière chose me chipote sur cette solution. Pourquoi faire une affectation par ligne avec un fetch ? Il n'y a qu'une seule information dans le résultat votre requête, vous savez ou elle se trouve alors pourquoi ne pas aller la chercher directement ?

C'est pourquoi, et pour conclure, je proposerais tout simplement cette solution :

$sql = "SELECT COUNT(*) AS `nb` FROM `maTable`;";

$res = mysql_query($sql);

$nb  = mysql_result($res, 0, 'nb');

Et vous, vous feriez comment ?

Étude de cas : Tester si une variable est vide en PHP

Méthylbro — Wed, 21 Oct 2009 08:00:00 +0200

Comme je vous l'ai déjà dit hier, je suis en train de devoir modifier toute une série de script écrit en PHP par d'autres développeurs.

Si hier l'inutilité d'ouvrir des flux à tout bout de champ vers des fichiers m'a pour le moins amusé, aujourd'hui je commence à être agacé par tout ce que je peu voir.

Pour tester si une variable est vide, beaucoup trop souvent les jeunes développeurs s'arrêtent à la solution suivante :

if ($myVar=="") 

echo 'ma variable est vide';

Alors qu'en réalité l'assertion $myVar=="" ne signifie pas du tout la variable $myVar est vide mais la variable $myVar est une chaîne de caractères vide.

On trouve ce genre d'assertion partout dans beaucoup de script. Pourtant qu'adviendrait il de notre script si $myVar avait une valeur à entier:0 dès le départ ?

$myVar = 0;

if ($myVar=="")

echo 'ma variable est vide';

Ou mieux, si $myVar était null ?

$myVar = null;

if ($myVar=="")

echo 'ma variable est vide';

Pourtant dans ce dernier cas, $myVar est réellement vide, puisqu'elle n'a aucune valeur. Mais l'assertion $myVar=="" ne se vérifie pas. Donc peut on considérer que $myVar=="" signifie que $myVar est une variable vide ?

Si vous souhaitez tester si une variable est vide, utilisez plutôt la fonction empty() :

if (empty($myVar))

echo 'ma variable est vide';

Si vous considérez une chaîne de caractères composée seulement d'espace comme vide, vous pouvez alors utiliser la fonction trim() au préalable. Prenons un exemple concret trouvé dans le script qui m'a inspiré ce billet :

if ($nick != "" && $text != "" && $nick != " " && $text != " ") {}

Nous effacerons les espaces en début et fin de chaîne avec la fonction trim() avant de tester le résultat avec empty() dans une condition :

$nick = trim($nick, ' ');

$text = trim($text, ' ');

if (!empty($nick) && !empty($text)) {}

Étude de cas : Stocker une date dans le système de fichiers en PHP

Méthylbro — Tue, 20 Oct 2009 08:00:00 +0200

En travaillant sur un script écrit par quelqu'un d'autre, j'ai eu l'idée de ce petit tutoriel. En effet au sein d'un script que j'ai du modifier j'ai découvert une portion de code qui m'a quelque peut alerté.

Nous allons voir comment le développeur aurait pu résoudre son problème avec une solution alternative.

Dans notre exemple nous devrons stocker une date dans le système de fichiers côté serveur puis pouvoir venir la récupérer et la mettre à jour lors d'une autre exécution du script.

Voici mot pour mot la solution qui a été retenue par le développeur dont j'ai du modifier le script :

// Ecriture de l'heure courante dans fichier, pour comparaison ulterieure

$fichier_memoire = "memoire.db";



// Lecture de la derniere heure sauvegardee

// Ajouter protections

$fp_l = fopen($fichier_memoire, 'r');

$last_date = fread($fp_l, 6);

$suc=fclose ($fp_l);



// L'heure courante brute //

$date_propre = date('H:i');



$fp_m=fopen($fichier_memoire, w);

$suc=fputs($fp_m, "$date_propre");

$suc=fclose ($fp_m);

Comme vous pourrez le voir, l'opération se déroule en deux temps :

d'abord on ouvre un flux en lecture vers le fichier pour récupérer la date stockée comme une chaîne de caractère en son sein
ensuite on ouvre un flux en écriture seule vers le fichier pour venir enregistrer la date à l'intérieur comme une chaîne de caractères

Ce que je reproche à cette méthode, c'est d'ouvrir inutilement et à deux reprises un flux vers le fichier (d'abord en lecture puis en écriture).

En effet le système de fichier nous propose déjà d'obtenir toute une foule d'information avant même d'ouvrir celui-ci. Son nom, le nom de son propriétaire, sa taille, sa date de création, sa date de dernière modification etc.

Pourquoi alors ne pas utiliser directement ces informations ? Cela nous éviterais d'avoir ouvrir notre fichier.

Pour cela je vais vous proposer d'utiliser la date de dernière modification pour stocker l'information qui nous intéresse.

// format de date que l'on utilisera à l'affichage

define('DATE_FORMAT', 'Y/d/m H:i:s');

// nom du fichier 

$filename  = 'filetest';  

// ensemble des informations sur le fichier

$fileinfos = stat($filename);

// date de dernière modification que l'on donnera au fichier 

$time = time(); 



// Si le fichier existe déjà, on montre ca date de dernière modification

if (file_exists($filename))

echo 'last update : '.date(DATE_FORMAT, $fileinfos['mtime']).'
';



// On modifie la date de dernière modification du fichier

// Si ce dernier n'existe pas, on le crée

if (touch($filename, $time))

echo 'update on : '.date(DATE_FORMAT, $time);

Pour stocker une date dans le système de fichier afin de revenir la chercher plus tard, quelle solution préférait vous ? Ouvrir toute une série de flux vers le fichier ou manipuler directement les informations relatives à ce dernier ?

A lire également sur le sujet

Chargement de fichiers (3/3) - par la méthode PUT

Méthylbro — Sat, 10 Oct 2009 08:00:00 +0200

Nous avons vu comment faire du charment de fichier avec la méthode POST dans le dernier billet. Pourtant, comme nous l'avons vus dans le tutoriel sur le protocole HTTP ; faire de la création de ressources (et donc de l'envoi de fichier) avec la méthode POST fonctionne, mais ce c'est pas le top.

La marche a suivre passe alors par l'utilisation de la méthode HTTP PUT. C'est sur cette dernière que nous allons nous pencher aujourd'hui. Nous verrons alors que, encore trop peu de navigateurs supportent la méthode PUT et pour des raisons de sécurité, JavaScript ne vous facilitera pas forcément la vie pour pouvoir proposer une alternative aux browsers ne prenant pas en charge cette méthode.

Chargement de fichiers par la méthode PUT

Comme nous l'avons vu dans notre étude du protocole HTTP, chaque action à réaliser sur le serveur possède idéalement une méthode propre. GET pour la lecture, POST pour la modification, DELETE pour la suppression, HEAD pour avoir les en-têtes d'un document ainsi que PUT pour la création de nouvelles ressources.

Côté client

Idéalement donc, nous ne devrions donc pas utiliser la méthode POST pour envoyer des fichiers (du moins, lors de la création de ressources) mais la méthode PUT. Le formulaire idéal que nous devrions posséder pour la création d'une nouvelle ressource devrait donc avoir la forme suivante :

<form method="put">

<p>

<label for="titre">Titre</label>

<input type="text" id="titre" name="titre" />

</p>

<p>

<label for="image">Image</label>

<input type="file" id="image" name="image" />

</p>

<input type="submit" value="ajouter" />

</form>

Malheureusement, nous ne pourrons commencer à voir apparaître ce genre de formulaires qu'avec HTML5.

Une surcouche simple avec JavaScript ?

En attendant la sortie de HTML5 et donc le support de la méthode PUT, nous pourrions créer des surcouches simple en JavaScript pour envoyer nos fichiers. En effet la fameuse interface XMLHTTPRequest de JavaScript (à l'origine de ce que l'on appelle AJAX) implémente elle toutes les méthodes du protocole HTTP.

Il suffirait donc de créer un formulaire de ce type :

<?xml version="1.0" encoding="utf-8"?>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr" lang="fr">

<head>

<title>Upload</title>

<meta http-equiv="content-type" content="text/html; charset= utf-8" />

<script type="text/javascript">

window.onload = function() {

document.getElementById("test").onsubmit = function() {

var xhr = null;

if(window.XMLHttpRequest)

xhr = new XMLHttpRequest();

else if(window.ActiveXObject){

try {

xhr = new ActiveXObject("Msxml2.XMLHTTP");

} catch (e) {

xhr = new ActiveXObject("Microsoft.XMLHTTP");

}

} else {

alert("Votre navigateur ne supporte pas les objets XMLHTTPRequest...");

xhr = false;

}

xhr.onreadystatechange = function() {

if(xhr.readyState == 4) {

if (xhr.status == 200) {

this.innerHTML = "Le fichier "+this.fichier.value+" a bien ete charge";

} else {

this.innerHTML = "Impossible de charger le fichier "+this.fichier.value;

}

}

}

xhr.open("PUT", "script.php", false);

xhr.send(this.fichier);

return false;

}

}

</script>

</head>

<body>



<form method="put" id="test">

<p>

<label for="fichier">Fichier</label>

<input type="file" id="fichier" name="fichier" />

</p>

<input type="submit" value="envoyer" />

</form>



</body>

</html>

Cependant cette solution se borne à un problème de sécurité de taille. Il est impossible en JavaScript de pouvoir lire le contenu du fichier appartenant encore au client. Il existe cependant des astuces pour palier à ce problème. Mais les mettre en place relève du calvaire.

Ressources utiles sur le sujet

Côté serveur

Côté serveur néanmoins, les choses sont plus simples. Car le duo Apache/PHP permet d'implémenter facilement le traitement des requêtes de type PUT voire DELETE aussi d'ailleurs.

La directive Script d'Apache

La première chose à faire si vous souhaitez que votre script réponde à des requêtes HTTP avec la méthode PUT sera de signaler à Apache ce qu'il doit faire lorsqu'on lui demandera de traiter une telle requête. Nous utiliserons pour cela la directive « Script » d'Apache.

Vous pouvez placer cette directive n'importe où dans votre fichier de configuration d'Apache. Généralement on l'insère dans un bloc <Directory> ou parfois même directement dans un <VirtualHost>.

Nous allons voir un exemple simple, permettant de charger un fichier. A chaque utilisation de la méthode PUT, nous demanderons donc à Apache d'exécuter le fichier « put.php » :

Script PUT /put.php

Traitement de la méthode PUT en PHP

Une fois Apache configuré pour exécuter notre script lors d'une requête avec la méthode PUT il n'y a rien de plus simple à traiter en PHP.

Il suffit de lire le flux entrant qui contiendra les données du fichier, puis d'aller les écrire dans un fichier de destination sur le serveur.

$putdata = fopen("php://input", "r");

$fp = fopen("myputfile.ext", "w");

and write to the file */

while ($data = fread($putdata, 1024))

fwrite($fp, $data);

fclose($fp);

fclose($putdata);

Chargement de fichiers (2/3) - par la méthode POST

Méthylbro — Sat, 03 Oct 2009 08:00:00 +0200

Voyons aujourd’hui la deuxième partie du tutoriel sur le chargement de fichiers avec PHP.

Aujourd’hui nous allons voir comment mettre en place un formulaire permettant de charger un fichier vers un serveur en utilisant la méthode POST. C’est la méthode la plus classique cependant comme je l’ai dit lors de l’introduction ; nous verrons également comment implémenter la méthode PUT.

Chargement de fichier par la méthode POST

Le chargement de fichier tel que nous le connaissons le plus couramment à été introduit en novembre 1995 par la RFC-1867. Si vous souhaitez plus de détails sur le fonctionnement de cette méthode je vois renvois directement vers la RFC. Dans notre article nous ne verrons que comment mettre tout cela en œuvre au sein d'un l'environnement AMP.

Nous réaliserons l'étude de cas suivante à titre d'exemple :

A souhaite pouvoir charger des fichiers dans le répertoire /upload/ de son site internet via un simple formulaire disponible depuis son navigateur.

Nous utiliserons l'arborescence de la figure 1-1. Le répertoire /upload/ contiendra les fichiers chargés par le visiteur, le fichier /upload.php contiendra le formulaire ainsi que le script PHP permettant le chargement des images. Quand au fichier /.htaccess il pourra nous permettre de modifier certaines valeurs par défaut de PHP un peu gênante que nous verrons plus bas.

Figure 1-1 : Arborescence

Le formulaire HTML

Comme nous l'avons abordé plus haut, l'envoi de fichier via la méthode POST est décrit par la RFC-1867. Comme exposé au sein de la RFC, côté HTML nous devons résoudre 3 impératifs :

que notre formulaire utilise la méthode POST
que l'attribut « enctype » de notre balise « form » prenne la valeur « multipart/form-data »
que le champ accueillant le fichier à envoyer soit de type « file »

Pour résoudre proprement notre étude de cas, nous ajouterons aussi un petit message de retour, pour indiquer si le chargement c'est bien passé, s'il a échoué … Ce message sera géré en PHP et stocké dans la variable $information.

Voici donc une première partie de notre fichier upload.php :

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"

"http://www.w3.org/TR/html4/strict.dtd">

<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=utf8">

<title>Chargement de Fichiers</title>

</head>

<body>

<form method="post" enctype="multipart/form-data">

<p><?php echo $information; ?></p>

<p>

<label for="fichier">Fichier à envoyer :</label>

<input type="file" id="fichier" name="fichier" />

</p>

<p>

<input type="submit" value="Envoyer" />

</p>

</form>

</body>

</html>

Notre formulaire sera donc très simple et ressemblera à quelque chose comme le montre la figure 1-2. Remarquez que le navigateur s'occupe lui-même de proposer un champ parcourable au visiteur pour que celui-ci puisse sélectionner le fichier de son choix.

Figure 1-2 : Le formulaire

Traiter le formulaire en PHP

Maintenant que nous avons rédigé notre formulaire ; nous allons voir comment en lire les données une fois celui-ci envoyé. Si les données traditionnelles envoyées depuis des formulaires avec la méthode POST sont lues la superglobale $_POST ; les choses sont un peu différentes concernant les champs de type file

lors de la validation du formulaire

Lors de la validation du formulaire, le client va envoyer le fichier à l'aide de son navigateur. PHP et apache viendrons alors placer ce fichier dans un répertoire temporaire. C'est l'étape 1 que vous pouvez retrouver sur la figure 2-1.

Ce fichier sera conservé à cet endroit durant toute l'exécution du script uniquement. Une fois le script achevé et pour des raisons de sécurités évidentes le fichier sera supprimé de cet emplacement.

Vous pouvez connaître le nom du répertoire utilisé comme répertoire temporaire via la directive upload_tmp_dir du php.ini. Généralement il s'agit par défaut de /tmp/.

Figure 2-1 : Déplacements du fichier

Comprenez bien que vous devez donc, déplacer le fichier et l'enregistrer ailleurs si vous souhaitez conserver celui-ci après la fin de l'exécution du script. C'est ce que nous allons écrire en PHP.

Dans notre étude de cas, nous voulons stocker nos fichiers dans le répertoire /upload/ ; nous devrons donc déplacer notre fichier du répertoire temporaire pour le placer dans le répertoire /upload/. C'est la deuxième étape représentée sur la figure 2-1.

la super globale $_FILES

Pour lire un les données associés aux champs de type file depuis un script PHP, vous devrez utiliser la superglobale $_FILES. Il s'agit d'un tableau multidimensionnel contenant à son premier niveau, un indice par fichier envoyé via un champ de formulaire de type file. Le nom de l'indice correspond a la valeur de l'attribut « name » de votre formulaire.

Si nous reprenons notre étude de cas, la superglobale $_FILES contiendra donc un indice nommé « fichier ». $_FILES['fichier'] sera donc égal à un tableau contenant un ensemble de valeurs qui nous informera sur le fichier concerné.

Le tableau que vous trouverez dans $_FILES['fichier'], ou dans $_FILES[{n'importe quel fichier}] contiendra les valeurs suivantes :

Indice	Description
name	Le nom original du fichier, tel que sur la machine du client web.
type	Le type MIME du fichier, si le navigateur a fourni cette information. Par exemple, cela pourra être "image/gif". Ce type mime n'est cependant pas vérifié du côté de PHP et, donc, ne prend pas sa valeur pour se synchroniser.
size	La taille, en octets, du fichier téléchargé.
tmp_name	Le nom temporaire du fichier qui sera chargé sur la machine serveur
error	Le code d'erreur associé au téléchargement de fichier. Cet élément a été introduit en PHP 4.2.0

Pour information, sachez que $_FILES n'est utilisé que depuis PHP4.1, avant il fallait utiliser $HTTP_POST_FILES mais considérez ce dernier comme obsolète.

les différentes erreurs

Comme vous venez de le voir, le tableau $_FILES['fichier'] contient un indice « error » qui permet de connaître le statut du téléchargement du fichier associé.

Voici un tableau récapitulatif des valeurs possible que vous pourrez rencontrer :

Constante	Valeur	Description
UPLOAD_ERR_OK	0	Aucune erreur, le téléchargement est correct
UPLOAD_ERR_INI_SIZE	1	Le fichier téléchargé excède la taille de upload_max_filesize, configurée dans le php.ini
UPLOAD_ERR_FORM_SIZE	2	Le fichier téléchargé excède la taille de MAX_FILE_SIZE, qui a été spécifiée dans le formulaire HTML.
UPLOAD_ERR_PARTIAL	3	Le fichier n'a été que partiellement téléchargé
UPLOAD_ERR_NO_FILE	4	Aucun fichier n'a été téléchargé
UPLOAD_ERR_NO_TMP_DIR	6	Un dossier temporaire est manquant. Introduit en PHP 4.3.10 et PHP 5.0.3
UPLOAD_ERR_CANT_WRITE	7	Échec de l'écriture du fichier sur le disque. Introduit en PHP 5.1.0
UPLOAD_ERR_EXTENSION	8	L'envoi de fichier est arrêté par l'extension. Introduit en PHP 5.2.0

le code PHP

Maintenant que nous avons vu ensemble l'essentiel sur ce que vous devait savoir, je vais vous proposer la suite et fin de notre petit exemple : la partie concernant les traitements en PHP. Vous pourrez également trouver l'ensemble des sources concernant notre étude de cas en annexe à ce tutoriel.

Notre traitement en PHP va se diviser en 3 actions simples à réaliser :

vérifier que le formulaire a bien été envoyé
vérifier que le fichier à bien été chargé dans le répertoire temporaire
déplacer le fichier vers le répertoire /upload/

Bien évidement, comme nous l'avons vu lors de la création du formulaire plus haut, tout au long de ces traitements nous prendrons soin en cas d'erreur d'en avertir l'utilisateur final à l'aide de la variable $information.

$upload_path = 'upload/';

if (isset($_FILES['fichier'])) {

if ($_FILES['fichier']['error']===UPLOAD_ERR_OK) {

$filename = $upload_path.$_FILES['fichier']['name'];

if (move_uploaded_file($_FILES['fichier']['tmp_name'], $filename)) {

$information = 'Le fichier à bien été enregistré';

} else {

$information = 'Impossible d\'enregistrer le fichier';

}

} else {

$information = 'Impossible de charger le fichier. Code d\'erreur #'.$_FILES['fichier']['error'];

}

} else {

$information = 'Selectionner le fichier a envoyer';

}

Annexe

informations à connaître

Allez donc faire un tour sur la documentation PHP, et regardez les choses suivantes concernant le chargement de fichier par la méthode POST :

Directives dans le php.ini :

Fonctions à connaître :

Une piste si vous souhaitez implémenter une barre de progression : apc.rfc1867

upload_max_filesize

PHP a besoin d'une limite de taille pour les fichiers envoyés via cette méthode. Généralement dans la plupart des configuration par défaut cette limite peut parfois être trop basse, empêchant ainsi vos utilisateurs de charger des fichiers un minimum conséquents (comme un gros fichier word, ou une image haute définition par exemple).

En théorie ce genre de problème est forcé de vous arriver au moins une fois pendant votre vie. Sachez que vous pouvez vous-même modifier la taille maximum des fichiers via la directive PHP upload_max_filesize.

Pour modifier cette valeur, vous pouvez par exemple la changer depuis un fichier .htaccess placé dans le répertoire contenant votre script PHP. Ajouter simplement les lignes suivantes dans le fichier (xxxxx étant la nouvelle valeur que vous souhaitez attribuer. Il s'agit du nombre d'octet maximum que peut représenter un fichier chargé) :

php_value upload_max_filesize xxxxx

Conclusion

Comme nous avons pu le voir, PHP implémente de façon plus que satisfaisante la RFC-1867 ce qui nous permet, couplé avec du HTML, de proposer aux utilisateurs de nos applications un moyen de pouvoir saisir des fichiers.

Le tout malgré la faiblesse de HTML 4 qui n'implémente aucun support de la méthode HTTP PUT dont le rôle est dédié à la création de nouvelles ressources.

Cependant le support de la méthode PUT est à l'ordre du jour si l'on en crois le brouillon de HTML 5 publié par le W3C. Dans un futur proche, nous pourrions donc implémenté des formulaire avec la méthode PUT au sein de nos pages web sans avoir à ajouter de sur-couche en JavaScript comme c'est le cas actuellement.

Chargement de fichiers (1/3) - Introduction

Méthylbro — Fri, 02 Oct 2009 08:00:00 +0200

Je vais publier à partir d'aujourd'hui et dans les jours qui viennent une série de 3 billets qui ensemble formeront un tutoriel sur le chargement de fichier avec PHP.

L'objectif sera double. Essayer de mieux expliquer aux plus novices le fonctionnement du chargement de fichiers par la méthode POST ; la méthode la plus classique que l'on connaît tous. Mais également faire ouvrir les yeux sur la possibilité de charger des fichiers proprement selon le protocole HTTP : avec la méthode PUT.

En espérant que cette petite série de billets vous plaise et surtout qu'elle vous apprennent des choses intéressante.

Introduction au chargement de fichiers

La plupart des applications que nous avons à produire supposent une certaine interactivité avec les utilisateurs finaux. Ces derniers doivent en effet la plupart du temps saisir toute sortes d'information à un moment donné.

S'il est facile de maîtriser rapidement l'environnement LAMP pour proposer des formulaires simples permettant aux utilisateurs de saisir des chaînes de caractères ; de faire des choix parmi des listes et etc. Il est néanmoins plus complexe de créer des formulaire capables d'offrir à l'utilisateur d'envoyer par exemple des fichiers entiers.

Il faut dire que la méthode généralement proposée par la plupart des tutoriaux traitant du sujet n'arrange pas les choses. Si vous vous êtes penchés sur le protocole HTTP comme je vous l'ai invité à le faire, vous comprendrez certainement qu'utiliser la méthode POST pour de l'envoi de fichiers à quelque chose de quelque peut perturbant.

C'est pourquoi, après avoir revu en profondeur la méthode traditionnelle de chargement de fichiers en PHP nous observerons ensemble comment profiter pleinement des capacités que nous apporte le JavaScript côté client pour palier le non support de la méthode PUT par HTML 4.

Ressources HTTP : Champs d'en-tête et codes de retour

Méthylbro — Thu, 23 Jul 2009 08:00:00 +0200

Après avoir vu ensemble comment fonctionne le protocole HTTP au niveau de ses requêtes et de ses résultats ; et avant de concevoir pas à pas un petit client HTTP entièrement écrit en PHP nous allons faire un petit billet de ressources sur le protocole HTTP.

Dans ce billet j'ai tout simplement listé et classé l'ensemble des champs d'en-tête (de requête et de réponse) que vous pourrez trouvé le plus communément. Bien évidement il ne s'agit pas d'une liste exhaustive car de toute façon il est tout à fait possible pour n'importe qui d'utiliser des champs d'en-tête personnalisés. Pour ma part je laisse régulièrement une signature à mon travail en glissant un petit mot dans les champs de réponse.

J'y ai glissé également à nouveau un tableau très classique. Il s'agit de la liste des codes de retour HTTP (excluant les codes hérités de WebDav).

Les champs d'en-tête HTTP

Les champs de requête
Nom du champ	Description
Accept	Type de contenu accepté par le navigateur (par exemple text/html, ce sont les codes MIME).
Content-Length	Longueur du corps de la requête
Content-Type	Type de contenu du corps de la requête (par exemple text/html).
Date	Date de début de transfert des données
Forwarded	Utilisé par les proxys entre le navigateur et le serveur
From	Permet de spécifier l'adresse e-mail du client
Referer	URL du lien à partir duquel la requête a été effectuée
If-Modified-Since	Dernière date de réception du contenu de la ressource
Host	Nom du serveur/domaine de destination
User-Agent	Chaîne donnant des informations sur le client, comme le nom et la version du navigateur, du système d'exploitation

Les champs de réponses
Nom de l'en-tête	Description
Content-Encoding	Type de codage du corps de la réponse
Content-Language	Type de langage du corps de la réponse
Content-Length	Longueur du corps de la réponse
Content-Type	Type de contenu du corps de la réponse (par exemple text/html).
Date	Date de début de transfert des données
Expires	Date limite de consommation des données
Forwarded	Utilisé par les machines intermédiaires entre le browser et le serveur
Location	Redirection vers une nouvelle URL associée au document
Server	Caractéristiques du serveur ayant envoyé la réponse

Les codes de retour HTTP

Les codes de retour
Information
100	Continue	Attente de la suite de la requête
101	Switching Protocols	Acceptation du changement de protocole
Succès
200	OK	Requête traitée avec succès
201	Created	Requête traitée avec succès avec création d'un document
202	Accepted	Requête traitée mais sans garantie de résultat
203	Non-Authoritative Information	Information retournée mais générée par une source non certifiée
204	No Content	Requête traitée avec succès mais pas d'information à renvoyer
205	Reset Content	Requête traitée avec succès, la page courante peut être effacée
206	Partial Content	Une partie seulement de la requête a été transmise
Redirection
300	Multiple Choices	L'URI demandée se rapporte à plusieurs ressources
301	Moved Permanently	Document déplacé de façon permanente
302	Moved Temporarily	Document déplacé de façon temporaire
303	See Other	La réponse à cette requête est ailleurs
304	Not Modified	Document non-modifié depuis la dernière requête
305	Use Proxy	La requête doit être ré-adressée au proxy
307	Temporary Redirect	La requête doit être redirigée temporairement vers l'URI spécifiée
Erreur du client
400	Bad Request	La syntaxe de la requête est erronée
401	Unauthorized	Accès à la ressource refusé
402	Payment Required	Paiement requis pour accéder à la ressource (non utilisé)
403	Forbidden	Refus de traitement de la requête
404	Not Found	Document non trouvé
405	Method Not Allowed	Méthode de requête non autorisée
406	Not Acceptable	Toutes les réponses possibles seront refusées.
407	Proxy Authentication Required	Accès à la ressource autorisé par identification avec le proxy
408	Request Time-out	Temps d'attente d'une réponse du serveur écoulé
409	Conflict	La requête ne peut être traitée à l'état actuel
410	Gone	La ressource est indisponible et aucune adresse de redirection n'est connue
411	Length Required	La longueur de la requête n'a pas été précisée
412	Precondition Failed	Préconditions envoyées par la requête non-vérifiées
413	Request Entity Too Large	Traitement abandonné dû à une requête trop importante
414	Request-URI Too Long	URI trop longue
415	Unsupported Media Type	Format de requête non-supportée pour une méthode et une ressource données
416	Requested range unsatisfiable	Champs d'en-tête de requête 'range' incorrect.
417	Expectation failed	Comportement attendu et défini dans l'en-tête de la requête insatisfaisable
Erreur du serveur
500	Internal Server Error	Erreur interne du serveur
501	Not Implemented	Fonctionnalité réclamée non supportée par le serveur
502	Bad Gateway ou Proxy Error	Mauvaise réponse envoyée à un serveur intermédiaire par un autre serveur.
503	Service Unavailable	Service indisponible
504	Gateway Time-out	Temps d'attente d'une réponse d'un serveur à un serveur intermédiaire écoulé
505	HTTP Version not supported	Version HTTP non gérée par le serveur

Le protocole HTTP : Les Réponses

Méthylbro — Tue, 21 Jul 2009 08:00:00 +0200

Vendredi dernier, je me suis lancé dans la rédaction d'une nouvelle série d'articles dédiés au protocole HTTP. Après avoir commencé dimanche à parler des requêtes et de tous les éléments qui les composent ; nous allons avoir aujourd'hui comment sont construites les réponses HTTP.

Composition d'un résultat HTTP

Dans le protocole HTTP on peut considérer que les réponses sont construites à peut de choses prés de la même manière que les requête. On pourra ainsi la découper à nouveau en trois parties bien distinctes.

Le code de retour

La première chose que doit indiquer le serveur au client HTTP c'est si sa commande a bien été effectuée. Il s'agit du code de retour donné en première ligne de la réponse. Cette ligne prendra la forme suivante :

HTTP/1.1 200 OK

Reprenant donc la version du protocole utilisé, le code de l'erreur ainsi que sa traduction littérale, ici une réponse favorable indiquant que tout c'est bien passé sans encombres.

Ce chapitre n'est pas destiné à faire la liste de tous les codes d'erreurs qu'il existe. Je réserve ça pour plus tard. Cependant je suis sur que vous connaissez déjà bon nombre de codes d'erreurs. Qui n'a jamais vu dans son navigateur des pages "404" indiquant que le document n'existe pas ? C'est en réalité ici que sont utilisées ces fameux codes ; en voilà l'explication.

En-tête

Les réponse HTTP contiennent elles aussi divers champs d'en-tête. Ces derniers permettent de fournir toute sorte d'informations au client.

Il peut s'agir par exemple du type de serveur HTTP qui a été utilisé pour répondre à la requête (Soit Apache dans mon petit exemple), de la date à laquelle à été générer le document que vous êtes en train de consulter (dans le cas de sites dynamiques) mais on peut y trouver également des informations très intéressante que le serveur fourni au cache de votre navigateur.

Nous verrons la liste de tous les champs possibles dans un chapitre à venir. Mais bien évidement cette liste n'est pas figée. Vous pouvez tout à fait venir rajouter des champs d'en-tête comme vous le souhaitez.

Corps

Bien évidement, le résultat d'une requête doit pouvoir contenir également le document que vous avez demandé. Je dit bien "doit pouvoir", car dans le cas d'une requête avec la méthode HEAD cela ne sera pas le cas.

Le document est donc fourni à la fin du résultat. Il peut s'agir de n'importe quel type de fichier : document html, image, fichier pdf ou que sais-je encore.

Le protocole HTTP : Les Requêtes

Méthylbro — Sun, 19 Jul 2009 08:00:00 +0200

J'ai abordé dans mon billet précédent l'importance et le soin qu'un développeur web doit mettre en oeuvre pour comprendre et maîtriser les différents protocoles qu'il est amené a utilisé.

J'avais, sans doutes à tord, commencé à parler du protocole SMTP dans une première série de billets. Mais je vais essayer de corriger un peu cette erreur en publiant maintenant un chapelet de billets sur le protocole HTTP.

En effet, la maîtrise de ce protocole est essentielle pour appréhender par la suite bon nombre de problématiques. Qu'il s'agisse de sécurité, de sessions, d'AJAX ou d'architectures relativement complexe de type MVC et etc si dès le départ vous n'êtes pas à l'aise à l'emploi de HTTP ; vous ne parviendrez jamais a maîtriser d'autres concepts plus avancés.

HTTP : Un protocole synchrone

A l'instar de beaucoup de protocoles de communication (comme l'IMAP par exemple), HTTP est un protocole synchrone. C'est-à-dire que les deux processus d'envoi de requête et de réception de la réponse s'effectuent de manière synchronisée. Chacune étant en lien avec l'autre.

Jusque là rien de bien nouveau a ce que vous avez sans doutes déjà compris auparavant. Seulement la requête n'est pas seulement constituée de l'adresse de la page que vous souhaitez récupérer. De la même façon la réponse elle contient d'autres informations que le simple fichier (généralement un document html) que le client souhaite téléchargée.

Nous allons donc commencer par voir de quoi son composer les requêtes HTTP. J'expliquerais également le concept de "méthode" au sein du protocole HTTP, et nous verrons rapidement ensemble chacune d'entre elles.

Composition d'une requête HTTP

Comme je l'ai dit précédemment, en HTTP une requête ce n'est pas composé de la simple url que vous souhaitez joindre. En effet il faut fournir au serveur HTTP d'autres paramètres afin que ce dernier puisse répondre à votre sollicitation.

Commande

Avec le protocole HTTP, trois paramètres au minimum sont à fournir afin de pouvoir constituer une requête :

la méthode utilisée
le nom du fichier souhaité
la version du protocole employée

Ces informations doivent être disposées sur la première ligne de votre requête, séparées par un espace comme le montre le petit schéma ci-dessous :

En-tête

Vous venez de le voir sur la petite figure, une requête est aussi constituée d'autres informations. Il s'agit de ce que l'on appelle les champs de requête. C'est un ensemble d'informations facultatives que vous pouvez passer au serveur web.

C'est par exemple grâce aux informations fournies ici que le serveur web peut connaître le navigateur que vous utilisez. Nous verrons dans un autre chapitre quelles sont les informations qui sont acceptées ici.

Corps

Enfin, dernier point, il s'agit du corps de votre requête. Si vous avez déjà manipulé des données de formulaire avec du PHP et du html simple, vous vous êtes sans doutes déjà demandés comment étaient transmises les variables entre le navigateur et le serveur avec la méthode POST. Contrairement aux données circulant avec la méthode GET, ces dernières sont « invisibles » et n'apparaissent pas dans l'url.

C'est ici qu'elles sont transmises. Directement dans le corps de votre requête. Elles prennent la même forme que les variables passées dans le GET ;

variable=valeur&variable2=valeur2

Les méthodes HTTP

En HTTP, les méthodes sont en fait des sortes de commandes. Elles vous permettront de spécifier au serveur le type d'action que vous souhaitez que réalise votre requête.

Il existe cinq méthodes :

Les méthodes HTTP
Méthode	Description
GET	Requête de la ressource située à l'URL spécifiée
HEAD	Requête de la ressource située à l'URL spécifiée (la réponse ne contient que l'entête, et pas le contenu de la ressource)
POST	Envoi de données au programme situé à l'URL spécifiée (le corps de la requête peut être utilisé)
PUT	Envoi de données à l'URL spécifiée (idem POST)
DELETE	Suppression de la ressource située à l'URL spécifiée

Malheureusement en html les formulaires ne supportent pour le moment que les méthodes GET et POST. Il s'agit d'une restriction bien souvent regrettée que l'on pallie généralement avec des surcouches en javascript (avec ce que l'on appelle vulgairement l'AJAX).

Néanmoins l'arrivée du support des méthodes PUT et DELETE par html et un des points abordés dans le document de travail de HTML5.

A venir : Introduction au protocole HTTP

Méthylbro — Fri, 17 Jul 2009 08:00:00 +0200

La semaine dernière, au fil d'une discussion avec le responsable technique d'un site de vente en ligne basé à Toulouse je me suis aperçu que la méconnaissance (ou plutôt ici la mal-connaissance) du protocole HTTP est une affliction bien plus large est généralisée que je ne le pensais jusqu'à présent.

Je sait que l'excellent Julien Pauli est en train de rédiger un article dédié au protocole HTTP qui sera sans doutes bien plus clair et complet que tout ce que je pourrais jamais écrire à ce sujet (cela fait un moment qu'il en fait allusion sur son blog).

Néanmoins en attendant la sortie de cet article je vais essayer de faire un rapide synthèse du minimum requis pour réellement comprendre le protocole HTTP. Ou du moins, du minimum pour vous donner le goût et l'envie de vous y pencher dessus plus en détail.

HTTP est sans doutes l'un des protocoles réseaux les plus simples à comprendre et pourtant il est parmi les protocoles les plus ignorés par les débutants et les amateurs (voire même par certains qui se disent professionnels).

Il y a quand même un point que tout le monde à bien compris au sujet du protocole HTTP, c'est qu'il est question d'un protocole orienté client/serveur. Le plus simplement du monde, le client envoie une requête au serveur et celui-ci lui retourne la ressource correspondante.

Oui mais voilà, la requête ne se limite pas à la simple url ; comme vous pouvez l'apercevoir dans un navigateur. La réponse elle, ne se limite pas au document html, ou à tout autre type de document.

Nous verrons donc, donc une série d'articles à venir de quoi son composer les requêtes et les réponse HTTP lors de ce dialogue client/serveur. On s'attardera par exemple sur les champs d'en-tête à connaître, ou sur les codes d'erreurs les plus courants. Pour finir même, nous verrons comment créer un petit client HTTP directement avec PHP.

Le protocole SMTP

Méthylbro — Wed, 01 Jul 2009 08:00:00 +0200

Comme pour beaucoup de choses en PHP ; pour bien saisir les points faible d'une méthode par rapport à une autre ; il faut avant tout maîtriser le sujet que l'on traite. Ici il s'agit de l'envoi de courrier électronique et donc implicitement de l'utilisation du protocole SMTP (Simple Mail Transfert Protocol).

Comme son nom l'indique ; le protocole SMTP est très simple. Il est même parmi les protocoles les plus simple à comprendre. Il suffit simplement de signaler au serveur SMTP qui est l'émetteur d'un message, quel est son destinataire et de rédiger enfin le dit message et il s'occupe du reste.

C'est ce que fait la fonction mail() de PHP pour vous. Elle se connecte et donne au serveur SMTP défini dans votre php.ini toutes ces informations. Pour mieux comprendre donc comment cette dernière fonctionne ; je vous invite à faire un petit test. Envoyer vous-même ; sans client mail, sans fonction mail, un courrier à l'aide du protocole SMTP.

Comme mes statistiques me signalent que 76,26 % de mes visiteurs sont des utilisateurs de Windows (bouh les vilains) je vais donc réaliser cet exemple sous XP. Nous allons communiquer avec notre serveur SMTP directement en ligne de commande dans le terminal et avec l'aide de telnet.

Sous Windows ; ouvrez donc un nouveau terminal : Démarrer > Exécuter : cmd

La première chose à faire c'est se connecter à un serveur SMTP. Ici je vais utiliser celui d'orange (smtp.orange.fr) mais pour être sur que ce petit test fonctionne chez vous ; je vous conseille d'utiliser le serveur SMTP de votre fournisseur d'accès.

Nous ouvrons donc une connexion avec le serveur SMTP :

telnet smtp.orange.fr 25

Le serveur vous renvoie alors un code 220 ; ce qui signifie que tout c'est bien passé, et que vous avez désormais une connexion établie entre votre poste client et le serveur SMTP.

Une fois correctement connecté à votre serveur SMTP ; il faut commencer par s'identifier. C'est le rôle de la commande EHLO (anciennement HELO).

Dans notre exemple ; nous allons nous déclarer comme un utilisateur inconnu ; cela n'a que peut d'importance pour le moment (surtout sur un serveur SMTP public).

EHLO unknown

Une fois cette commande exécutée, le serveur nous retourne un code 250 (OK) pour nous dire que tout c'est bien passé.

Nous disposons donc désormais d'une connexion prête à l'emploi pour envoyer un message à notre serveur SMTP.

Afin de pouvoir envoyer un message ; nous allons devoir fournir à notre serveur SMTP trois informations :

l'adresse de l'émetteur du message
l'adresse du ou des destinataires du message
le contenu du message

Commençons donc par les coordonnées de l'émetteur du message. Vous devez utiliser la commande MAIL FROM pour les indiquer au serveur ; par exemple :

MAIL FROM:<methylbro@titaxium.org>

Si tout se passe bien ; que vous avez saisie l'adresse correctement, le serveur SMTP devrait à nouveau vous retourner un code 250 (OK) pour vous dire que tout c'est bien passé.

De la même façon que pour l'émetteur du message ; nous devons maintenant spécifier le ou les destinataires. Pour cela nous devons utiliser la commande RCPT TO. Vous pouvez l'utiliser autant de fois que vous avez de destinataires.

RCPT TO:<methylbro@forumfr.com>

Si tout se passe bien ; que vous avez saisie l'adresse correctement, le serveur SMTP devrait à nouveau vous retourner un code 250 (OK) pour vous dire que tout c'est bien passé.

Maintenant il ne nous reste plus qu'à indiquer le contenu du message que l'on souhaite envoyer.

Pour ce faire nous devons utiliser la commande DATA. La commande DATA va nous laisser rédiger le contenu de notre message jusqu'à ce que le serveur reçoive la pseudo commande <CR><LF>.<CR><LF>

DATA

Bonjour !

.

Une fois le contenu du message envoyé au serveur SMTP ; celui-ci va nous répondre que le message à bien été pris en compte et qu'il a été mis en file d'attente avant envoi. On peut donc considérer que le message à bien été envoyé.

On peut donc clore la connexion ouverte entre le client et le serveur SMTP. Pour cela ; on utilise la commande QUIT.

QUIT

Lors du développement de vos script PHP il est en effet plus agréable d'utiliser la fonction mail() ; qui propose une véritable interface simple d'utilisation plutôt que d'avoir à réaliser soit même toutes ces opérations (ouverture d'un socket, transaction avec le serveur SMTP …).

Malheureusement cette fonction possède bon nombre d'inconvénient. En termes de sécurité tout d'abord ; car sur un script mal conçue, rien n'empêche les injections. Mais également en termes de consommation de ressources dans le cadre d'un envoi en masse de courriers ; pour de l'emailling par exemple.

Pour plus d'informations sur le protocole SMTP, je vous conseille de lire la RFC 2821. Vous pourrez en trouver une traduction francaise sur le site abcdrfc.free.fr.

PHP : Stocker sa configuration dans une session

Méthylbro — Thu, 25 Jun 2009 08:30:00 +0200

De prime abord, cette idée peut paraitre saugrenue. Quelle peut être l'intérêt de stocker des variables de configuration au sein d'une session ?

J'avoue que je n'en ai absolument aucune idée. Ne me jetez pas la pierre, je cherchais juste un bon exemple pour montrer que l'on peut enregistrer des variables de configuration n'importe ou avec un minimum d'abstraction.

De prime abord, cette idée peut paraitre saugrenue. Quelle peut être l'intérêt de stocker des variables de configuration au sein d'une session ?

La classe Session_ConfigurationHandler


class Session_ConfigurationHandler extends ConfigurationHandler implements iConfigurationHandler {



private $array_access;



public function __construct($array_access, $auto=null) {

parent::__construct($auto);



if (strlen(session_id())<=0) throw new Exception('need a valid SID resource');

$r = (!session_is_registered($array_access))

? (session_register($array_access))

? true

: new Exception('failed to define \''.$array_access.'\'')

: new Exception('\''.$array_access.'\' is already defined');

if ($r instanceof Exception) throw $r;

}



public function load() {

$this->setData($_SESSION[$this->array_access]);

return $this;

}



public function save() {

$_SESSION[$this->array_access] = $this->getData();

return $this;

}



}

PHP : Stocker sa configuration dans une base de données

Méthylbro — Tue, 23 Jun 2009 08:30:00 +0200

Nous venons de voir dans un billet précédant comment manipuler facilement des variables de configuration à l'aide d'un fichier .ini. Mais comme je l'ai expliqué dans le billet d'introduction à ce sujet, dans certains cas nous pourrions très bien vouloir stocker autrement ces informations.

Aujourd'hui nous allons voir comment, avec la même méthodologie, avec les mêmes classes et interfaces de base nous pouvons étendre notre petite librairie à l'utilisation de base de données.

La classe DataBase_ConfigurationHandler

Pour ce faire, il faudra indiquer à la classe Configuration comment elle doit lire et enregistrer les informations qu'elle manipule.

Il suffit donc de reprendre la classe abstraite ConfigurationHandler au sein d'une nouvelle classe (que nous appellerons ici DataBase_ConfigurationHandler) et de lui implémenter également les méthodes de l'interface iConfigurationHandler.

On se retrouve donc avec un nouvel objet de type ConfigurationHandler capable de lire et d'écrire dans une base de données.


class DataBase_ConfigurationHandler extends ConfigurationHandler implements iConfigurationHandler {



private $column_name;

private $column_value;

private $table;

private $_PDO;



public function __construct($colname, $colvalue, $table, $PDO, $auto=false) {

parent::__construct($auto);

$this->column_name = $colname;

$this->column_value = $colvalue;

$this->table = $table;

$this->_PDO = $PDO;

}



public function load() {

$sql = "SELECT `".$this->column_name."`, `".$this->column_value."` "

. "FROM `".$this->table."`;";

$PDOStatement = $this->_PDO->query($sql);

while($row = $PDOStatement->fetch(PDO::FETCH_ASSOC)) {

$this->setData($row[$this->column_name], $this->column_value);

}

return $this;

}



public function save() {

$arr = array();

$sql = "TRUNCATE TABLE `".$this->table."`;";

$this->_PDO->exec($sql);

$sql = "INSERT INTO `".$this->table."` "

. "(`".$this->column_name."`, `".$this->column_value."`) VALUES ";

foreach($this->data as $name => $value) $arr[] = "('".$name."', '".$value."')";

$sql.= implode(', ', $arr);

$this->_PDO->exec($sql);

return $this;

}



}

La table CONFIGURATION

Dans un second temps nous allons créer une table simple au sein d'une base de données qui contiendra les valeurs de chaque variables de configuration que nous allons utiliser :


CREATE TABLE `CONFIGURATION` (

`name` varchar(255) NOT NULL,

`value` blob NULL,

PRIMARY KEY (`name`)

)TYPE=MyISAM;



INSERT INTO `CONFIGURATION` (`name`, `value`) VALUES ('bonjour', 'hello world !'), ('foo', 'bar');

Exemple d'utilisation

Pour finir il ne reste plus qu'a utiliser notre nouvelle classe. Rien de plus simple car grâce au l'interface iConfigurationHandler c'est toujours les mêmes méthodes que l'on utilise.


$PDO = new PDO();

$maMethode = new DataBase_ConfigurationHandler('name', 'value', 'CONFIGURATION', $PDO);

$maConfiguration = new Configuration($maMethode);



echo $maConfiguration->bonjour;

/*

* Affichera :

* hello world !

*/

echo $maConfiguration->foo;

/*

* Affichera :

* bar

*/



$maConfiguration->bonjour = 'coucou !';

$maMethode->save();

PHP : Stocker sa configuration dans un fichier ini

Méthylbro — Sun, 21 Jun 2009 08:30:00 +0200

Maintenant que vous savez comment gérer vos variables de configuration en PHP avec une classe et que vous êtes capable de stocker ces dernières de différentes manière. Nous allons voir comment les enregistrer au sein d'un fichier ini.

Comme je l'ai déjà dit, ce format sera plus efficace, car l'on pourra lire et écrire plus facilement les données concernées.

Nous allons voir aujourd'hui un exemple de classe héritant de la classe abstraite ConfigurationHandler ainsi que l'interface iConfigurationHandler que nous avons déjà vu dans un billet précédant.

Il suffit juste d'indiquer comment doivent se lire et s'enregistrer les différentes variables de configuration dans le fichier .ini.


class IniFile_ConfigurationHandler extends ConfigurationHandler implements iConfigurationHandler {



private $file;



public function __construct($file, $auto=false) {

parent::__construct($auto);

$r = (file_exists($file) && is_file($file))

? (is_readable($file) && is_writable($file))

? $this->file = $file

: new Exception('failed to open stream: Permission denied')

: new Exception('failed opening \''.$file.'\': No such file');

if ($r instanceof Exception) throw $r;

}



public function load() {

$this->setData(parse_ini_file($this->file, false));

return $this;

}



public function save() {

$str = null;

foreach($this->data as $name => $value) {

$str.= $name.' = '. ((is_int($value))

? $value

: (is_bool($value))

? ($value) ? 'On' : 'Off'

: '"'.$value.'"').PHP_EOL;

}

file_put_contents($this->file, $str);

return $this;

}



}

Ainsi, pour dire à notre classe Configuration qu'elle doit lire et enregistrer ses valeurs dans le fichier config.ini, nous l'utiliserons désormais de la façon suivante :


$maMethode = new IniFile_ConfigurationHandler('config.ini');

$maConfiguration = new Configuration($maMethode);



$maConfiguration->maVariable = 'Hello World !'; 

$maConfiguration->foo = 'bar';



$maMethode->save();