Perte de donn=c3=a9es

Bonjour,

Le 18/10/2018 20:22, Le Fou a écrit :

J'ai un formulaire qui m'envoie une donnée... qui n'arrive jamais !

Le formulaire en HTML (mail.htm) :
<form method="post" enctype="text/plain" action="mail.php">
<input type="text" name="message" size="70">
<input type="submit" value="Envoyer">
</form>

Le PHP qui récupère les données (mail.php) :
<?php
if (isset($_POST['message'])) {
echo 'Votre nom est '.$_POST['message'];
} else {
echo 'Erreur';
}
?>

ça m'affiche toujours Erreur, pourquoi ?

Visible sur http://ffessm.cd84.free.fr/mail.htm

Je ne sais pas ce qui se passe.

Pour investiguer, essaye les choses suivantes :
- utiliser $_REQUEST au lieu de $_POST
- afficher le contenu de $_POST et $_REQUEST dans tous les cas
(c.-à-d. quel que soit le résultat du isset)
- essayer avec la méthode "get" plutôt que "post"
- essayer d'autres valeurs de enctype...

--
Olivier Miakinen

Le 19/10/2018 à 02:20, Olivier Miakinen a écrit :

Bonjour,

Le 18/10/2018 20:22, Le Fou a écrit :

J'ai un formulaire qui m'envoie une donnée... qui n'arrive jamais !

Le formulaire en HTML (mail.htm) :
<form method="post" enctype="text/plain" action="mail.php">
<input type="text" name="message" size="70">
<input type="submit" value="Envoyer">
</form>

Le PHP qui récupère les données (mail.php) :
<?php
if (isset($_POST['message'])) {
echo 'Votre nom est '.$_POST['message'];
} else {
echo 'Erreur';
}
?>

ça m'affiche toujours Erreur, pourquoi ?

Visible sur http://ffessm.cd84.free.fr/mail.htm

Je ne sais pas ce qui se passe.

Pour investiguer, essaye les choses suivantes :
- utiliser $_REQUEST au lieu de $_POST
- afficher le contenu de $_POST et $_REQUEST dans tous les cas
(c.-à-d. quel que soit le résultat du isset)
- essayer avec la méthode "get" plutôt que "post"
- essayer d'autres valeurs de enctype...

Bonjour Monsieur

Le navigateur Chrome a une fonctionnalité qui est de charger les
pages en plusieurs étapes.

Si vous faites ( dans mail.php ) :

if(isset($_POST['message']))
{
$message = $_POST['message'];

$_COOKIE['message'] = $message;
}
elseif(isset($_COOKIE['message']))
{
$message = $_COOKIE['message']
}

if (isset($message))
{
echo 'Votre nom est '.$message;
}
else
{
echo 'Erreur';
}


Ou bien lancement de session et $_SESSION au lieu de $_COOKIE ?

Bien à vous.

Jean François Ortolo

Le 19/10/2018 à 02:20, Olivier Miakinen a écrit :

Bonjour,

Le 18/10/2018 20:22, Le Fou a écrit :

J'ai un formulaire qui m'envoie une donnée... qui n'arrive jamais !

Le formulaire en HTML (mail.htm) :
<form method="post" enctype="text/plain" action="mail.php">
<input type="text" name="message" size="70">
<input type="submit" value="Envoyer">
</form>

Le PHP qui récupère les données (mail.php) :
<?php
if (isset($_POST['message'])) {
echo 'Votre nom est '.$_POST['message'];
} else {
echo 'Erreur';
}
?>

ça m'affiche toujours Erreur, pourquoi ?

Visible sur http://ffessm.cd84.free.fr/mail.htm

Je ne sais pas ce qui se passe.

Pour investiguer, essaye les choses suivantes :
- utiliser $_REQUEST au lieu de $_POST
- afficher le contenu de $_POST et $_REQUEST dans tous les cas
(c.-à-d. quel que soit le résultat du isset)
- essayer avec la méthode "get" plutôt que "post"
- essayer d'autres valeurs de enctype...

