Il y a un troisième cas, tu sais. !isset($_REQUEST['s']).
Franz
5
Dans quelle mesure est-il important que d'autres personnes comprennent clairement votre code? POST et GET sont explicites, alors que REQUEST peut provenir de différentes sources. Je pense que l'efficacité est négligeable puisque les superglobales REQUEST, POST et GET sont toujours chargées pour chaque requête.
Kevin
Réponses:
273
$_REQUEST, par défaut, contient le contenu de $_GET, $_POSTet $_COOKIE.
Mais ce n'est qu'un défaut, qui dépend de variables_order; et pas sûr de vouloir travailler avec les cookies.
Si je devais choisir, je n'utiliserais probablement pas $_REQUEST, et je choisirais $_GETou $_POST- en fonction de ce que mon application doit faire (c'est-à-dire l'un ou l'autre, mais pas les deux) : de manière générale:
Vous devez utiliser $_GETlorsque quelqu'un demande des données à votre application.
Et vous devez utiliser $_POSTlorsque quelqu'un pousse (insère ou met à jour ou supprime) des données dans votre application.
Dans tous les cas, il n'y aura pas beaucoup de différence sur les performances: la différence sera négligeable par rapport à ce que fera le reste de votre script.
Idéalement, vous devriez toujours pouvoir utiliser $ _REQUEST. Mais ce n'est bien sûr qu'un monde parfait.
Tyler Carter
2
$ _REQUEST est censé être (ou du moins était) plus cher que d'utiliser directement $ _POST et $ _GET.
Darrell Brogdon
3
+1 pour le concept de différence de performance négligeable et la perspective de maintenance étant plus importante: $ _GET et $ _POST véhiculent un sens d'une manière que $ _REQUEST ne peut pas.
Jon Cram
9
L'utilisation de $ _REQUEST ne provoque pas XSS / XSRF. Ne pas comprendre les nuances de XSS / XSRF provoque XSS / XSRF. Tant que vous atténuez avec des jetons, il n'y a pas de problème ET vous bénéficiez des avantages de l'utilisation de $ _REQUEST (toutes vos variables sont dans une superglobale). En fait, je reconstruis $ _REQUEST avant de l'utiliser sur la base des autres superglobales à cause de 'variables_order'. Je traite $ _COOKIE, puis $ _GET, puis $ _POST. De cette façon, les variables POST ont la priorité la plus élevée et les variables cookie ont la plus basse, ce qui me permet de corriger implicitement un certain nombre de bogues (par exemple Adobe Flash et les guillemets magiques).
CubicleSoft
c'est dans le nom, Get = get from, Post = post to
Grumpy
32
GET vs POST
1) GET et POST créent tous deux un tableau (par exemple, tableau (clé => valeur, clé2 => valeur2, clé3 => valeur3, ...)). Ce tableau contient des paires clé / valeur, où les clés sont les noms des contrôles de formulaire et les valeurs sont les données d'entrée de l'utilisateur.
2) GET et POST sont traités comme $ _GET et $ _POST. Ce sont des superglobales, ce qui signifie qu'elles sont toujours accessibles, quelle que soit leur portée - et vous pouvez y accéder à partir de n'importe quelle fonction, classe ou fichier sans rien faire de spécial.
3) $ _GET est un tableau de variables passées au script courant via les paramètres URL.
4) $ _POST est un tableau de variables passées au script courant via la méthode HTTP POST.
Quand utiliser GET?
Les informations envoyées depuis un formulaire avec la méthode GET sont visibles par tous (tous les noms et valeurs de variable sont affichés dans l'URL). GET a également des limites sur la quantité d'informations à envoyer. La limitation est d'environ 2000 caractères. Cependant, comme les variables sont affichées dans l'URL, il est possible de mettre la page en signet. Cela peut être utile dans certains cas.
GET peut être utilisé pour envoyer des données non sensibles.
Remarque: GET ne doit JAMAIS être utilisé pour envoyer des mots de passe ou d'autres informations sensibles!
Quand utiliser POST?
Les informations envoyées depuis un formulaire avec la méthode POST sont invisibles pour les autres (tous les noms / valeurs sont incorporés dans le corps de la requête HTTP) et n'ont aucune limite sur la quantité d'informations à envoyer.
De plus, POST prend en charge des fonctionnalités avancées telles que la prise en charge de l'entrée binaire en plusieurs parties lors du téléchargement de fichiers sur le serveur.
Cependant, comme les variables ne sont pas affichées dans l'URL, il n'est pas possible de mettre la page en signet.
Veuillez également ajouter quelque chose à propos de REQUEST.
Black Mamba
Et pour $ _REQUEST?
Aamir Kalimi
22
$ _GET récupère les variables de la chaîne de requête ou de votre URL.>
$ _POST récupère les variables d'une méthode POST, comme (généralement) les formulaires.
$ _REQUEST est une fusion de $ _GET et $ _POST où $ _POST remplace $ _GET. Bon à utiliser $ _REQUEST sur les formulaires d'auto-référence pour les validations.
+1 C'est essentiellement ce qu'on m'a appris. Pas technique comme les autres réponses, mais beaucoup plus facile à retenir (à GETpartir de la chaîne de requête, POSTde la soumission du formulaire).
jp2code
18
Je suggère d'utiliser $_POSTet $_GETexplicitement.
L'utilisation de $ _REQUEST devrait de toute façon être inutile avec une conception de site appropriée, et elle présente certains inconvénients, comme vous laisser ouvert à des CSRF/XSSattaques plus faciles et à d'autres bêtises résultant du stockage de données dans l'URL.
La différence de vitesse doit être minimale dans les deux cas.
Bonne réponse, avec la mise en garde que dans de nombreuses situations, un GET ou un POST doit être choisi en fonction de la situation au lieu d'utiliser l'un ou l'autre.
ceejayoz
3
Vous avez raison que personne ne s'en soucie, mais à mon avis, utiliser $_REQUESTest la mauvaise conclusion. Voyez ma réponse.
Franz
4
pourquoi utiliser $ _REQUEST est plus propre que $ _GET ou $ _POST? $ _REQUEST exécute la même logique en arrière-plan et choisir GET ou POST vous donne plus de contrôle.
Jay Zeng
6
L'affirmation selon laquelle _REQUEST est plus hygiénique nécessite une élaboration.
2
Je vous recommande d'utiliser GET si vous souhaitez que l'utilisateur puisse copier l'URL et effectuer la même opération, c'est-à-dire (l'URL est visible comme 'google.com/q=searchWord' 'tandis que POST doit être utilisé pour publier des données sur un site Web qui ne devrait être inséré qu'une seule fois, ou beaucoup de données sont actives et l'utilisateur ne devrait pas être en mesure de conserver l'URL comme l'insertion de données dans des bases de données, la connexion, etc.
Dean Meehan
7
Ne t'inquiète pas. Mais vous devez toujours utiliser la deuxième solution (plus une vérification supplémentaire pour aucune de ces variables existantes), car il y a des problèmes de sécurité avec $_REQUEST(puisque $_GETet $_POSTne sont pas les seules sources pour ce tableau).
Il y avait un article sur les problèmes d' $_REQUESThier, je crois. Laisse-moi aller le trouver.
Pas du tout une mauvaise solution. Il prend en charge les failles de sécurité associées $_REQUESTmais permet toujours d'accéder au même script dans les deux sens (dans mon cas, le même script est utilisé avec différentes `` actions '' et parfois $ _GET conviendrait, mais d'autres fois j'ai besoin de $ _POST pour cacher / sécuriser les données).
Xandor
4
Il existe certains problèmes de sécurité, car un pirate informatique peut définir un cookie qui remplacera une valeur $ _POST ou $ _GET. Si vous gérez des données sensibles, je ne recommanderais pas d'utiliser $ _REQUEST. - Xandor
tu ne peux pas être utilisé $_GET alternative $_POSTsur certains cas.
Quand ??
lorsque vous souhaitez télécharger un fichier.
lorsque vous ne souhaitez pas afficher de données dans l'URL.
GETa également des limites sur la quantité d'informations à envoyer. La limitation est d'environ 2000 caractères.
Autre chose, il y a peu de cas où vous ne pouvez pas récupérer des données en utilisant $_POST
Quand ?
lorsque les données sont transmises dans l'URL.
Pour le service de repos
`GET`-Provides a read only access to a resource.`PUT`-Used to create a new resource.
il n'y a rien de mal à utiliser $_REQUEST.
Mais la façon de faire est de vérifier explicitement $ _SERVER ['REQUEST_METHOD'], et non de se fier au fait que $ _POST est vide pour un GET.
Bons conseils d'utilisation $_SERVER['REQUEST_METHOD']pour vérifier si le script sera appelé avec l'un ou l'autre. Mais dire que rien ne va $_REQUESTpas n'est pas vrai à 100%. Il existe certains problèmes de sécurité, car un pirate informatique peut définir un cookie qui remplacera une valeur $ _POST ou $ _GET. Si vous gérez des données sensibles, je ne recommanderais pas d'utiliser $_REQUEST.
Xandor
J'ai ajouté votre commentaire dans ma réponse, il fait de l'aide merci
Parth Chavda
3
$ _GET récupère les variables de la chaîne de requête ou de votre URL.>
$ _POST récupère les variables d'une méthode POST, comme (généralement) les formulaires.
$ _REQUEST est une fusion de $ _GET et $ _POST où $ _POST remplace $ _GET. Bon à utiliser $ _REQUEST sur les formulaires d'auto-référence pour les validations.
Le remplacement dépend request_orderet peut également contenir des valeurs de cookie, c'est pourquoi ce n'est pas une fonctionnalité très fiable ni utile.
Ja͢ck
1
J'utiliserais la deuxième méthode car elle est plus explicite. Sinon, vous ne savez pas d'où viennent les variables.
Pourquoi avez-vous quand même besoin de vérifier à la fois GET et POST? Utiliser l'un ou l'autre n'a sûrement plus de sens.
J'ai déjà vu cela, en GETétant utilisé pour un seul élément (par exemple le déplacer) et POSTpour plusieurs d'entre eux (un formulaire avec des cases à cocher ...).
Franz
1
Je n'utilise que _GET ou _POST. Je préfère avoir le contrôle.
Ce que je n'aime pas dans l'un ou l'autre des fragments de code dans l'OP, c'est qu'ils ignorent les informations sur la méthode HTTP utilisée. Et cette information est importante pour la désinfection des entrées.
Par exemple, si un script accepte des données d'un formulaire qui va être entré dans la base de données, le formulaire a intérêt à utiliser POST ( utilisez GET uniquement pour les actions idempotentes ). Mais si le script reçoit les données d'entrée via la méthode GET, il devrait (normalement) être rejeté. Pour moi, une telle situation pourrait justifier l'écriture d'une violation de sécurité dans le journal des erreurs, car c'est un signe que quelqu'un essaie quelque chose.
Avec l'un ou l'autre des fragments de code dans l'OP, cette désinfection ne serait pas possible.
En fait, il est très simple d'écrire une petite page qui publie ce que vous voulez sur une page. Donc, à moins que vous ne vous fiez à l'envoi d'en-têtes de référence, les variables de publication ne sont pas plus sûres que d'obtenir des variables. Je suppose que le plus grand avantage d'un explicite $_POSTest d'empêcher les robots des moteurs de recherche de faire quelque chose comme ceci: thedailywtf.com/Articles/WellIntentioned-Destruction.aspx
Duroth
Je n'ai rien dit du contraire. Ce que j'ai dit, c'est que si le formulaire HTML utilise POST et que le script gère, il reçoit les données du formulaire via GET, le script voudrait en savoir plus et ne pas rejeter ce fait, comme le font les deux exemples de kobra. (Btw: le référent n'est pas sûr non plus.)
1
Je voudrais utiliser $_POST, et $_GETparce que différemment de $_REQUESTleur contenu n'est pas influencé par variables_order.
Quand l'utiliser $_POSTet $_GETdépend du type d'opération en cours d'exécution. Une opération qui modifie les données traitées à partir du serveur doit être effectuée via une requête POST, tandis que les autres opérations doivent être effectuées via une requête GET. Pour faire un exemple, une opération qui supprime un compte utilisateur ne doit pas être exécutée directement après que l'utilisateur a cliqué sur un lien, alors que la visualisation d'une image peut être effectuée via un lien.
l'instruction valide si $ _REQUEST a plus d'un paramètre (le premier paramètre de $ _REQUEST sera l'URI de la requête qui peut être utilisé en cas de besoin, certains packages PHP ne retourneront pas $ _GET alors vérifiez si c'est plus de 1 aller pour $ _GET, par par défaut, ce sera $ _POST.
Vous optimisez prématurément. En outre, vous devriez vraiment réfléchir à la question de savoir si GET doit être utilisé pour ce que vous POST-ing, pour des raisons de sécurité.
N'essayez pas de dire aux gens qu'il y a quelque chose de plus sûr à propos de POST que de GET.
Je n'ai pas. Le point était que leurs utilisations devraient être réfléchies et ne pas être utilisées de manière flagrante de manière interchangeable, car "il est tellement plus facile de taper simplement REQUEST".
Alex Brasetvik
Si vous voulez dire que kobra doit vérifier que les données ont été envoyées en utilisant la méthode prévue, alors je suis d'accord. L'un ou l'autre de ses exemples de code rend ces tests impossibles.
0
C'est moche et je ne le recommanderais pas comme solution finale lors de la transmission du code en direct, mais lors de la création de fonctions de repos, il est parfois pratique d'avoir un capteur de paramètres `` fourre-tout '':
Quelqu'un de création pourrait probablement même y ajouter pour gérer les paramètres de ligne de commande ou tout ce qui provient de votre IDE. Une fois que vous avez décidé de ce que fait une fonction de repos donnée, vous pouvez en choisir une appropriée pour cet appel donné pour vous assurer d'obtenir ce dont vous avez besoin pour la version de déploiement. Cela suppose que «REQUEST_METHOD» est défini.
!isset($_REQUEST['s'])
.Réponses:
$_REQUEST
, par défaut, contient le contenu de$_GET
,$_POST
et$_COOKIE
.Mais ce n'est qu'un défaut, qui dépend de
variables_order
; et pas sûr de vouloir travailler avec les cookies.Si je devais choisir, je n'utiliserais probablement pas
$_REQUEST
, et je choisirais$_GET
ou$_POST
- en fonction de ce que mon application doit faire (c'est-à-dire l'un ou l'autre, mais pas les deux) : de manière générale:$_GET
lorsque quelqu'un demande des données à votre application.$_POST
lorsque quelqu'un pousse (insère ou met à jour ou supprime) des données dans votre application.Dans tous les cas, il n'y aura pas beaucoup de différence sur les performances: la différence sera négligeable par rapport à ce que fera le reste de votre script.
la source
GET vs POST
1) GET et POST créent tous deux un tableau (par exemple, tableau (clé => valeur, clé2 => valeur2, clé3 => valeur3, ...)). Ce tableau contient des paires clé / valeur, où les clés sont les noms des contrôles de formulaire et les valeurs sont les données d'entrée de l'utilisateur.
2) GET et POST sont traités comme $ _GET et $ _POST. Ce sont des superglobales, ce qui signifie qu'elles sont toujours accessibles, quelle que soit leur portée - et vous pouvez y accéder à partir de n'importe quelle fonction, classe ou fichier sans rien faire de spécial.
3) $ _GET est un tableau de variables passées au script courant via les paramètres URL.
4) $ _POST est un tableau de variables passées au script courant via la méthode HTTP POST.
Quand utiliser GET?
Les informations envoyées depuis un formulaire avec la méthode GET sont visibles par tous (tous les noms et valeurs de variable sont affichés dans l'URL). GET a également des limites sur la quantité d'informations à envoyer. La limitation est d'environ 2000 caractères. Cependant, comme les variables sont affichées dans l'URL, il est possible de mettre la page en signet. Cela peut être utile dans certains cas.
GET peut être utilisé pour envoyer des données non sensibles.
Remarque: GET ne doit JAMAIS être utilisé pour envoyer des mots de passe ou d'autres informations sensibles!
Quand utiliser POST?
Les informations envoyées depuis un formulaire avec la méthode POST sont invisibles pour les autres (tous les noms / valeurs sont incorporés dans le corps de la requête HTTP) et n'ont aucune limite sur la quantité d'informations à envoyer.
De plus, POST prend en charge des fonctionnalités avancées telles que la prise en charge de l'entrée binaire en plusieurs parties lors du téléchargement de fichiers sur le serveur.
Cependant, comme les variables ne sont pas affichées dans l'URL, il n'est pas possible de mettre la page en signet.
la source
la source
GET
partir de la chaîne de requête,POST
de la soumission du formulaire).Je suggère d'utiliser
$_POST
et$_GET
explicitement.L'utilisation de $ _REQUEST devrait de toute façon être inutile avec une conception de site appropriée, et elle présente certains inconvénients, comme vous laisser ouvert à des
CSRF/XSS
attaques plus faciles et à d'autres bêtises résultant du stockage de données dans l'URL.La différence de vitesse doit être minimale dans les deux cas.
la source
Utilisez REQUEST. Personne ne se soucie de la vitesse d'une opération aussi simple, et c'est un code beaucoup plus propre.
la source
$_REQUEST
est la mauvaise conclusion. Voyez ma réponse.Ne t'inquiète pas. Mais vous devez toujours utiliser la deuxième solution (plus une vérification supplémentaire pour aucune de ces variables existantes), car il y a des problèmes de sécurité avec
$_REQUEST
(puisque$_GET
et$_POST
ne sont pas les seules sources pour ce tableau).Il y avait un article sur les problèmes d'
$_REQUEST
hier, je crois. Laisse-moi aller le trouver.EDIT : Eh bien, pas directement un post, mais le voici quand même: http://kuza55.blogspot.com/2006/03/request-variable-fixation.html
la source
Utilisez-le car il est plus sûr et ne fera pas de différence de vitesse notable
la source
$_REQUEST
mais permet toujours d'accéder au même script dans les deux sens (dans mon cas, le même script est utilisé avec différentes `` actions '' et parfois $ _GET conviendrait, mais d'autres fois j'ai besoin de $ _POST pour cacher / sécuriser les données).Il existe certains problèmes de sécurité, car un pirate informatique peut définir un cookie qui remplacera une valeur $ _POST ou $ _GET. Si vous gérez des données sensibles, je ne recommanderais pas d'utiliser $ _REQUEST. - Xandor
tu ne peux pas être utilisé
$_GET
alternative$_POST
sur certains cas.Quand ??
GET
a également des limites sur la quantité d'informations à envoyer. La limitation est d'environ 2000 caractères.Autre chose, il y a peu de cas où vous ne pouvez pas récupérer des données en utilisant
$_POST
Quand ?
Pour le service de repos
il n'y a rien de mal à utiliser
$_REQUEST
.Mais la façon de faire est de vérifier explicitement $ _SERVER ['REQUEST_METHOD'], et non de se fier au fait que $ _POST est vide pour un GET.
la source
$_SERVER['REQUEST_METHOD']
pour vérifier si le script sera appelé avec l'un ou l'autre. Mais dire que rien ne va$_REQUEST
pas n'est pas vrai à 100%. Il existe certains problèmes de sécurité, car un pirate informatique peut définir un cookie qui remplacera une valeur $ _POST ou $ _GET. Si vous gérez des données sensibles, je ne recommanderais pas d'utiliser$_REQUEST
.$ _GET récupère les variables de la chaîne de requête ou de votre URL.>
$ _POST récupère les variables d'une méthode POST, comme (généralement) les formulaires.
$ _REQUEST est une fusion de $ _GET et $ _POST où $ _POST remplace $ _GET. Bon à utiliser $ _REQUEST sur les formulaires d'auto-référence pour les validations.
la source
request_order
et peut également contenir des valeurs de cookie, c'est pourquoi ce n'est pas une fonctionnalité très fiable ni utile.J'utiliserais la deuxième méthode car elle est plus explicite. Sinon, vous ne savez pas d'où viennent les variables.
Pourquoi avez-vous quand même besoin de vérifier à la fois GET et POST? Utiliser l'un ou l'autre n'a sûrement plus de sens.
la source
GET
étant utilisé pour un seul élément (par exemple le déplacer) etPOST
pour plusieurs d'entre eux (un formulaire avec des cases à cocher ...).Je n'utilise que _GET ou _POST. Je préfère avoir le contrôle.
Ce que je n'aime pas dans l'un ou l'autre des fragments de code dans l'OP, c'est qu'ils ignorent les informations sur la méthode HTTP utilisée. Et cette information est importante pour la désinfection des entrées.
Par exemple, si un script accepte des données d'un formulaire qui va être entré dans la base de données, le formulaire a intérêt à utiliser POST ( utilisez GET uniquement pour les actions idempotentes ). Mais si le script reçoit les données d'entrée via la méthode GET, il devrait (normalement) être rejeté. Pour moi, une telle situation pourrait justifier l'écriture d'une violation de sécurité dans le journal des erreurs, car c'est un signe que quelqu'un essaie quelque chose.
Avec l'un ou l'autre des fragments de code dans l'OP, cette désinfection ne serait pas possible.
la source
$_POST
est d'empêcher les robots des moteurs de recherche de faire quelque chose comme ceci: thedailywtf.com/Articles/WellIntentioned-Destruction.aspxJe voudrais utiliser
$_POST
, et$_GET
parce que différemment de$_REQUEST
leur contenu n'est pas influencé parvariables_order
.Quand l'utiliser
$_POST
et$_GET
dépend du type d'opération en cours d'exécution. Une opération qui modifie les données traitées à partir du serveur doit être effectuée via une requête POST, tandis que les autres opérations doivent être effectuées via une requête GET. Pour faire un exemple, une opération qui supprime un compte utilisateur ne doit pas être exécutée directement après que l'utilisateur a cliqué sur un lien, alors que la visualisation d'une image peut être effectuée via un lien.la source
Je l'utilise,
l'instruction valide si $ _REQUEST a plus d'un paramètre (le premier paramètre de $ _REQUEST sera l'URI de la requête qui peut être utilisé en cas de besoin, certains packages PHP ne retourneront pas $ _GET alors vérifiez si c'est plus de 1 aller pour $ _GET, par par défaut, ce sera $ _POST.
la source
Vous optimisez prématurément. En outre, vous devriez vraiment réfléchir à la question de savoir si GET doit être utilisé pour ce que vous POST-ing, pour des raisons de sécurité.
la source
C'est moche et je ne le recommanderais pas comme solution finale lors de la transmission du code en direct, mais lors de la création de fonctions de repos, il est parfois pratique d'avoir un capteur de paramètres `` fourre-tout '':
Quelqu'un de création pourrait probablement même y ajouter pour gérer les paramètres de ligne de commande ou tout ce qui provient de votre IDE. Une fois que vous avez décidé de ce que fait une fonction de repos donnée, vous pouvez en choisir une appropriée pour cet appel donné pour vous assurer d'obtenir ce dont vous avez besoin pour la version de déploiement. Cela suppose que «REQUEST_METHOD» est défini.
la source