Qual è il limite in multipart / form-data?

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?

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.

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--

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