Skip to Content

Changes for page Multipart form-data

Last modified by Erik Bakker on 2024/06/17 11:39
From version 23.1
edited by Erik Bakker
on 2024/01/19 08:20
Change comment: There is no comment for this version
To version 20.1
edited by Erik Bakker
on 2022/08/05 14:50
Change comment: There is no comment for this version

Summary

Details

Page properties
Default language
... ... @@ -1,0 +1,1 @@
1 +en
Content
... ... @@ -27,13 +27,6 @@
27 27  * Defining the content types of each part of the message
28 28  * Construction of the complete message according to the specification
29 29  
30 -{{info}}
31 -The following criteria apply when utilizing the boundary functionality within the multipart/form-data construction:
32 -* The value of the Boundary must begin with a double horizontal bar –, this is called a leading hyphen
33 -* The value of the Boundary must not contain more than 70 characters in addition to the leading hyphen.
34 -* The value of the Boundary must not contain characters that are disabled by the HTTP protocol or the URL, such as the colon: etc.
35 -* A boundary within the request body must always be preceeded by a CRLF line. This means that when the request body **ends** with a CRLF line an **additional** CRLF line is needed **before** the boundary doubling the CRLF lines in that part of the request body.{{/info}}
36 -
37 37  === 3.1 Prepare the message ===
38 38  
39 39  To construct the message, several steps are needed to make it work. Luckily, most of the steps necessary have to do with concepts we have already discussed in previous microlearnings. As you can imagine, based on what multipart/form-data entails, we need a way to both store the meta information and the file(s) we want to send to the external party. For example, put the metadata in one (or multiple) header(s) and use the file content as a payload. This you can achieve with a header enricher and standard transformer.
... ... @@ -65,17 +65,24 @@
65 65  
66 66  Now that we have constructed our message correctly, the last thing to do is call the endpoint in question. Since we have prepared our message and accurately defined our contentType calling the endpoint does not require any additional configurations compared to what you are already used to when dealing with REST endpoints.
67 67  
68 -== 4. Key takeaways ==
61 +== 4. Assignment ==
69 69  
63 +Try to see whether you can construct the flow so that it outputs a valid multipart/form-data message.
64 +This assignment can be completed with the help of the (Academy) project you created/used in the previous assignment.
65 +
66 +== 5. Key takeaways ==
67 +
70 70  * Make sure to define the boundary that separates the parts of the message
71 71  * Make sure to define the content types of each part of the message
72 72  * Make sure to define the content type that matches the specification for multipart/form-data
73 73  * Construct the complete message according to the specification
74 74  
75 -== 5. Suggested Additional Readings ==
73 +== 6. Suggested Additional Readings ==
76 76  
77 77  If you are interested in this topic, please read the help texts on the platform and read the following link:
78 78  
79 -* [[Multipart form-data explained>>https://www.sobyte.net/post/2021-12/learn-about-http-multipart-form-data/||target="blank"]]
77 +* https://www.sobyte.net/post/2021-12/learn-about-http-multipart-form-data/
80 80  
81 -)))((({{toc/}}))){{/container}}{{/container}}
79 +== 7. Silent demonstration video ==
80 +
81 +As this is more of theoretical microlearning, there is no video accompanying the microlearning.)))((({{toc/}}))){{/container}}{{/container}}