Limites du tableau $_POST

Bonjour à tous,

Tout d'abord voici ce que je tente de faire :

Mon formulaire contient un champ textarea (id="text") et lorsque je le poste j'enregistre le contenu du textarea dans une base de donnée (champ type MEDIUMTEXT). Jusque la rien d'inhabituelle...

Seulement lorsque le contenu du textarea dépasse les 65535 caractères, plus rien ne marche sur mon serveur distant alors que sur mon serveur local tout est ok (serveurs ~même config).

La variable $_POST['text'] arrive vide.
J'ai vérifié dans le php.ini la constante post_max_size est fixé à 8M... ce qui est largement suffisant.

Ma question est donc :
y'a t-il d'autres élément de configuration qui limiterai la taille du $_POST ?


Autre souci, provenant probablement du même problème, lorsque j'essaye de mettre à jour directement le champs dans la table avec mon texte cela ne fonctionne pas non plus.

PHP Version 4.4.4-8+etch3


Tout élément de réponse sera le bienvenue :D



Thomas

Bonjour,

Pour moi c' est assez dur de t'aider car cela peut venir de plein de raisons,
le pire est que j'avais eu le même probléme.

Alors j'aimerais que tu me donne dans deux blocs,

Tout ton FORM (trés exactement)
Et toute tta procédrure de récupération

Par ailleur, as tu controlé ceci:

upload_max_filesize : Est a quelle valeur ?

post_max_size : Est'il bien trés supérieur a cette valeur ??

register_argc_argv : a quelle valeur en cas de GET

magic_quotes_gpc : Est' il bien actrivé
tous les caractères ' (guillemets simples), " (guillemets doubles), \ (antislash) et NUL sont échappés avec un antislash.


Bon voila pour le moment

Citation:

---

magic_quotes_gpc : Est' il bien actrivé

---

Il ne faut surtout pas activer ça.
C'est une directive obsolète qui disparaitra definitivement en PHP6.

Citation:

---

Envoyé par sabotage

Il ne faut surtout pas activer ça.
C'est une directive obsolète qui disparaitra definitivement en PHP6.

---

Oui et merci pour l'info, l'Ami

Mais a y regarder de plus pret, la fonction n'existera plus car le choix ne sera plus présent, je veux dire la protection se fera d'office !

Heu... il me semble 8O

Non ce système, qui est actuellement desactivé par défaut, sera retiré purement et entierement.

Citation:

---

Envoyé par sabotage

Non ce système, qui est actuellement desactivé par défaut, sera retiré purement et entierement.

---

Dis moi va falloir faire tout "a la main" pour MYSQL pfffffffffff...
il nous énervent avec leurs versions changeantes ...

Tu me diras il devait y avoir un trou de sécuritée a boucher mais pourquoi ??

Bref j'aurais appris quelque chose merci :D

L'idée de depart des magic_quotes etait de limiter le probleme des injections SQL en protegeant systematiquement tout ce qui venait d'un formulaire.

Malheureusement tout ce qui vient d'un formulaire n'etant pas destiné a aller dans un requete SQL, il fallait retirer tous ces petits slashs dans tous les autres cas.
Tous les serveurs n'activant pas cette option, il fallait donc protéger ou pas et enlever les slash ou pas, selon les cas.

Un veritable casse tête.

Il n'y a pas de "version changeante", cette option a été désamorcée il y a 5 ans déjà avec l'arrivée de PHP5.
Actuellement insérer des variables dans une chaine de requête est de toute facon une méthode dépassée : il faut utiliser PDO et les requetes preparées.

Pffffffff ... tu es dur avec le client l' Ami, :cry:

Je m'étais dit qu' a mon age j' allais passer a travers les mailles du
PHP Data Objects ... Alors c' est cuit, il va falloir que je raprenne encore untruc ! 8O

Notes bien j' aimes ça, mais bon, va falloir bucher ça a fond pour bien comprendre la syntaxe.

En tout cas je n' avais pas vu que PHP6 allait nous imposer ça. :evilred:

Bonne nuit a toi quand même :D

PHP6 ne va pas l'imposer mais fortement l'encourager en releguant les autres méthodes de connexion dans PECL.

Mais PDO s'apprend en quelques instants car il fonctionne evidemment sur les memes principes de query, execute, fetch pour la base tout en proposant plein de choses bien utiles.

Citation:

---

Envoyé par sabotage

PHP6 ne va pas l'imposer mais fortement l'encourager en releguant les autres méthodes de connexion dans PECL.
Mais PDO s'apprend en quelques instants car il fonctionne evidemment sur les memes principes de query, execute, fetch pour la base tout en proposant plein de choses bien utiles.

---

Mais dis moi tu n'es pas encore couché ? 8O

Bon alors tu me tentes, je vais en tester quelques fonctions de base et je verrais bien, de toute façon tu n'y couperas pas, je viendrais t'appeler au secour de temps en temps :oops:

Bon si tu part en dernier cette nuit, éteinds la lumiére en sortant :D:D

Pour en revenir à mon problème :


upload_max_filesize : 8M

post_max_size : 8M

register_argc_argv : on

magic_quotes_gpc : activé



