Right, I left that one out: the prompt goes into Parameters.
Background: posting a file with parameters is like posting a form. A MIME is created with the following structure:
Code: Select all
MIME-Version: 1.0
Content-Type: multipart/related; boundary=i7wMePDuTqA3JHHXpDUEXVORVjtiNIdJVvktuGrDPUtnjZLvr
--i7wMePDuTqA3JHHXpDUEXVORVjtiNIdJVvktuGrDPUtnjZLvr
Content-Type: application/PDF
Content-ID: PDF_00001
Content-Disposition: attachment; filename="test.pdf"; name="file"
...here comes the PDF file or whatever other file ...
--i7wMePDuTqA3JHHXpDUEXVORVjtiNIdJVvktuGrDPUtnjZLvr
Content-Disposition: form-data; name="parameter1"
value 1
------i7wMePDuTqA3JHHXpDUEXVORVjtiNIdJVvktuGrDPUtnjZLvr
Content-Disposition: form-data; name="parameter2"
value 2
--i7wMePDuTqA3JHHXpDUEXVORVjtiNIdJVvktuGrDPUtnjZLvr
The boundary can of course be anything and is used by a web server to identify where a part starts and where it ends.
A web server receiving a MIME knows what the parameters are: it is the stuff that is part of Content-Disposition: form-data.
And it knows where the file is because that is in a part with Content-Disposition: attachment. The "name" of the attachment comes from the "File variable" property. Some servers will ignore this, some will not accept the post if there is no attachment with the correct name. In principle there can be multiple attachments in which case it will be necessary to identify the different parts correctly, otherwise the server would not know which part is the cover PDF and which part is the content PDF by way of example . This is not common and is currently not supported by HTTP request.
The difference when using "Request type - POST a body" is that only parameters are placed into the MIME, no attachment.