Avertissement concernant la dépréciation de `$ HTTP_RAW_POST_DATA`


121

Je suis passé à PHP 5.6.0 et maintenant je reçois l'avertissement suivant partout:

Deprecated: Automatically populating $HTTP_RAW_POST_DATA is deprecated and will
be removed in a future version. To avoid this warning set
'always_populate_raw_post_data' to '-1' in php.ini and use the php://input stream
instead. in Unknown on line 0

Warning: Cannot modify header information - headers already sent in Unknown on line 0

Très bien, je compte sur une fonctionnalité obsolète. Sauf que non!

  1. Je n'ai jamais utilisé cette variable dans aucun de mes scripts. Pour être honnête, je ne savais même pas qu'il existe.
  2. phpinfo()montre que j'ai always_populate_raw_post_datamis à 0 (désactivé). Alors, quoi de neuf?

Je ne veux pas "éviter l'avertissement" en définissant cette valeur sur -1. Cela masquera simplement l'avertissement et j'aurai toujours une configuration obsolète. Je veux résoudre le problème à sa source et savoir pourquoi PHP pense que le HTTP_RAW_POST_DATAremplissage est activé.


Le même problème, mais possible cause / solution différente: stackoverflow.com/questions/25984623
...

Cet avertissement me pose des problèmes lors de l'exécution de handle () de PHP SoapServer sur PHP> = 5.6. Cet avertissement sera toujours affiché dans la réponse de SOAP, de sorte que __soapCall () d'un SoapClient obtiendra l'exception "SoapFault exception: [Client] ressemble à nous n'avons pas de document XML". Tellement difficile à déboguer car cet avertissement n'apparaîtra normalement pas.
Johnny Wong

Réponses:


135

Il s'avère que ma compréhension du message d'erreur était erronée. Je dirais qu'il comporte un très mauvais choix de mots. Googler m'a montré que quelqu'un d'autre avait mal compris le message exactement comme je l'ai fait - voir le bogue PHP # 66763 .

Après totalement inutile "C'est comme ça que les MR voulaient que ce soit." réponse à ce bogue par Mike, Tyrael explique que le mettre à "-1" ne fait pas simplement disparaître l'avertissement. Il fait ce qu'il faut , c'est-à-dire qu'il désactive complètement le remplissage de la variable coupable. Il s'avère que l'avoir réglé sur 0 ENCORE remplit les données dans certaines circonstances. Parlez de mauvais design! Pour citer PHP RFC :

Modifiez le paramètre INI always_populate_raw_post_data pour accepter trois valeurs au lieu de deux.

  • -1: le comportement du maître; ne remplissez jamais $ GLOBALS [HTTP_RAW_POST_DATA]
  • 0 / off / peu importe: comportement BC (remplir si le type de contenu n'est pas enregistré ou si la méthode de demande est autre que POST)
  • 1 / on / yes / true: comportement BC (toujours renseigner $ GLOBALS [HTTP_RAW_POST_DATA])

Donc oui, le mettre à -1 évite non seulement l'avertissement, comme le message l'a dit, mais cela désactive également le remplissage de cette variable, ce que je voulais.


23
tl; dr c'est un avertissement stupide qui apparaît même si vous n'utilisez pas la chose contre laquelle il met en garde; définir always_populate_raw_post_data sur -1
srcspider

7
je l'ai mis always_populate_raw_post_data = -1. encore maintenant l'avertissement à venir et corrompant la réponse json
itsazzad

2
Donc, la réponse en fait est d'aller dans votre php.inifichier et de définir (ou de décommenter) always_populate_raw_post_data = -1.
John

Mais je n'ai pas vraiment compris. C'est exactement ce que dit l'avertissement? To avoid this warning set 'always_populate_raw_post_data' to '-1' in php.ini and use the php://input stream instead.
Andreas

@Andreas le point est la raison pour laquelle il est dit que, c'est à dire la différence entre 0, qui est apparemment "désactivé", et -1, qui est ... "plus fort désactivé"? → confusion → raison de cette question (et réponse).
rr-

39

Cela fait un certain temps que je tombe sur cette erreur. Mettez ma réponse pour quiconque pourrait tomber sur ce problème.

L'erreur signifie uniquement que vous envoyez une requête POST vide. Cette erreur se trouve généralement sur les requêtes HTTP sans aucun paramètre passé. Pour éviter cette erreur, vous pouvez toujours ajouter un paramètre au POST sans changer le php.ini.

Comme:

$.post(URL_HERE
    ,{addedvar : 'anycontent'}
    ,function(d){
       doAnyHere(d);
    }
    ,'json' //or 'html','text'
);

4
C'est la meilleure réponse que j'ai trouvée pour ce problème! Je traite ce problème de temps en temps depuis un mois et cela m'a poussé à regarder dans la mauvaise direction. J'avais simplement un POST vide en cas d'accident et une fois que cela a été corrigé, tout fonctionnait très bien! Merci de m'avoir sauvé d'un terrible mal de tête!
Craig Howell

34

J'ai rencontré le même problème sur le serveur nginx (DigitalOcean) - tout ce que j'avais à faire était de me connecter rootet de modifier le fichier /etc/php5/fpm/php.ini.

Pour trouver la ligne avec le always_populate_raw_post_datapremier run grep:

grep -n 'always_populate_raw_post_data' php.ini

Qui a renvoyé la ligne 704

704:;always_populate_raw_post_data = -1

Ensuite, ouvrez simplement php.inisur cette ligne avec l' viéditeur:

vi +704 php.ini

Supprimez le point-virgule pour le décommenter et enregistrez le fichier :wq

Enfin, redémarrez le serveur et l'erreur a disparu.


3
Si la ligne est commentée dans votre, php.inivous utilisez probablement une configuration de développement de php.ini.
BadHorsie

13

Si vous utilisez WAMP ...

vous devez ajouter ou décommenter la propriété always_populate_raw_post_datadans php.iniet définir sa valeur sur -1. Dans mon cas php.iniest situé dans:

C:\wamp64\bin\php\php5.6.25\php.ini

..mais si vous recevez toujours l'avertissement (comme je l'étais)

