Domanda

Tutti,

Come parte di un'applicazione che sto scrivendo, devo disporre di un servizio Web PUT HTTP che accetta l'imagedata in arrivo, che verrà analizzato, convalidato e aggiunto a un archivio di file locale.

Il mio problema si presenta dopo la convalida della dimensione come

  

$ _ SERVER [ 'CONTENT_LENGTH']

ha un > 0 e questo valore è identico alla dimensione del file di test, quindi posso supporre che tutto vada bene fino a questo punto ma quando provo a leggere i dati del flusso in entrata usando

  

file_get_contents ( 'php: // stdin');

Ottengo una stringa vuota. Ho anche provato a usare

  

file_get_contents ( 'php: // input');

E questo mi dà lo stesso risultato di una stringa vuota.

Qualsiasi aiuto, suggerimento o direzione sarà apprezzato.

NB: sto usando

  • PHP 5.2.6
  • Apache 2.0
È stato utile?

Soluzione

La mia ipotesi migliore è che è necessario modificare httpd.conf per non negare le richieste PUT. L'hai verificato?

Altri suggerimenti

Apache HTTPD rifiuta le richieste PUT per impostazione predefinita. Puoi controllare mod_put:
http://perso.ec-lyon.fr/lyonel.vincent/ apache / mod_put.html

e aggiungilo a 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>

file_get_contents non accetta il " r " parametro - vedi la pagina del manuale di PHP :

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

I valori $ flag validi sono FILE_USE_INCLUDE_PATH, FILE_TEXT, FILE_BINARY .

Prova a rimuovere il " r " bandiera e riprovare

Modifica - domanda aggiornata, " r " la bandiera veniva ignorata così evidentemente non alla radice del problema.

Sembra che ci sia un segnalato bug in PHP relativo a file_get_contents restituendo una stringa vuota per un POST HTTP. Dalla descrizione del bug:

  

file_get_contents ('php: // input') (e anche file, fopen + fread ) no   restituire i dati POST, quando inviato modulo con   enctype = " multipart / form-data ".

     

Quando viene inviato lo stesso modulo senza l'enctype specificato (quindi predefinito   & Quot; application / x-www-form-urlencoded " viene utilizzato) tutto funziona correttamente.

Quindi sembra che una soluzione alternativa sia quella di cambiare il tipo di modulo specificato da multipart / form-data , che ovviamente non è l'ideale per un caricamento di immagini - da Specifica W3 FORM :

  

Il tipo di contenuto " application / x-www-form-urlencoded " è inefficiente per l'invio di grandi quantità di dati binari o testo contenente caratteri non ASCII. Il tipo di contenuto "multipart / form-data" dovrebbe essere usato per inviare moduli che contengono file, dati non ASCII e dati binari.

Ulteriore modifica

Questo bug sembra essere stato risolto nella tua versione di PHP. Hai verificato per accertarti che il buffer in lettura non inizi con un carattere di ritorno a capo / newline? C'è un problema in qualche modo simile al tuo che è stato discusso su Sitepoint .

Prova a eseguire strlen sull'input e vedi qual è la lunghezza .

Il r che hai come secondo arg non è giusto. file_get_contents non utilizza gli argomenti a / r / w / a + / r + / w + utilizzati da fopen . Probabilmente vuoi rimuoverlo e basta:

file_get_contents('php://input');

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

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top