PHP 6 et la requete de décodage
Du coté PHP
|
|
PHP 6 et la requete de décodage
Des nouvelles de PHP 6 avec l'article de Andrei Zmievski sur son blog, au lieu de vous le commentez, j'ai préféré vous le traduire car il est relativement technique. Des questions restent en suspend en fin de lecture. Comment vont-ils faire pour recuperer les erreurs? Comment gérer les convertions des champs aux variables si un caractère invalide est detecté et retourne une erreur, à quel niveau se trouvera cette erreur? Restez branché!!
Il semble que nous nous sommes finalement mis d'accord sur une approche pour l'entrée HTTP (requete) de décodage en PHP 6. Il n'y a pas eu moins de 4 propositions différentes présentées auparavant, mais celle-ci combine flexibilité, performance, intuition, des changements d'architecture minimaux, et ne possède qu'une paire de petits inconvénients. Regardons de plus près.
Comme vous le savez probablement déjà, déterminer correctement l'encodage des requetes HTTP est en quelque sorte un problème qui n'a toujours pas été résolu. Je ne connais aucun " mainstream clients " envoyant la spécification charset avec la requete. Cela signifie qu'il est laissé au serveur ou à l'application la tâche de trouver l'encodage, ce qui peut se faire de différentes manières, y compris la détection d'encodage, l'étude de l'en-tête Accept-Charset, l'analyse de la requete pour voir si le champ _charset_ est passé, et d'autres. Malheureusement, aucune d'entre elles n'est complètement fiable et le mieux que vous pouvez faire est de deviner l'encodage avec un certain degré de certitude.
L'approche que nous avons choisie est à la base un plan d'évaluation paresseux. Lorsque PHP reçoit la requete, il va simplement la stocker dans le programme, telle quelle, et ne fera aucun décodage de la requete. Cependant, si votre script accède éventuellement aux tableaux $_GET, $_POST, ou $_REQUEST, le pilote JIT du runtime va intervenir et convertir les valeurs du tableau de binaire (brut) en Unicode, basé sur le réglage actuel d'encodage d'entrée HTTP. Cela se fait pour tout le tableau en une fois, non pas élément par élément. Le réglage d'encodage peut être changé au runtime en passant par la fonction au nom proposé de http_input_encoding(). Si l'encodage est changé, le pilote JIT est ré armé et le prochain accès aux tableaux re-convertira les données brutes stockées en Unicode basé sur le nouveau réglage.
Les avantages de cette approche sont nombreux. Un, PHP n'est pas obligé de deviner l'encodage de la requete durant l'étape d'analyse de la requete, qui se déroule avant que le script ne soit exécuté. Ceci permet à l'application de fixer explicitement l'encodage attendu ou de demander à d'autres sources la valeur d'encodage possible. Par exemple, il pourrait y avoir une fonction qui effectue la détection d'encodage sur la requete et renvoie la réponse accompagnée du degré de certitude; ou PHP pourrait analyser la requete et fournir la valeur brute du champ _charset_. Dans les deux cas, il dépend de l'application de fixer l'encodage avant d'accéder aux tableaux de requete. Deux, PHP n'a pas à faire du décodage de requete jusqu'à ce qu'il soit nécessaire de le faire, supprimant le coût initial des scripts qui n'ont pas besoin des tableaux de requete. Trois, dans le cas d'erreurs de conversion, elles sont traitées en utilisant le même mécanisme que PHP emploie pour d'autres conversions d'encodage, permettant à l'application de fixer un pilote d'erreur de conversion personnalisé.
Rasmus a indiqué un problème qui peut se poser avec cette approche. Quelqu'un pourrait essayer d'injecter de fausses données dans la requete, de telle manière que lorsque l'app accède pour la première fois à un tableau de requete, les fausses données déclenchent des erreurs dans le traitement de conversion. Je pense que nous pouvons nous occuper de ce problème d'une manière intelligente, et que les avantages de notre approche contrebalancent les inconvénients. Remarquez que le décodage de la requete n'a rien à voir avec le filtrage. La tâche de l'extension filtre est de valider ou d'assainir les données, et il doit opérer avec les résultats de la conversion de requete, i.e. des chaînes de caractères Unicode.
J'espère que cela aura été une avant-première utile de cette partie très importante de PHP 6. une fois que cette fonctionnalité sera achevée, nous pourrons finalement publier l'avant-première de l' Unicode.
Il semble que nous nous sommes finalement mis d'accord sur une approche pour l'entrée HTTP (requete) de décodage en PHP 6. Il n'y a pas eu moins de 4 propositions différentes présentées auparavant, mais celle-ci combine flexibilité, performance, intuition, des changements d'architecture minimaux, et ne possède qu'une paire de petits inconvénients. Regardons de plus près.
Comme vous le savez probablement déjà, déterminer correctement l'encodage des requetes HTTP est en quelque sorte un problème qui n'a toujours pas été résolu. Je ne connais aucun " mainstream clients " envoyant la spécification charset avec la requete. Cela signifie qu'il est laissé au serveur ou à l'application la tâche de trouver l'encodage, ce qui peut se faire de différentes manières, y compris la détection d'encodage, l'étude de l'en-tête Accept-Charset, l'analyse de la requete pour voir si le champ _charset_ est passé, et d'autres. Malheureusement, aucune d'entre elles n'est complètement fiable et le mieux que vous pouvez faire est de deviner l'encodage avec un certain degré de certitude.
L'approche que nous avons choisie est à la base un plan d'évaluation paresseux. Lorsque PHP reçoit la requete, il va simplement la stocker dans le programme, telle quelle, et ne fera aucun décodage de la requete. Cependant, si votre script accède éventuellement aux tableaux $_GET, $_POST, ou $_REQUEST, le pilote JIT du runtime va intervenir et convertir les valeurs du tableau de binaire (brut) en Unicode, basé sur le réglage actuel d'encodage d'entrée HTTP. Cela se fait pour tout le tableau en une fois, non pas élément par élément. Le réglage d'encodage peut être changé au runtime en passant par la fonction au nom proposé de http_input_encoding(). Si l'encodage est changé, le pilote JIT est ré armé et le prochain accès aux tableaux re-convertira les données brutes stockées en Unicode basé sur le nouveau réglage.
Les avantages de cette approche sont nombreux. Un, PHP n'est pas obligé de deviner l'encodage de la requete durant l'étape d'analyse de la requete, qui se déroule avant que le script ne soit exécuté. Ceci permet à l'application de fixer explicitement l'encodage attendu ou de demander à d'autres sources la valeur d'encodage possible. Par exemple, il pourrait y avoir une fonction qui effectue la détection d'encodage sur la requete et renvoie la réponse accompagnée du degré de certitude; ou PHP pourrait analyser la requete et fournir la valeur brute du champ _charset_. Dans les deux cas, il dépend de l'application de fixer l'encodage avant d'accéder aux tableaux de requete. Deux, PHP n'a pas à faire du décodage de requete jusqu'à ce qu'il soit nécessaire de le faire, supprimant le coût initial des scripts qui n'ont pas besoin des tableaux de requete. Trois, dans le cas d'erreurs de conversion, elles sont traitées en utilisant le même mécanisme que PHP emploie pour d'autres conversions d'encodage, permettant à l'application de fixer un pilote d'erreur de conversion personnalisé.
Rasmus a indiqué un problème qui peut se poser avec cette approche. Quelqu'un pourrait essayer d'injecter de fausses données dans la requete, de telle manière que lorsque l'app accède pour la première fois à un tableau de requete, les fausses données déclenchent des erreurs dans le traitement de conversion. Je pense que nous pouvons nous occuper de ce problème d'une manière intelligente, et que les avantages de notre approche contrebalancent les inconvénients. Remarquez que le décodage de la requete n'a rien à voir avec le filtrage. La tâche de l'extension filtre est de valider ou d'assainir les données, et il doit opérer avec les résultats de la conversion de requete, i.e. des chaînes de caractères Unicode.
J'espère que cela aura été une avant-première utile de cette partie très importante de PHP 6. une fois que cette fonctionnalité sera achevée, nous pourrons finalement publier l'avant-première de l' Unicode.
Ajouter un commentaire
Quelques articles qui devraient vous intéresser
Connexion
Les derniers!