C'est "enctype" qui foutait la m...
Sans enctype ça fonctionne;
Avec enctype="application/x-www-form-urlencoded" ça fonctionne;
Avec enctype="multipart/form-data" ça fonctionne;
Avec enctype="text/plain" ça NE FONCTIONNE PAS !

Va comprendre Charles...

Merci.

--
A' tchao

Le Fou
http://shippylelivre.free.fr/
http://ffessm.cd84.free.fr/

Le 19/10/2018 à 12:37, Jean François Ortolo a écrit :

  Bonjour Monsieur

  Le navigateur Chrome a une fonctionnalité qui est de charger les
pages en plusieurs étapes.

  Si vous faites ( dans mail.php ) :

  if(isset($_POST['message']))
  {
    $message = $_POST['message'];

        $_COOKIE['message'] = $message;
  }
  elseif(isset($_COOKIE['message']))
  {
        $message = $_COOKIE['message']
  }

  if (isset($message))
  {
       echo 'Votre nom est '.$message;
   }
   else
   {
       echo 'Erreur';
   }


  Ou bien lancement de session et $_SESSION au lieu de $_COOKIE ?

  Bien à vous.

  Jean François Ortolo

Je n'utilise pas Chrome, mais Firefox.
J'essayerai sous d'autres navigateurs quand ma page sera terminée et
fonctionnelle sous Firefox ;-)

--
A' tchao

Le Fou
http://shippylelivre.free.fr/
http://ffessm.cd84.free.fr/

Le Fou <hiller.Eric@freeE.fr> écrivait :

Va comprendre Charles...

Voir ce qui est compris (donc défini) par le serveur qui peut être
fonction de la déclaration de la page html 4.01, xhtml, htm, html5, etc.
et de ce qu'utilise le serveur : Apache, Nginx, Lihthttpd, etc. et de la
version du serveur et de ses paramètres qui peut très bien ne pas
comprendre certains types MIME.
--
Un ordinateur résout des problèmes que nous n'aurions pas sans lui
Technique aéronautique : http://aviatechno.net

Bonjour,

Le Fou (Fri, 19 Oct 2018 15:59:31 +0200 - fr.comp.lang.php) :

C'est "enctype" qui foutait la m...
Sans enctype ça fonctionne;
Avec enctype="application/x-www-form-urlencoded" ça fonctionne;
Avec enctype="multipart/form-data" ça fonctionne;
Avec enctype="text/plain" ça NE FONCTIONNE PAS !

« application/x-www-form-urlencoded is the default value if the enctype
attribute is not specified. This is the correct option for the
majority of simple HTML forms. »

Si rien n'est spécifié, la valeur par défaut de enctype est
'application/x-www-form-urlencoded'. C'est la bonne option à utiliser
dans la majorité des cas.

« text/plain is a valid option, although it sends the data without any
encoding at all. It is not recommended, as its behavior is difficult
to predict. »

text/plain est une option valide, bien que son utilisation provoque
l'envoi des données sans aucun encodage. Son usage n'est pas
recommandé, car son comportement est difficile à prédire.