Donc si je comprend bien mon problème viendrai du fait que upload_max_filesize et post_max_size sont à la même valeur ?... 8M on est quand même loin des quelques 70000 caractères que j'essaye d'insérer dans un champs MEDIUMTEXT. Et mon serveur local est configuré de la même façon, cela ne pose pas de problème.


est-ce qu'il serait possible que cela vienne de la configuration de TinyMCE ?


merci de votre aide

Citation:

---

est-ce qu'il serait possible que cela vienne de la configuration de TinyMCE ?

---

Alors moi je trouves tes paramétres IMPEC !!
et le TinyMCE alors vraiment tu ne pourrait rien faire sur ton web ..

reste donc a éplucher comment tu envoies et comment tu reçoit !

Allez donne nous tes codes du FORM complet, et de la réception dans le PHP destinataire 8O

Donner le code complet sera difficile puisque intégré dans un cms.

Au delà de mon code ce qui m'étonne c'est qu'il m'est également impossible d'insérer plus de 65535 caractères dans un champs MEDIUMTEXT et cela en direct dans la base de données (config MySQL ?).


bref, pour le form :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

<form method="post" action="" id="formulaire" name="formulaire"> <input type="hidden" name="id" value="<?php echo $id ?>" /> <input type="hidden" name="func" value="<?php if ($db->f('id')) echo "updateContent"; else echo "addContent"; ?>" /> <input type="hidden" name="page" value="<?php echo $modulename?>/content_form" /> <input type="hidden" name="selected_language" value="<?php echo $currLanguage; ?>" /> <input type="hidden" name="parent_id" value="0" /> <!-- Le champ texte --> <textarea id="text" rows="25" cols="75" name="text"><?php echo $dbLang->f('text'); ?></textarea> <!-- Autres champs, le bouton submit... --> </form>

---

Réception des données

Code:

---

1 2 3 4 5 6 7 8

ini_set("session.use_trans_sid","0"); session_start(); // Le site est en production... if($_SERVER['REMOTE_ADDR'] == 'xxx.xxx.xxx.xxx') { echo '<pre>'.print_r($_POST, true).'</pre>'; // Résultat : $_POST['text'] est vide si le contenu du textarea dépasse 65535 caractères }

---

Ce sont les 4 premières lignes du programme, les traitements suivant ne sont donc pas en cause, ou alors comment ?!

Escuses mon retard j'étais en courses :oops:

Bien je comprends plusieurs choses, dis moi si je me trompes

1) ton

Citation:

---

echo '<pre>'.print_r($_POST, true).'</pre>';

---

affiches bien les autres titres et contenus venant de ton FORM
en particulier celui qui le précéde immédiatement. et celui qui le suit immédiatement.

2) tu dis que dans ta console MYSQL tu ne peux en faisant je supposes un copier collé entrer dans ce champ un texte plus gros !

Voila qui est bien plus troublant, car cela voudrait dire que ton passage de paramétres (tes PHP) n' ont rien a voir avec cette affaire.

Dis moi si je t'ais exactement compris, pendant ce temps je vais faire contrôler certains paramétre sur un de mes serveur a Marseilles. 8O

1) Les champs précédents sont bien contenu dans le $_POST... Les suivants je n'ai pas fait attention... je vais vérifier... oui ils sont bien présents.

2) C'est exactement ça le passage de paramètre php ne semble pas en cause dans mon programme puisque cela ne fonctionne pas non plus avec le passage de paramètre de phpMyAdmin. Voilà pourquoi ma première idée à été de me tourner vers les configurations serveur... Ce qui n'a rien donnée de plus.

Un paramètre/configuration de MySql semble également exclu puisque dans ce cas là, la valeur de mon $_POST['text'] ne serait pas vide, seul l'insertion échouerai...


Je suis vraiment à cour d'idée...

Nouvelle donnée :

J'ai réussi a insérer un texte proche de la limite. Lorsque je veux modifier l'enregistrement (directement dans phpMyAdmin) voici le message qui apparait à coté du champs texte en question :

Citation:

---

Il est possible que ce champ
ne soit pas éditable
en raison de sa longueur

---

Il doit bien y'avoir un paramètre quelque part qui fasse que le POST soit vidé si sa taille est trop longue et que phpMyAdmin réutilise pour afficher l'avertissement !

En tout cas merci de ton aide, ça me permet de pas stagner :D

De mon coté rien de nouveau, sauf que l'avis général est que la frontiére des
65535 caractères reste problématique pffff... 8O

En tout dernier ressort, je penses que tu as testé une saisie type
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
etc... sans accents apostrphes etc ...

D'autre part tu n'a aucun traitements parasites sur ces textes ?

Bref je reste un peut sans pistes désolé :oops:

Je n'avais pas vraiment tester le "aaaaa...", cela m'a permis de voir que le seuil était exactement à 65000 caractères et non 65535 (logiquement supposé ?).

Bon... je sens que des claviers vont voler ! :D

Citation:

---

Envoyé par tomaa

Je n'avais pas vraiment tester le "aaaaa...", cela m'a permis de voir que le seuil était exactement à 65000 caractères et non 65535 (logiquement supposé ?).

Bon... je sens que des claviers vont voler ! :D

---

Oui c'est bien le chiffre que j'avais retenu, du reste, certain éditeurs ont une version multipage quand on dépasse 65000 caractéres

Bon allez A++ :?