Perte de données

[Le Fou]

Bonsoir,

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

[Olivier Miakinen]

Bonjour,

Post by Le Fou
J'ai un formulaire qui m'envoie une donnée... qui n'arrive jamais !
<form method="post" enctype="text/plain" action="mail.php">
<input type="text" name="message" size="70">
<input type="submit" value="Envoyer">
</form>
<?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...

[Jean François Ortolo]

Post by Olivier Miakinen
Bonjour,

Post by Le Fou
J'ai un formulaire qui m'envoie une donnée... qui n'arrive jamais !
<form method="post" enctype="text/plain" action="mail.php">
<input type="text" name="message" size="70">
<input type="submit" value="Envoyer">
</form>
<?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.
- 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 Fou]

  Bonjour Monsieur
  Le navigateur Chrome a une fonctionnalité qui est de charger les
pages en plusieurs étapes.
  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 ;-)

[Le Fou]

Post by Olivier Miakinen
Bonjour,

Post by Le Fou
J'ai un formulaire qui m'envoie une donnée... qui n'arrive jamais !
<form method="post" enctype="text/plain" action="mail.php">
<input type="text" name="message" size="70">
<input type="submit" value="Envoyer">
</form>
<?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.
- 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.

[Otomatic]

Post by Le Fou
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.

[Eric Demeester]

Bonjour,

Post by Le Fou
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 Fou]

Post by Olivier Miakinen
Bonjour,

Post by Le Fou
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.

[Doug713705]

Le 2018-10-20, Eric Demeester nous expliquait dans
fr.comp.lang.php

Post by Eric Demeester
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.

[Olivier Miakinen]

Post by Doug713705

Post by Eric Demeester
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.

[Doug713705]

Le 2018-10-21, Olivier Miakinen nous expliquait dans
fr.comp.lang.php

Post by Olivier Miakinen

Post by Doug713705

Post by Eric Demeester
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.

[Olivier Miakinen]

Post by Doug713705

Post by Olivier Miakinen
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. »

Le comportement dans une page web n'est pas prédictible, car le html
a un format particulier, dans lequel certains caractères sont réservés
(« < » ou « & » par exemple). Il faut donc encoder ces caractères.

Post by Doug713705
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.

Mais lorsque le lien est mailto, ça ne fait rien d'autre que d'ouvrir
un courrielleur en copiant le contenu dans l'éditeur. Si encodage il
doit y avoir, ce sera fait par le courrielleur au moment où tu vas
cliquer sur son bouton « envoyer ».

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

En fait il faudrait lire les docs de référence (ce que je n'ai pas
fait, et il est trop tard pour que je le fasse maintenant).

Bonne nuit !

[Olivier Miakinen]

Post by Olivier Miakinen
En fait il faudrait lire les docs de référence (ce que je n'ai pas
fait, et il est trop tard pour que je le fasse maintenant).

Dans HTML 4.0, seuls application/x-www-form-urlencoded et
multipart/form-data sont spécifiés, avec une explication pour
les deux, et il est dit que le comportement d'autres valeurs
de enctype est non spécifié :
<https://www.w3.org/TR/html4/interact/forms.html#h-17.13.4>.

Dans HTML 5.3, text/plain est autorisé, mais il est dit la
chose suivante :
<https://www.w3.org/TR/2018/WD-html53-20181018/sec-forms.html#plain-text-form-data%E2%91%A0>
Payloads using the text/plain format are intended to be human readable.
They are not reliably interpretable by computer, as the format is
ambiguous (for example, there is no way to distinguish a literal newline
in a value from the newline at the end of the value).
</>
C'est donc bien ce qui convient à un lien mailto: puisque c'est un
humain qui lira le contenu du courriel avant de le soumettre.

Tout ceci me semble très clair. La seule interrogation qu'il me
reste, c'est où Le Fou a pris son exemple de formulaire avec enctype
en text/plain puisque visiblement ce n'était pas adapté à ce qu'il
voulait faire.

[Le Fou]

Post by Olivier Miakinen
Tout ceci me semble très clair. La seule interrogation qu'il me
reste, c'est où Le Fou a pris son exemple de formulaire avec enctype
en text/plain puisque visiblement ce n'était pas adapté à ce qu'il
voulait faire.

