Il semble que mon serveur cpanel / WHM ait probablement été configuré (bien que je ne sache pas quelle en est la cause) avec certains parameters de sécurité, alors que PHP ne reçoit pas les données de formulaire envoyées par d’autres domaines / ordinateurs / périphériques …
J’ai testé le vidage de $ _REQUEST (et aussi de _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ juste juste au cas où) pour les données de post où l’origine provient du serveur à partir d’un autre périphérique.
J’ai également essayé le réglage CORS tout en en- header("access-control-allow-origin: *");
PHP header("access-control-allow-origin: *");
J’ai aussi mis en .htaccess à la fois dans le répertoire parent et dans le répertoire du jeu d’en-têtes php Header set Access-Control-Allow-Origin "*"
comme un test de santé mentale, je l’ai essayé avec php barebones, pas de cookies. ceci n’imprimera que si le script envoyant des variables <?php print_r($_REQUEST)
provient du même serveur, mais ne fonctionnera pas s’il est ailleurs <?php print_r($_REQUEST)
Réponse en-tête du client:
Y a-t-il un moyen de ne pas s’arrêter mais d’ autoriser la publication de données à partir de n’importe quelle source ?
(Également pour une vérification de la santé mentale, testez le script client de la publication de périphérique à distance sur le serveur pour travailler sur https://posttestserver.com/ – il est donc clair que le serveur PHP n’accepte pas les champs de publication)
Apparemment, dans Unity 2017.3.0f3, request.chunkedTransfer
(à partir de request = new UnityWebRequest
) est défini sur true, la valeur false permet aux variables de stream d’entrée php: // de passer.
Cependant, en fonction de la façon dont vous encodez le formulaire, $ _REQUEST et $ _POST sont toujours des tableaux nuls jusqu’à request.SetRequestHeader("Content-Type", "application/x-www-form-urlencoded");
est ajouté…
request.chunkedTransfer = false; // cela pourrait fonctionner si vous utilisez WWWForm request.SetRequestHeader ("Content-Type", "application / x-www-form-urlencoded");