(source : https://html.com/attributes/form-enctype/)

En résumé, le seul cas où il soit indispensable de définir la valeur de
enctype est quand des boutons proposant l'upload de fichiers sont
présents dans le formulaire. la valeur d'enctype est alors
'multipart/form-data'.

Dans les autres cas, mieux vaut ne pas le définir, la valeur par défaut
faisant parfaitement l'affaire.

HTH.

Le 20/10/2018 à 08:48, Eric Demeester a écrit :

Bonjour,

Le Fou (Fri, 19 Oct 2018 15:59:31 +0200 - fr.comp.lang.php) :

C'est "enctype" qui foutait la m...
Sans enctype ça fonctionne;
Avec enctype="application/x-www-form-urlencoded" ça fonctionne;
Avec enctype="multipart/form-data" ça fonctionne;
Avec enctype="text/plain" ça NE FONCTIONNE PAS !

« application/x-www-form-urlencoded is the default value if the enctype
attribute is not specified. This is the correct option for the
majority of simple HTML forms. »

Si rien n'est spécifié, la valeur par défaut de enctype est
'application/x-www-form-urlencoded'. C'est la bonne option à utiliser
dans la majorité des cas.

« text/plain is a valid option, although it sends the data without any
encoding at all. It is not recommended, as its behavior is difficult
to predict. »

text/plain est une option valide, bien que son utilisation provoque
l'envoi des données sans aucun encodage. Son usage n'est pas
recommandé, car son comportement est difficile à prédire.

(source : https://html.com/attributes/form-enctype/)

En résumé, le seul cas où il soit indispensable de définir la valeur de
enctype est quand des boutons proposant l'upload de fichiers sont
présents dans le formulaire. la valeur d'enctype est alors
'multipart/form-data'.

Dans les autres cas, mieux vaut ne pas le définir, la valeur par défaut
faisant parfaitement l'affaire.

HTH.

Merci de ces précisions.

--
A' tchao

Le Fou
http://shippylelivre.free.fr/
http://ffessm.cd84.free.fr/

Le 2018-10-20, Eric Demeester nous expliquait dans
fr.comp.lang.php
(<q1jlsdlhuitfbuj04mf4abts8s2s362uqr@4ax.com>) :

Dans les autres cas, mieux vaut ne pas le définir, la valeur par défaut
faisant parfaitement l'affaire.

Si cette variable n'a d'intérêt que pour deux cas quelle peut bien être la
raison pour laquelle il a été décidé de permettre d'autres valeurs _et_
de les documenter ?

Ça semble peu logique.

--
Chez les vieilles qui trafiquent le spleen,
T'as bouffé tes nerfs et tes nuits
Et maintenant tu cherches une combine
Pour domestiquer nos envies.
-- H.F. Thiéfaine, L'homme politique, le rollmops et la cuve à mazout

Le 21/10/2018 12:25, Doug713705 a écrit :

Dans les autres cas, mieux vaut ne pas le définir, la valeur par défaut
faisant parfaitement l'affaire.

Si cette variable n'a d'intérêt que pour deux cas quelle peut bien être la
raison pour laquelle il a été décidé de permettre d'autres valeurs _et_
de les documenter ?

Ça semble peu logique.

Il n'y a que ces deux cas si la cible est une page html, mais text/plain
pourrait être utilisé si la cible est un lien mailto: par exemple.


--
Olivier Miakinen

Le 2018-10-21, Olivier Miakinen nous expliquait dans
fr.comp.lang.php
(<pqhn23$u62$1@cabale.usenet-fr.net>) :

Dans les autres cas, mieux vaut ne pas le définir, la valeur par défaut
faisant parfaitement l'affaire.

Si cette variable n'a d'intérêt que pour deux cas quelle peut bien être la
raison pour laquelle il a été décidé de permettre d'autres valeurs _et_
de les documenter ?

Ça semble peu logique.

Il n'y a que ces deux cas si la cible est une page html, mais text/plain
pourrait être utilisé si la cible est un lien mailto: par exemple.

Il doit me manquer quelqchose car sie je me réfère à
« text/plain is a valid option, although it sends the data without any
encoding at all. It is not recommended, as its behavior is difficult
to predict. »

Même si la cible est un mail, si le comportement n'est pas prédictible,
je n'en vois pas l'intérêt.

Rien de pire qu'un comportement non prédictible.

--
Tu sais comment comment ça jouit, Les mecs complètements stress
Qui t'réclament aux toilettes une p'tite canette, une p'tite fumette,
Une reniflette, une seringuette, Une bonne branlette... Et puis : ciao... dodo.
-- H.F. Thiéfaine, Cabaret Sainte-Lilith