Qual è il limite in multipart / form-data?


403

Voglio fare una domanda sul multipart/form-data. Nell'intestazione HTTP, trovo che il Content-Type: multipart/form-data; boundary=???.

Il ???libero deve essere definito dall'utente? O è generato dall'HTML? È possibile per me definire il ??? = abcdefg?


2
Ho scoperto che questa è la risposta. w3.org/TR/html401/interact/forms.html#h-17.13.4.2
Domande

Risposte:


424

Il ???libero deve essere definito dall'utente?

Sì.

o è fornito dall'HTML?

No. HTML non ha nulla a che fare con questo. Leggere sotto.

È possibile per me definire il ???come abcdefg?

Sì.

Se si desidera inviare i seguenti dati al server Web:

name = John
age = 12

l'utilizzo application/x-www-form-urlencodedsarebbe così:

name=John&age=12

Come puoi vedere, il server sa che i parametri sono separati da una e commerciale &. Se &è richiesto per un valore di parametro, deve essere codificato.

Quindi, come fa il server a sapere dove inizia e termina il valore di un parametro quando riceve una richiesta HTTP utilizzando multipart/form-data?

Usando il confine , simile a &.

Per esempio:

--XXX
Content-Disposition: form-data; name="name"

John
--XXX
Content-Disposition: form-data; name="age"

12
--XXX--

In tal caso, il valore limite è XXX. Lo specifichi Content-Typenell'intestazione in modo che il server sappia come dividere i dati che riceve.

Quindi è necessario:

  • Utilizzare un valore che non verrà visualizzato nei dati HTTP inviati al server.

  • Sii coerente e usa lo stesso valore ovunque nel messaggio di richiesta.


54
Devi aggiungere un "-" extra alla fine del confine.
Sebastian Piskorski,

13
Puoi leggerlo nella documentazione. Il finale di confine deve avere due extra "-" Link: w3.org/TR/html401/interact/forms.html#h-17.13.4.2
Sebastian Piskorski

6
Bella risposta. Un limite è solo la "chiave" per separare le "parti" multiple di un payload multipart. Normalmente qualcosa come '&' è sufficiente per separare le variabili ma è necessario qualcosa di più unico per separare i payload all'interno del payload.
user2483724

1
@ K3rnel31 Naturalmente, a meno che la nuova stringa di confine non abbia la stessa lunghezza.
Oscar Mederos,

5
Penso che il valore limite dichiarato nell'intestazione Content-Type sarà in realtà -XXX --- perché un "-" extra dovrebbe essere scritto quando si separano le parti (da qui --- XXX ---)
Theodore K .

96

La risposta esatta alla domanda è: sì, è possibile utilizzare un valore arbitrario per il boundaryparametro , dato che non supera i 70 byte di lunghezza e comprende solo caratteri a 7 bitUS-ASCII (stampabili).

Se si utilizza uno dei multipart/*tipi di contenuto, in realtà viene richiesto di specificare il boundaryparametro Content-Typenell'intestazione, altrimenti il ​​server (nel caso di una richiesta HTTP) non sarà in grado di analizzare il payload.

Probabilmente vuoi anche impostare il charsetparametro su UTF-8nella tua Content-Typeintestazione, a meno che tu non possa essere assolutamente sicuro che US-ASCIInei dati del payload verrà utilizzato solo il set di caratteri.

Alcuni estratti rilevanti dall'RFC2046 :

  • 4.1.2. Parametro Charset:

    A differenza di altri valori di parametro, i valori del parametro charset NON fanno distinzione tra maiuscole e minuscole. Il set di caratteri predefinito, che deve essere assunto in assenza di un parametro charset, è US-ASCII.

  • 5.1. Tipo di supporto multipart

    Come indicato nella definizione del campo Codifica trasferimento-contenuto [RFC 2045], nessuna codifica diversa da "7 bit", "8 bit" o "binaria" è consentita per entità di tipo "multipart". I delimitatori e i campi di intestazione "multipart" sono sempre rappresentati come US-ASCII a 7 bit (anche se i campi di intestazione possono codificare testo di intestazione non US-ASCII secondo RFC 2047) e i dati all'interno delle parti del corpo possono essere codificati in un parte per parte, con campi Codifica trasferimento contenuto per ogni parte del corpo appropriata.

    Il campo Content-Type per entità multipart richiede un parametro, "confine". La linea del delimitatore di confine viene quindi definita come una linea costituita interamente da due trattini ("-", valore decimale 45) seguito dal valore del parametro limite dal campo di intestazione Content-Type, uno spazio bianco lineare opzionale e un CRLF finale.

    I delimitatori di confine non devono apparire all'interno del materiale incapsulato e non devono superare i 70 caratteri, senza contare i due trattini principali.

    La linea del delimitatore di confine che segue l'ultima parte del corpo è un delimitatore distinto che indica che non seguiranno ulteriori parti del corpo. Tale linea del delimitatore è identica alle precedenti linee del delimitatore, con l'aggiunta di altri due trattini dopo il valore del parametro limite.

Ecco un esempio usando un confine arbitrario:

Content-Type: multipart/form-data; charset=utf-8; boundary="another cool boundary"

--another cool boundary
Content-Disposition: form-data; name="foo"

bar
--another cool boundary
Content-Disposition: form-data; name="baz"

quux
--another cool boundary--

2
Mi piace di più questa risposta perché cita RFC su come vengono specificati i trattini .
Rick,

@Rick C'è un motivo valido per IETF per farlo - anche se sembrano tutti praticamente uguali, solo uno dei seguenti quattro è il carattere trattino corretto: ˗ - - -
antichris

ah, quando ho detto hypens, intendo la tua risposta mi ha detto quali hypens sono definiti nello standard. Ero confuso su quali hypens siano "definiti dal cliente" e quali siano "definiti dalle specifiche"
Rick

31

multipart / form-data contiene il confine per separare coppie nome / valore. Il confine si comporta come un marcatore di ogni blocco di coppie nome / valore passate quando viene inviato un modulo. Il limite viene automaticamente aggiunto a un tipo di contenuto di un'intestazione di richiesta.

Il modulo con enctype = l'attributo "multipart / form-data" avrà un'intestazione di richiesta Content-Type: multipart / form-data; limite --- WebKit193844043-h ( vaue generato dal browser ).

Il payload passato è simile al seguente:

Content-Type: multipart/form-data; boundary=---WebKitFormBoundary7MA4YWxkTrZu0gW

    -----WebKitFormBoundary7MA4YWxkTrZu0gW
    Content-Disposition: form-data; name=”file”; filename=”captcha
    Content-Type:

    -----WebKitFormBoundary7MA4YWxkTrZu0gW
    Content-Disposition: form-data; name=”action

    submit
    -----WebKitFormBoundary7MA4YWxkTrZu0gW--

Per quanto riguarda il servizio web, viene utilizzato nel modulo @Consumes ("multipart / form-data").

Fai attenzione, quando collaudi il tuo servizio web utilizzando Chrome Postman, devi selezionare l'opzione dei dati del modulo (pulsante di opzione) e il menu File dalla casella a discesa per inviare l'allegato. La fornitura esplicita del tipo di contenuto come multipart / form-data genera un errore. Perché il confine è mancante in quanto sovrascrive la richiesta di arricciatura di post man su server con tipo di contenuto aggiungendo il confine che funziona correttamente.

Vedere RFC1341 sec7.2 Tipo di contenuto multipart

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.