Impossible d'accéder aux données HTTP PUT dans le code du service Web

Question

Tous,

Dans le cadre d’une application que j’écris, j’ai besoin d’un service Web HTTP PUT qui accepte les images entrantes, qui seront analysées, validées et ajoutées à un magasin de fichiers local.

Mon problème survient après la validation de la taille en tant que

.

  

$ _ SERVER ['CONTENT_LENGTH']

a un > 0 valeur, et cette valeur est identique à la taille du fichier de test, donc je peux supposer que tout va bien jusqu'à ce point mais lorsque j'essaie de lire les données du flux entrant à l'aide de

.

  

content_get_contents ('php: // stdin');

Je reçois une chaîne vide. J'ai aussi essayé d'utiliser

  

content_get_contents ('php: // input');

Et cela me donne le même résultat d'une chaîne vide.

Toute aide, suggestion ou direction sera appréciée.

NB: j'utilise

• PHP 5.2.6
• Apache 2.0

Answer 1

Ma meilleure hypothèse est que vous devez modifier httpd.conf pour ne pas refuser les demandes PUT. Avez-vous vérifié cela?

Answer 2

Apache HTTPD refuse les demandes PUT par défaut. Vous pouvez vérifier mod_put:
http://perso.ec-lyon.fr/lyonel.vincent/ apache / mod_put.html

et ajoutez ceci à httpd.conf:

<Location /upload/dir>
  EnablePut On
  AuthType Basic
  AuthName "Web publishing"
  AuthUserFile /www/etc/passwd
  AuthGroupFile /www/etc/group
  <Limit PUT>
    require valid-user
  </Limit>
</Location>

Answer 3

content_get_contents ne prend pas le " r " paramètre - voir la page de manuel de PHP :

string file_get_contents  ( string $filename  [, int $flags...)

Les valeurs

valides $ flag sont FILE_USE_INCLUDE_PATH, FILE_TEXT, FILE_BINARY .

Essayez de supprimer le " r " marquer et réessayer

Modifier : la question a été mise à jour, " r " Le drapeau était ignoré, ce qui n’était manifestement pas la racine du problème.

Il semble y avoir un bug signalé dans PHP concernant fichier_get_contents renvoyant une chaîne vide pour un HTTP POST. D'après la description du bogue:

  

content_get_contents ('php: // input') (et aussi le fichier , fopen + fread ) ne   renvoyer les données POST, lorsque le formulaire est soumis avec   enctype = "multipart / form-data".

     

Lorsque le même formulaire est envoyé sans type d’enregistrement spécifié (donc   "application / x-www-form-urlencoded" est utilisé) tout fonctionne bien.

Donc, il semblerait qu’une solution consiste à changer le type de formulaire spécifié en le séparant de multipart / form-data , ce qui n’est évidemment pas idéal pour un téléchargement d’image - à partir de Spécification du formulaire W3 :

  

Le type de contenu "application / x-www-form-urlencoded" est inefficace pour l'envoi de grandes quantités de données binaires ou de texte contenant des caractères non-ASCII. Le type de contenu "multipart / form-data" doit être utilisé pour soumettre des formulaires contenant des fichiers, des données non-ASCII et des données binaires.

Modification ultérieure

Ce bogue semble avoir été résolu dans votre version de PHP. Avez-vous vérifié que le tampon en cours de lecture ne commence pas par un caractère retour-chariot / nouvelle ligne? sur Sitepoint , un problème quelque peu similaire au vôtre. / p>

Essayez d'exécuter strlen sur l'entrée et de voir sa longueur. .

Answer 4

Le r que vous avez comme deuxième argument n’est pas correct. content_get_contents n'utilise pas les arguments a / r / w / a + / r + / w + utilisés par fopen . Vous voulez probablement l'enlever et faites juste:

file_get_contents('php://input');

Voir http://us3.php.net/file_get_contents .