file_get_contents ("php: // input") o $ HTTP_RAW_POST_DATA, qual è il migliore per ottenere il corpo della richiesta JSON?


120

file_get_contents("php://input")o $HTTP_RAW_POST_DATA- qual è il migliore per ottenere il corpo della richiesta JSON?

E quale tipo di richiesta ( GETo POST) devo utilizzare per inviare dati JSON quando si utilizza il lato client XmlHTTPRequest?

La mia domanda è stata ispirata da questa risposta: come pubblicare JSON su PHP con curl

Cita da quella risposta:

Dal punto di vista del protocollo file_get_contents("php://input")è effettivamente più corretto, dal momento che non stai comunque elaborando i dati del modulo multipart http.

Risposte:


195

In realtà php://inputti consente di leggere i dati POST grezzi.

È un'alternativa meno dispendiosa in termini di memoria a $ HTTP_RAW_POST_DATA e non necessita di alcuna direttiva php.ini speciale .

php://inputnon è disponibile con enctype="multipart/form-data".

Riferimento: http://php.net/manual/en/wrappers.php.php


12
Inoltre, a partire da PHP 5.6, $HTTP_RAW_POST_DATAè considerato deprecato e php://inputpuò essere riutilizzato.
Chris Forrence


json_decode (file_get_contents ('php: // input'), true) supporta in PHP 7.1 per ottenere i valori $ _GET dall'URL?
Kailas

$ HTTP_RAW_POST_DATA è stato deprecato a partire da PHP 7
Daniel

15

php: // input è un flusso di sola lettura che consente di leggere i dati grezzi dal corpo della richiesta. Nel caso di richieste POST, è preferibile utilizzare php: // input invece di $ HTTP_RAW_POST_DATA in quanto non dipende da speciali direttive php.ini . Inoltre, per quei casi in cui $ HTTP_RAW_POST_DATA non è popolato per impostazione predefinita, è un'alternativa potenzialmente meno dispendiosa in termini di memoria all'attivazione di always_populate_raw_post_data.

Fonte: http://php.net/manual/en/wrappers.php.php .


4
Inoltre, a partire da PHP 5.6, $HTTP_RAW_POST_DATAè considerato deprecato e php://inputpuò essere riutilizzato.
Chris Forrence

14

file_get_contents (php: // input) - ottiene i dati POST non elaborati e devi usarli quando scrivi API e hai bisogno di XML / JSON / ... input che non può essere decodificato in $ _POST da PHP qualche esempio:

inviare per posta stringa JSON

<input type="button" value= "click" onclick="fn()">
<script>
 function fn(){


    var js_obj = {plugin: 'jquery-json', version: 2.3};

    var encoded = JSON.stringify( js_obj );

var data= encoded


    $.ajax({
  type: "POST",
  url: '1.php',
  data: data,
  success: function(data){
    console.log(data);
  }

});

    }
</script>

1.php

//print_r($_POST); //empty!!! don't work ... 
var_dump( file_get_contents('php://input'));

3

Per come inviare la richiesta dovrebbero applicarsi le normali regole. Se la richiesta è di recuperare informazioni (ad esempio un risultato di 'suggerimento' di ricerca parziale, o una nuova pagina da visualizzare, ecc ...) è possibile utilizzare GET. Se i dati inviati fanno parte di una richiesta di modifica (aggiornamento di un database, cancellazione di un record, ecc.) Allora usa POST.

Lato server, non c'è motivo di utilizzare l'input non elaborato, a meno che non si desideri acquisire l'intero blocco di post / recupero dati in una sola volta. È possibile recuperare le informazioni specifiche desiderate tramite gli array _GET / _POST come al solito. Le librerie AJAX come MooTools / jQuery gestiranno la parte difficile dell'esecuzione delle chiamate AJAX effettive e della codifica dei dati del modulo in formati appropriati per te.


Questo è il punto: voglio afferrare l'intero blocco di dati post / get in una sola volta, perché JSON è un formato senza variabili, rappresenta solo i dati.
Manuel Bitto

@ Kucebe non vedo perché è necessario, perché non inserire i dati JSON in un campo POST e farla finita?
Pekka

Se desideri l'intero blocco JSON, perché non assegnare il blocco di testo JSON a un campo modulo e inviarlo in questo modo? <input type="hidden" name="data" value="json data here" />è del tutto accettabile e ti consente di recuperarlo banalmente lato server con $ _REQUEST ['data'].
Marc B

3
L'incorporamento di JSON in un campo POST vanifica lo scopo del tag di tipo di contenuto HTTP e non è così piacevole per il debug in Fiddler e nei debugger del browser (che possono comprendere JSON). Inoltre, molte librerie JavaScript di terze parti POST JSON payload come application / json.
CyberMonk

2

Per i dati JSON, è molto più semplice POST come tipo di contenuto "application / json". Se usi GET, devi codificare in URL il JSON in un parametro ed è un po 'disordinato. Inoltre, non ci sono limiti di dimensione quando esegui il POST. La dimensione di GET è molto limitata (4K al massimo).


2
C'è spesso un limite di dimensione per POST, ma di solito è impostato piuttosto alto. Controlla il tuo php.ini.
Brad

2

La tua seconda domanda è semplice, GET ha un limite di dimensione di 1-2 kilobyte sia sul lato server che sul lato browser, quindi qualsiasi tipo di maggiore quantità di dati che dovresti inviare tramite POST.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.