Vous devez également définir always_populate_raw_post_data = -1dans phpForApache.ini:

C:\wamp64\bin\php\php5.6.25\phpForApache.ini

Si vous ne trouvez pas ce fichier, ouvrez une fenêtre de navigateur et accédez à:

http://localhost/?phpinfo=1

et recherchez la valeur de la clé du fichier de configuration chargé . Dans mon cas, celui php.iniutilisé par WAMP est situé dans:

C:\wamp64\bin\apache\apache2.4.23\bin\php.ini (lien symbolique vers C: \ wamp64 \ bin \ php \ php5.6.25 \ phpForApache.ini)

Enfin, redémarrez WAMP (ou cliquez sur redémarrer tous les services)


6

Si la .htaccess fichier n'est pas disponible, créez-le sur le dossier racine et passez cette ligne de code.

Mettez ceci dans un .htaccessfichier (testé fonctionne bien pour l'API)

<IfModule mod_php5.c>
    php_value always_populate_raw_post_data -1
</IfModule>

2
s'il vous plaît expliquer mon Seigneur
Zohaib

5

Décommenter le

always_populate_raw_post_data = -1 

dans php.ini (ligne # 703) et le redémarrage des services APACHE m'aident quand même à me débarrasser du message

; Always populate the $HTTP_RAW_POST_DATA variable. PHP's default behavior is
; to disable this feature and it will be removed in a future version.
; If post reading is disabled through enable_post_data_reading,
; $HTTP_RAW_POST_DATA is *NOT* populated.
; http://php.net/always-populate-raw-post-data
; always_populate_raw_post_data = -1

4

Pour tous ceux qui ont encore des difficultés avec ce problème après avoir changé le php.init comme le suggère la réponse acceptée. Puisque l'erreur se produit lorsqu'une requête ajax est effectuée via POSTsans aucun paramètre, tout ce que vous avez à faire est de changer la méthode d'envoi en GET.

var xhr = $.ajax({
   url:  url,
   type: "GET",
   dataType: "html",
   timeout: 500,
});

Encore une autre option si vous souhaitez conserver la méthode POSTpour une raison quelconque est d'ajouter un objet JSON vide au petititon ajax.

var xhr = $.ajax({
   url:  url,
   type: "POST",
   data: {name:'emtpy_petition_data', value: 'empty'}
   dataType: "html",
   timeout: 500,
});

4

J'ai reçu ce message d'erreur lors de l'envoi de données à partir d'un formulaire html (méthode Post). Tout ce que j'avais à faire était de changer l'encodage sous la forme de "text / plain" à "application / x-www-form-urlencoded" ou "multipart / form-data". Le message d'erreur était très trompeur.


3

Malheureusement, cette réponse de @EatOng n'est pas correcte . Après avoir lu sa réponse, j'ai ajouté une variable factice à chaque requête AJAX que je tirais (même si certaines d'entre elles avaient déjà des champs) juste pour être sûr que l'erreur n'apparaît jamais.

Mais tout à l'heure, je suis tombé sur la même foutue erreur de PHP. J'ai double-confirmé que j'avais envoyé des données POST (d'autres champs aussi avec la variable factice). Version PHP 5.6.25, la always_populate_raw_post_datavaleur est définie sur0 .

De plus, comme j'envoie une application/jsonrequête, PHP ne la remplit pas $_POST, je dois plutôt json_decode()le corps de la requête POST brut, accessible par php://input.

Comme la réponse de @ rr- le cite,

0 / off / peu importe: comportement BC (à renseigner si le type de contenu n'est pas enregistré ou si la méthode de requête est autre que POST ).

Parce que la méthode de requête est à coup sûr POST, je suppose que PHP n'a pas reconnu / aimé ma Content-Type: application/jsonrequête (encore une fois, pourquoi ??).

OPTION 1:

Modifiez le php.inifichier manuellement et définissez la variable coupable sur-1 , comme le suggèrent de nombreuses réponses ici.

OPTION 2:

Il s'agit d'un bogue PHP 5.6. Mettez à jour PHP.

OPTION 3:

Comme @ user9541305 a répondu ici, changer la Content-Typerequête de AJAX en application/x-www-form-urlencodedou multipart/form-datafera remplir PHP le à $_POSTpartir du corps POSTed (parce que PHP aime / reconnaît ces en- content-typetêtes !?).

OPTION 4: DERNIER RESORT

Eh bien, je ne voulais pas changer le Content-Typed'AJAX, cela causerait beaucoup de problèmes pour le débogage. (Chrome DevTools affiche bien les variables POSTées des requêtes JSON.)

Je développe cette chose pour un client et je ne peux pas leur demander d'utiliser le dernier PHP, ni d'éditer le fichier php.ini. En dernier recours, je vais simplement vérifier si elle est définie sur 0et si oui, modifier lephp.ini je fichier dans mon script PHP lui-même. Bien sûr, je devrai demander à l'utilisateur de redémarrer apache. C'est dommage!

Voici un exemple de code:

<?php

if(ini_get('always_populate_raw_post_data') != '-1')
{
    // Get the path to php.ini file
    $iniFilePath = php_ini_loaded_file();

    // Get the php.ini file content
    $iniContent = file_get_contents($iniFilePath);

    // Un-comment (if commented) always_populate_raw_post_data line, and set its value to -1
    $iniContent = preg_replace('~^\s*;?\s*always_populate_raw_post_data\s*=\s*.*$~im', 'always_populate_raw_post_data = -1', $iniContent);

    // Write the content back to the php.ini file
    file_put_contents($iniFilePath, $iniContent);

    // Exit the php script here
    // Also, write some response here to notify the user and ask to restart Apache / WAMP / Whatever.
    exit;
}

0

Eh bien, s'il y a quelqu'un sur un hébergement partagé et sans accès au php.inifichier, vous pouvez définir cette ligne de code tout en haut de vos fichiers PHP:

ini_set('always_populate_raw_post_data', -1);

Fonctionne plus de la même manière. J'espère que cela fera gagner du temps à quelqu'un pour le débogage :)


0

NB: SI VOUS UTILISEZ PHPSTORM entrez la description de l'image ici


J'ai passé une heure à essayer de résoudre ce problème, pensant que c'était mon problème de serveur php, donc j'ai mis 'always_populate_raw_post_data' à '-1' dans php.ini et rien n'a fonctionné.

Jusqu'à ce que je découvre que l'utilisation du serveur intégré phpStorm est ce qui cause le problème, comme détaillé dans la réponse ici: Réponse de LazyOne Ici , j'ai donc pensé à le partager.


-1

; always_populate_raw_post_data = -1 dans php.init supprimer le commentaire de cette ligne .. always_populate_raw_post_data = -1


4
pourriez-vous expliquer?? Pourquoi ? Aussi, formatez / indentez correctement votre message
Ravi

-1

Je viens de recevoir la solution à ce problème d'un ami. il a dit: Ajoutez ob_start (); sous votre code de session. Vous pouvez ajouter exit (); sous l'en-tête. Je l'ai essayé et cela a fonctionné. J'espère que cela t'aides

Ceci est pour ceux sur un serveur d'hébergement loué qui n'ont pas accès au fichier php.init.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.