gratifiant > comp.lang.* > comp.lang.php

Le Fou (18/10/2018, 20h22)
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
Olivier Miakinen (19/10/2018, 02h20)
Bonjour,

Le 18/10/2018 20:22, Le Fou a écrit :
[..]
> ?>
> ça m'affiche toujours Erreur, pourquoi ?
> Visible sur


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 (19/10/2018, 12h37)
Le 19/10/2018 à 02:20, Olivier Miakinen a écrit :
> Bonjour,
> Le 18/10/2018 20:22, Le Fou a écrit :
> 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 Fou (19/10/2018, 15h59)
Le 19/10/2018 à 02:20, Olivier Miakinen a écrit :
> Bonjour,
> Le 18/10/2018 20:22, Le Fou a écrit :
> 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.
Le Fou (19/10/2018, 16h03)
Le 19/10/2018 à 12:37, Jean François Ortolo a écrit :
[..]
>   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 ;-)
Otomatic (19/10/2018, 16h23)
Le Fou <hiller.Eric> é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.
Eric Demeester (20/10/2018, 08h48)
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 : )

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 (20/10/2018, 19h52)
Le 20/10/2018 à 08:48, Eric Demeester a écrit :
[..]
> 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 (21/10/2018, 12h25)
Le 2018-10-20, Eric Demeester nous expliquait dans
fr.comp.lang.php
(<q1jlsdlhuitfbuj04mf4abts8s2s362uqr>) :

> 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 (21/10/2018, 13h14)
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.
Doug713705 (21/10/2018, 14h45)
Le 2018-10-21, Olivier Miakinen nous expliquait dans
fr.comp.lang.php
(<pqhn23$u62$1>) :

> 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 (22/10/2018, 02h49)
Le 21/10/2018 14:45, Doug713705 a écrit :
>> 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.

> 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 ».

> 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 (22/10/2018, 12h31)
Le 22/10/2018 02:49, j'écrivais :
> 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.
Doug713705 (22/10/2018, 12h35)
Le 2018-10-22, Olivier Miakinen nous expliquait dans
fr.comp.lang.php
(<pqj6qg$1b8t$1>) :

> Le 21/10/2018 14:45, Doug713705 a écrit :
> 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.
> 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:'>.

>> 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
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.

> Bonne nuit !


Bonne journée :)
Olivier Miakinen (22/10/2018, 12h44)
Le 22/10/2018 12:35, Doug713705 a écrit :
> 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.

>> 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
> 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>.

Discussions similaires