while (!feof($file)) {
$line = fgets($file, 1024);
/* This only works if the title and its tags are on one line. */
if (eregi("<title>(.*)</title>", $line, $out)) { $title = $out[1];
Vous pouvez aussi écrire des fichiers sur un FTP aussi longtemps que vous êtes connecté avec un utilisateur ayant les bons droits d'accés, alors que le fichier n'existait pas encore. Pour vous connecter avec un user autre qu'un 'anonyme', vous devez spécifier un nom d'utilisateur (et certainement le mot de passe) avec un URL du type 'ftp://user:password@ftp.example.com/path/to/file'.
(Vous pouvez utiliser le même type de syntaxe pour accéder à des fichiers via HTTP lorsqu'ils nécessitent une authentification basique.)
Example 19-2. Stocker des données sur un serveur distant
<?php
$file = fopen("ftp://ftp.php.net/incoming/outputfile", "w");
if (!$file) {
echo "<p>Unable to open remote file for writing.\n";
exit;
Remarque: Vous pouvez avoir l'idée à partir de l'exemple ci-dessus d'utiliser la même tehcnique pour écrire sur un log distant, mais comme mentionner ci-dessus vous ne pouvez qu'écrire sur un nouveau fichier en utilisant les URL fopen() wrappers. Pour faire des log distribués, nous vous conseillons de regarder la partie syslog().
Chapitre 20. Gestion des connexions
Note: Les informations suivantes ne sont valables qu'à partir de la version 3.0.7.
Le statut des connexions est conservé en interne par PHP. Il y a trois états possibles :
0 - NORMAL
1 - ABORTED (Annulé)
2 - TIMEOUT (Dépassé)
Lorsqu'un script PHP travaille, son état est NORMAL. Si le client distant se déconnecte, le status devient ABORTED. En général, une telle déconnexion provient d'un arrêt temporaire. Si la durée maximale d'exécution de PHP est dépassée, (voir
set_time_limit()), le script prend le statut TIMEOUT.
Vous pouvez en outre, décider si vous voulez que la déconnexion d'un client provoque l'arrêt de votre script. Il est parfois pratique de terminer le script, même si il n'y a plus de client pour recevoir les informations. Cependant, par défaut, le script sera
interrompu, et terminé dès que le client se déconnecte. Ce comportement peut être modifié avec la directive ignore_user_abort
dans le fichier php3.ini ou bien avec la directive Apache php3_ignore_user_abort du fichier Apache .conf directive ou avec la fonction ignore_user_abort(). Si vous ne demandez pas à PHP d'ignorer la déconnexion, et que l'utilisateur se déconnecte, le script sera terminé. La seule exception est si vous avez enregistré une fonction de fermeture, avec register_shutdown_function(). Avec une telle fonction, lorsque l'utilisateur annule sa requête, à la prochaine exécution du script, PHP va s'apercevoir que le dernier script n'a pas été terminé, et il va déclencher la fonction de fermeture. Cette fonction sera aussi appelée à la fin du script, si celui-ci se termine normalement. Pour pouvoir avoir un comportement différent suivant l'état du script lors de sa finalisation, vous pouvez exécutez des commandes spécifiques à la déconnexion grâce à la commande connection_aborted(). Cette fonction retournera vrai si la connexion a été annulée.
Votre script peut aussi expirer après un laps de temps. Par défaut, le délai est de 30 secondes. Cette valeur peut être changée en utilisant la directive PHP max_execution_time dans le fichier php3.ini ou avec la directive php3_max_execution_time dans le fichier Apache .conf ou encore avec la fonction set_time_limit(). Lorsque le délai expire, le script est terminé, et comme pour la déconnexion du client, une fonction de finalisation sera appelée. Dans cette fonction, vous pouvez savoir si c'est le délai d'expiration qui a causé la mort du script, en appelant la fonction connection_timeout(). Cette fonction retournera vrai si c'est le délai d'expiration a été dépassé.
Une chose à noter et que les deux cas ABORTED et TIMEOUT peuvent être appelés en même temps. Ceci est possible si vous demandez à PHP d'ignorer les déconnexions des utilisateurs. PHP va quand même noter le fait que l'utilisateur s'est déconnecté, mais le script va continuer. Puis, lorsqu'il atteint la limite de temps, le script va expirer. A ce moment là, les deux fonctions connection_timeout() et connection_aborted() vont retourner vrai. Vous pouvez aussi vérifier les deux états en un seul appel avec la fonction connection_status(). Cette fonction va retourner un champs de bits, avec les états. Si les deux états sont actifs, líétat retourné prendra la valeur 3.
Chapitre 21. Connexions persistantes aux bases de données
Les connexions persistantes aux bases de données SQL sont des connexions qui ne se referment pas à la fin du script. Lorsqu'une connexion persistante est demandée, PHP s'assure qu'il n'y a pas une autre connexion identique (qui serait ouverte précédemment), et si une telle connexion existe, elle est utilisée. Sinon, elle est créée. Une connexion " identique " est une connexion qui a ouvert le même hôte, avec le même nom et même mot de passe (si ils sont nécessaires).
Ceux qui ne sont pas habitués aux techniques des serveurs web et leur distribution de la charge de travail, se font parfois une fausse idée de ces connexions permanentes. En particulier, cela ne permet par l'ouverture de plusieurs sessions avec le même lien, cela ne permet pas la réalisation de transactions efficaces, et cela ne fait pas le café. En fait, pour être extrêmement clair sur le sujet, les connexions persistantes ne vous donnent aucune fonctionnalité de plus qu'avec les connexions non persistantes.
Pourquoi ?
Cela s'explique par la manière avec laquelle les serveurs web fonctionnent. Il y a trois manières d'utiliser PHP pour générer des pages.
La première est d'utiliser PHP comme un CGI (Common Interface Gateway). Lorsque PHP fonctionne de cette manière, une instance de l'interpréteur PHP est créé puis détruit pour chaque page demandée. Etant donné qu'il est détruit après chaque requête, toutes les ressources acquises (comme une connexion à une base SQL), sont purement et simplement détruites.
La deuxième méthode, et de loin, la plus prisée, est d'exécuter PHP sous la forme d'un module sur un serveur multi-process, ce qui revient à dire : Apache. Un tel serveur a typiquement un processus parent qui coordonne un ensemble de processus fils, qui servent les fichiers. Lorsque les requêtes parviennent depuis un client, elles sont transmises à un fils qui n'est pas déjà en train de servir un client. Cela signifie que si un client fait une deuxième requête, il peut être servi par un processus client différent de la première fois. Les connexions persistantes vous permettent alors de ne vous connecter à une base SQL que la première fois. Lors des connexions ultérieures, les processus fils pourront réutiliser la connexion ouverte précédemment.
La dernière méthode est d'utiliser PHP sous la forme d'un plug-in. Pour un serveur multi-thread, actuellement, c'est purement théorique, car PHP ne fonctionne par encore sous cette forme. Le développement est en cours pour supporter ISAPI, WSAPI, et NSAPI (sous Windows), qui permettront d'utiliser PHP comme un plug-in pour des serveurs tels que Netscape FastTrack,
Microsoft's Internet Information Server (IIS), et O'Reilly's WebSite Pro. Lorsque cela sera fait, le comportement sera le même que pour les serveur multi-process.
Si les connexions persistantes n'ont aucune fonctionnalité de plus, à quoi servent-elles ?
La réponse est extrêmement simple : efficacité. Les connexions persistantes sont un bon moyen d'accélérer les accès à une base SQL si le traitement de connexion à la base est long. Ce temps dépend de nombreux facteurs : le type de base de données, cette base est-elle sur le même serveur ou pas, qu'elle est la charge du serveur de base de données, etc... Si le temps de connexion est long, les connexions persistantes seront bien utiles, car une fois ouverte par un processus fils, la connexion est réutilisable sans avoir à se reconnecter. Si vous avez 20 processus fils, il suffit d'avoir 20 connexions persistantes ouvertes, une par fils.
Résumons nous : les connexions persistantes ont été définies pour avoir les mêmes fonctionnalités que les connexions non persistantes. Les deux types de connexions sont parfaitement interchangeables, et n'affecteront pas le comportement de votre script : uniquement son efficacité.
IV. Reference des fonctions PHP
I. Fonction d'accès aux base de données Adabas D II. Fonctions spécifiques à Apache
III. Manipulation des tableaux IV. Fonction Aspell
V. Fonctions de précision mathématiques VI. Calendriers
VII. Fonctions ClibPDF
VIII. Fonctions de date et d'heure
IX. Database (dbm-style) abstraction layer functions X. Fonction dBase
XI. Fonctions dbm XII. Accès aux dossiers
XIII. Chargement dynamique de librairies XIV. Exécution de programmes externes XV. Forms Data Format
XVI. Fonction FilePro
XXII. Options PHP & informations XXIII. Fonctions Informix
XXIV. Fonctions InterBase XXV. Fonctions LDAP XXVI. Email
XXVII. Fonctions mathématiques XXVIII. Fonctions de cryptage XXIX. Fonctions de hash XXX. Fonctions diverses
XXXI. Fonctions d'accès à mSQL
XXXII. Fonctions d'accès à Microsoft SQL Server XXXIII. Fonctions d'accès à MySQL
XXXIV. Fonctions d'accès Sybase XXXV. Fonctions réseau
XXXVI. Fonctions NIS XXXVII. ODBC
XXXVIII. Fonctions d'accès à Oracle 8 XXXIX. Fonctions d'accès à Oracle
XL. Expressions régulières compatibles Perl XLI. Fonctions relatives au format PDF XLII. Fonctions d'accès à PostgreSQL XLIII. Expressions régulières
XLIV. Sémaphores et mémoire partagée XLV. Gestion des sessions
XLVI. Fonctions Solid XLVII. Fonctions SNMP
XLVIII. Gestion des chaînes de caractères XLIX. URL
L. Fonctions sur les variables LI. Fonctions Vmailmgr LII. Fonctions WDDX
LIII. Fonctions de compression LIV. Analyseur de syntaxe XML
I. Fonctions Adabas D
Les fonctions Adabas D sont obsolètes, et vous préférerez sûrement utiliser les Fonctions unifiées ODBC.