J'ai été invité à utiliser la méthode php://input
au lieu d' $_POST
interagir avec les demandes Ajax de JQuery. Ce que je ne comprends pas, c'est les avantages de l'utilisation de cette méthode par rapport à la méthode globale de $_POST
ou $_GET
.
243
Réponses:
La raison en est que
php://input
renvoie toutes les données brutes après les en-têtes HTTP de la demande, quel que soit le type de contenu.Le PHP superglobal
$_POST
, seul est censé envelopper les données qui sont soitapplication/x-www-form-urlencoded
(type de contenu standard pour les messages de formulaire simples) oumultipart/form-data
(principalement utilisé pour les téléchargements de fichiers)En effet, ce sont les seuls types de contenu qui doivent être pris en charge par les agents utilisateurs . Ainsi, le serveur et PHP ne s'attendent généralement pas à recevoir un autre type de contenu (ce qui ne signifie pas qu'ils ne le pourraient pas).
Donc, si vous POSTEZ simplement un bon vieux HTML
form
, la demande ressemble à ceci:Mais si vous travaillez beaucoup avec Ajax, ce probaby comprend également l'échange de données plus complexes avec des types (chaîne, int, bool) et des structures (tableaux, objets), donc dans la plupart des cas, JSON est le meilleur choix. Mais une demande avec une charge utile JSON ressemblerait à ceci:
Le contenu serait maintenant
application/json
(ou du moins aucun des éléments mentionnés ci-dessus), donc$_POST
-wrapper de PHP ne sait pas (encore) comment gérer cela.Les données sont toujours là, vous ne pouvez tout simplement pas y accéder via le wrapper. Vous devez donc le récupérer vous-même au format brut avec
file_get_contents('php://input')
( tant qu'il n'est pasmultipart/form-data
codé ).C'est également ainsi que vous accéderez aux données XML ou à tout autre type de contenu non standard.
la source
application/json
à- dire comme une source de données valide pour le$_POST
tableau. Et il y a même des demandes publiées pour spécifiquement ce support.php://input
peut vous donner les octets bruts des données. Ceci est utile si les données POSTed sont une structure encodée JSON, ce qui est souvent le cas pour une requête AJAX POST.Voici une fonction pour cela:
Le
$_POST
tableau est plus utile lorsque vous manipulez des données de valeur-clé d'un formulaire, soumises par un POST traditionnel. Cela ne fonctionne que si les données POSTed sont dans un format reconnu, généralementapplication/x-www-form-urlencoded
(voir http://www.w3.org/TR/html4/interact/forms.html#h-17.13.4 pour plus de détails).la source
true
tant que second paramètre àjson_decode
, il retournera un tableau associatif.Si les données de publication sont mal formées, $ _POST ne contiendra rien. Pourtant, l'entrée php: // aura la chaîne mal formée.
Par exemple, il existe des applications ajax qui ne forment pas la séquence de valeurs-clés de publication correcte pour télécharger un fichier et qui vident simplement tout le fichier en tant que données de publication, sans nom de variable ou quoi que ce soit. $ _POST sera vide, $ _FILES sera également vide et l'entrée php: // contiendra le fichier exact, écrit sous forme de chaîne.
la source
Tout d'abord, une vérité de base sur PHP.
PHP n'a pas été conçu pour vous donner explicitement une interface de type REST pur (GET, POST, PUT, PATCH, DELETE) pour gérer les requêtes HTTP .
Cependant, la
$_POST
,$_GET
et$_FILES
superglobales , et la fonctionfilter_input_array()
sont très utiles pour les besoins simples / de la personne moyenne.L'avantage caché numéro un de
$_POST
(et$_GET
) est que vos données d'entrée sont urldécodées automatiquement par PHP . Vous ne pensez même jamais à le faire, en particulier pour les paramètres de chaîne de requête dans une demande GET standard.Cependant, vous en apprendrez plus ...
Cela étant dit, à mesure que vous progressez dans vos connaissances en programmation et que vous souhaitez utiliser l'
XmlHttpRequest
objet JavaScript (jQuery pour certains), vous voyez la limitation de ce schéma.$_POST
vous limite à l'utilisation de deux types de supports dans HTTPContent-Type
tête :application/x-www-form-urlencoded
, etmultipart/form-data
Ainsi, si vous voulez envoyer des valeurs de données à PHP sur le serveur et les faire apparaître dans le
$_POST
superglobal , vous devez encoder du côté client et envoyer ces données sous forme de paires clé / valeur - une étape peu pratique pour les novices (en particulier lorsque vous essayez de déterminer si différentes parties de l'URL nécessitent différentes formes de codage d'URL: normal, brut, etc.).Pour tous les utilisateurs jQuery, la
$.ajax()
méthode consiste à convertir votre JSON en paires clé / valeur encodées URL avant de les transmettre au serveur. Vous pouvez remplacer ce comportement en définissantprocessData: false
. Il suffit de lire le $ .ajax () et n'oubliez pas d'envoyer le bon type de média dans l'en-tête Content-Type.Encodage URL? Que diable!!!???
En règle générale, si vous effectuez une requête HTTP normale et synchrone (lorsque toute la page est redessinée) avec un formulaire HTML, l'agent utilisateur (navigateur Web) encodera automatiquement vos données de formulaire pour vous. Si vous souhaitez effectuer une requête HTTP asynchrone à l'aide de l'
XmlHttpRequest
objet, vous devez créer une chaîne codée en url et l'envoyer, si vous souhaitez que ces données s'affichent dans le$_POST
superglobal .Comment êtes-vous en contact avec JavaScript? :-)
La conversion d'un tableau ou d'un objet JavaScript en une chaîne encodée en url dérange de nombreux développeurs (même avec de nouvelles API comme Form Data ). Ils préfèreraient de loin envoyer JSON, et ce serait plus efficace pour le code client de le faire.
Rappelez-vous (clin d’œil, clin d’œil), le développeur Web moyen n’apprend pas à utiliser
XmlHttpRequest
directement objet, les fonctions globales, les fonctions de chaîne, les fonctions de tableau et les expressions régulières comme vous et moi ;-). Le codage url pour eux est un cauchemar. ;-)PHP, qu'est-ce qui donne?
Le manque de PHP de gestion XML et JSON intuitive décourage de nombreuses personnes. On pourrait penser qu'il ferait désormais partie de PHP (soupir).
Tant de types de médias (types MIME dans le passé)
XML, JSON et YAML ont tous des types de médias qui peuvent être placés dans un en-
Content-Type
tête HTTP .Regardez combien de types de médias (anciennement, les types MIME) sont définis par l'IANA.
Regardez combien il y a d'en- têtes HTTP .
php: // entrée ou buste
L'utilisation du
php://input
flux vous permet de contourner le niveau d'abstraction baby-sitting / hand holding que PHP a imposé au monde. :-) Un grand pouvoir implique de grandes responsabilités!Maintenant, avant de traiter les valeurs de données transmises en continu
php://input
, vous devez / devez faire quelques choses.Et l'encodage des caractères?
AH, HA! Oui, vous souhaiterez peut-être que le flux de données envoyé dans votre application soit encodé en UTF-8, mais comment savoir s'il l'est ou non?
Deux problèmes critiques.
php://input
.Allez-vous essayer de gérer les données de flux sans savoir combien il y a d'abord? C'est une terrible idée . Vous ne pouvez pas vous fier exclusivement à l'en-
Content-Length
tête HTTP pour obtenir des conseils sur la taille de l'entrée diffusée, car elle peut être usurpée.Vous allez avoir besoin d'un:
Allez-vous tenter de convertir des données de flux en UTF-8 sans connaître l'encodage actuel du flux? Comment? Le filtre de flux iconv ( exemple de filtre de flux iconv ) semble vouloir un encodage de début et de fin, comme celui-ci.
Ainsi, si vous êtes consciencieux, vous aurez besoin de:
( Mise à jour :
'convert.iconv.UTF-8/UTF-8'
forcera tout à UTF-8, mais vous devez toujours tenir compte des caractères que la bibliothèque iconv peut ne pas savoir traduire. En d'autres termes, vous devez savoir comment définir l'action à entreprendre lorsqu'un caractère ne peut pas être traduit : 1) Insérez un caractère fictif, 2) Échec / lancer et exception).Vous ne pouvez pas vous fier exclusivement à l'en-
Content-Encoding
tête HTTP , car cela pourrait indiquer quelque chose comme la compression comme ci-dessous. Ce n'est pas de cela que vous voulez prendre une décision concernant iconv.Par conséquent, les étapes générales pourraient être ...
Partie I: liée à la demande HTTP
Partie II: Données liées au flux
Partie III: liée au type de données
(N'oubliez pas, les données peuvent toujours être une chaîne codée URL que vous devez ensuite analyser et décoder URL).
Partie IV: Valeur des données liées
Filtrez les données d'entrée.
Validez les données d'entrée.
Voyez-vous maintenant?
Le
$_POST
superglobal, ainsi que les paramètres php.ini pour les limites d'entrée, sont plus simples pour le profane. Cependant, le traitement de l'encodage de caractères est beaucoup plus intuitif et efficace lors de l'utilisation de flux car il n'est pas nécessaire de parcourir les superglobales (ou les tableaux, en général) pour vérifier les valeurs d'entrée pour l'encodage approprié.la source
J'ai donc écrit une fonction qui obtiendrait les données POST du flux d'entrée php: // .
Donc, le défi ici était de passer à la méthode de demande PUT, DELETE OR PATCH et d'obtenir toujours les données de publication envoyées avec cette demande.
Je partage cela peut-être pour quelqu'un avec un défi similaire. La fonction ci-dessous est ce que j'ai trouvé et cela fonctionne. J'espère que ça aide!
la source
Exemple simple d'utilisation
la source