Je ne sais plus sur quel site j'avais trouvé cet exemple, mais c'était
pour faire un formulaire de contact, avec la fonction mail()...
Mais comme je n'arrivais pas à m'envoyer un mail j'avais simplifié au
maximum pour simplement tester la transmission d'une donnée d'une page
(avec le formulaire) à une autre page (PHP qui récupère la donnée).

Mais finalement j'abandonne car la fonction mail() n'envoie absolument
rien...
(page perso d'un compte gratuit de FREE)

[Doug713705]

Le 2018-10-22, Olivier Miakinen nous expliquait dans
fr.comp.lang.php

Post by Olivier Miakinen

Post by Doug713705

Post by Olivier Miakinen
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. »

Le comportement dans une page web n'est pas prédictible, car le html
a un format particulier, dans lequel certains caractères sont réservés
(« < » ou « & » par exemple). Il faut donc encoder ces caractères.

Post by Doug713705
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.

Mais lorsque le lien est mailto, ça ne fait rien d'autre que d'ouvrir
un courrielleur en copiant le contenu dans l'éditeur. Si encodage il
doit y avoir, ce sera fait par le courrielleur au moment où tu vas
cliquer sur son bouton « envoyer ».

Mais si c'est un mailto, alors la balise n'est pas un <form
method='post'> mais <a href='mailto:'>.

Post by Olivier Miakinen

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

En fait il faudrait lire les docs de référence (ce que je n'ai pas
fait, et il est trop tard pour que je le fasse maintenant).

J'ai eu la même flemme mais cette fois je prends mon courage à deux
mains et en consultant https://www.w3schools.com/tags/att_form_enctype.asp
on trouve:

text/plain: Spaces are converted to "+" symbols, but no special
characters are encoded

Du coup, ce n'est pas "difficult to predict".
Ça me rassure.

Post by Olivier Miakinen
Bonne nuit !

Bonne journée :)

[Olivier Miakinen]

Post by Doug713705
Mais si c'est un mailto, alors la balise n'est pas un <form
method='post'> mais <a href='mailto:'>.

Le lien avec <a href> ne permet pas de pré-remplir le message
dans le courrielleur.

Post by Doug713705

Post by Olivier Miakinen
En fait il faudrait lire les docs de référence (ce que je n'ai pas
fait, et il est trop tard pour que je le fasse maintenant).

J'ai eu la même flemme mais cette fois je prends mon courage à deux
mains et en consultant https://www.w3schools.com/tags/att_form_enctype.asp
on trouve: [...]

Sauf que w3schools ce n'est pas ce que j'appelle les docs de référence.
En revanche on y trouve un exemple de formulaire de type "mailto:" :
<https://www.w3schools.com/html/tryit.asp?filename=tryhtml_form_mail>.

[Doug713705]

Le 2018-10-22, Olivier Miakinen nous expliquait dans
fr.comp.lang.php

Post by Olivier Miakinen

Post by Doug713705
Mais si c'est un mailto, alors la balise n'est pas un <form
method='post'> mais <a href='mailto:'>.

Le lien avec <a href> ne permet pas de pré-remplir le message
dans le courrielleur.

Post by Doug713705

Post by Olivier Miakinen
En fait il faudrait lire les docs de référence (ce que je n'ai pas
fait, et il est trop tard pour que je le fasse maintenant).

J'ai eu la même flemme mais cette fois je prends mon courage à deux
mains et en consultant https://www.w3schools.com/tags/att_form_enctype.asp
on trouve: [...]

Sauf que w3schools ce n'est pas ce que j'appelle les docs de référence.

Pas faux.

Post by Olivier Miakinen
<https://www.w3schools.com/html/tryit.asp?filename=tryhtml_form_mail>.

Ah oui, j'avais totalement oublié qu'on pouvait faire ça.
Ça me rappelle mes premiers sites Internet. De véritables horreurs.

Aujourd'hui mettre un formulaire pareil en ligne c'est se faire spammer
sa boite mail à coup sûr.