8.4

opening http://127.0.0.1:8080/myaction in your browser.
l The HTTPservice accepts both POSTand GETrequests. Other than the presence of file attachments,
there is little difference in how these are handled. This means that visiting
/myaction?id=12345&q=test would be the same as having a form with two <input> fields
named, respectively, id and q, and submitting them with the information "12345"and "test". In both
cases, this information is located in the XMLenvelope that is the original input file.
l When doing POSTrequests and uploading files, always make sure to include the "multipart"option in
the <form>tag:
<form action="http://127.0.0.1:8080/myaction" method="POST" enctype="multipart/form-data">
Otherwise, file attachments will not be received, only their file names.
l The Mime Type option is better left at Auto-Detect unless the process requires it to be forced to a
specific type. This means that if a process can either return a PDF when successful or an HTMLpage
with an error message, it will not attempt to send an HTML with a PDFmime type (which, obviously,
would cause confusion).
l
There is no HTTPServer Output task (see below on how to end your process)
Request/Process/Response cycle
Once a process using the HTTPServer Input task is created, it is important to understand the cycle that is
triggered when such a process runs. Note that this is the process when the default HTTPServer Input task
options are used (more on how that behavior changes later):
1. A request is received by the HTTPservice.
2. This request is converted into an XMLrequest file along with one or more attachments when present.
3. The XMLrequest file and attachments are saved in a local folder, if the HTTPAction is a valid one
(otherwise, the files are deleted).
4. The HTTPservice keeps the request from the client open (it does not yet respond ot it), and waits.
5. The HTTPprocess corresponding to the HTTPAction captures the XMLfile and attachments and the
process begins.
6. The process runs its course just like any other process would (including subprocesses, send to
process, etc).
7. The very last file that is active when the process finishes is then returned to the HTTPservice.
8. The HTTPservice returns the file to the client and then closes the connection.
9. If, during this time, the timeout has expired (if the process takes more than 120 seconds), the
HTTPservice returns a "timeout"to the client, but the process stills finishes on its own. When the
process finishes, the return file is ignored by the HTTPservice.
Point 7 is critical to understand, as it has an impact on what the client receives. If a process receives a file
that is split into multiple parts and each of these parts generates and output, the last split's output will be sent