Was ist die Grenze bei multipart/form-data?

Kann der Benutzer den Begriff ??? frei definieren?

Ja.

oder wird es von der HTML geliefert?

Nein. HTML hat nichts damit zu tun. Lesen Sie unten.

Ist es mir möglich, das ??? als abcdefg zu definieren?

Ja.

Wenn Sie die folgenden Daten an den Webserver senden möchten:

name = John
age = 12

unter Verwendung von application/x-www-form-urlencoded würde dies so aussehen:

name=John&age=12

Wie Sie sehen können, weiß der Server, dass Parameter durch ein kaufmännisches Und getrennt sind. Wenn "&amp" für einen Parameterwert erforderlich ist, muss er kodiert werden.

Woher weiß der Server also, wo ein Parameterwert beginnt und wo er endet, wenn er eine HTTP-Anfrage mit multipart/form-data erhält?

Durch die Verwendung der Grenze, ähnlich wie bei &.

Zum Beispiel:

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

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

12
--XXX--

In diesem Fall ist der Begrenzungswert XXX. Sie geben ihn in der Kopfzeile Content-Type an, damit der Server weiß, wie er die empfangenen Daten aufteilen muss.

Das müssen Sie also tun:

• Verwenden Sie einen Wert, der in den an den Server gesendeten HTTP-Daten nicht vorkommt.

• Seien Sie konsistent und verwenden Sie überall in der Anforderungsnachricht denselben Wert.

Die genaue Antwort auf die Frage lautet: Ja, Sie können einen beliebigen Wert für den Parameter "Grenze" verwenden, vorausgesetzt, er ist nicht länger als 70 Byte und besteht nur aus [7-Bit-US-ASCII-][US-ASCII-] (druckbaren) Zeichen.

Wenn Sie einen der Inhaltstypen multipart/* verwenden, sind Sie sogar verpflichtet, den Parameter boundary im Content-Type-Header anzugeben, andernfalls ist der Server (im Falle einer HTTP-Anfrage) nicht in der Lage, die Nutzdaten zu parsen.

Wahrscheinlich sollten Sie auch den Parameter charset in Ihrem Content-Type-Header auf UTF-8 setzen, es sei denn, Sie können absolut sicher sein, dass nur der US-ASCII-Zeichensatz in den Nutzdaten verwendet wird.

Ein paar relevante Auszüge aus dem RFC2046:

• 4.1.2. Charset-Parameter: Im Gegensatz zu einigen anderen Parameterwerten wird bei den Werten des Charset-Parameters NICHT zwischen Groß- und Kleinschreibung unterschieden. Der Standardzeichensatz, der angenommen werden muss, wenn kein Zeichensatzparameter angegeben wird, ist US-ASCII.

• 5.1. Mehrteiliger Medientyp Wie in der Definition des Feldes Content-Transfer-Encoding [RFC 2045] angegeben, ist für Entitäten vom Typ "multipart" keine andere Kodierung als "7bit", "8bit" oder "binary" zulässig. Die "multipart" Begrenzungszeichen und Header-Felder werden in jedem Fall als 7bit US-ASCII dargestellt (obwohl die Header-Felder gemäß RFC 2047 auch Nicht-US-ASCII-Header-Text kodieren können), und die Daten innerhalb der Körperteile können auf einer Teil-für-Teil-Basis kodiert werden, mit Content-Transfer-Encoding-Feldern für jeden entsprechenden Körperteil.

  Das Feld Content-Type für mehrteilige Entitäten erfordert einen Parameter, "boundary". Die Begrenzungszeile wird dann als eine Zeile definiert, die vollständig aus zwei Bindestrichen ("-", Dezimalwert 45) besteht, gefolgt von dem Wert des Begrenzungsparameters aus dem Feld Content-Type header, optionalem linearem Leerzeichen und einem abschließenden CRLF.

  Die Begrenzungszeichen dürfen nicht innerhalb des gekapselten Materials erscheinen und dürfen nicht länger als 70 Zeichen sein, wobei die beiden führenden Bindestriche nicht mitgezählt werden.

  Die Begrenzungslinie nach dem letzten Textteil ist ein unterscheidbares Trennzeichen, das anzeigt, dass keine weiteren Textteile folgen werden. Eine solche Begrenzungszeile ist identisch mit den vorherigen Begrenzungszeilen, wobei nach dem Wert des Begrenzungsparameters zwei weitere Bindestriche hinzugefügt werden.

Hier ist ein Beispiel mit einer beliebigen Begrenzung:

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

"Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types"

multipart/form-data enthält boundary zur Trennung von Name/Wert-Paaren. Die Begrenzung wirkt wie eine Markierung für jedes Stück von Name/Wert-Paaren, das beim Absenden eines Formulars übergeben wird. Der Boundary wird automatisch zu einem Content-Type eines Request-Headers hinzugefügt.

Das Formular mit dem Attribut enctype="multipart/form-data" hat einen Request-Header Content-Type : multipart/form-data; boundary --- WebKit193844043-h (browser generated vaue).

Die übergebene Nutzlast sieht in etwa so aus:

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

Auf der Webservice-Seite wird sie in der Form @Consumes("multipart/form-data") konsumiert.

Wenn Sie Ihren Webservice mit chrome postman testen, müssen Sie die Option form data (Optionsfeld) und das Menü File (Datei) in der Dropdown-Box aktivieren, um den Anhang zu senden. Die explizite Angabe des Inhaltstyps als multipart/form-data führt zu einem Fehler. Da die Begrenzung fehlt, wird die Curl-Anfrage von postman an den Server mit dem Inhaltstyp durch Anhängen der Begrenzung überschrieben, was gut funktioniert.

Siehe RFC1341 sec7.2 The Multipart Content-Type