Joseph Koets created NIFI-873:
---------------------------------
Summary: Adding Form Hosting to ListenHTTP Processor
Key: NIFI-873
URL: https://issues.apache.org/jira/browse/NIFI-873
Project: Apache NiFi
Issue Type: Wish
Components: Extensions
Reporter: Joseph Koets
Priority: Minor
The following is a suggestion for an improvement to the ListenHTTP processor.
I wasn't sure whether to post this under Wish or Improvement, but for now it's
a wish.
ListenHTTP should have an optional property whose value is an html form or
whose value references an html file to be hosted at "host:port/form" similar to
"host:port/contentListener".
The form would have to post to "host:port/contentListener".
I've done this outside of NiFi's web server, and it works great. Given that it
can be done currently, perhaps you wouldn't want to make the change, but I
think it would offer some convenience by hosting the form on the same server.
An example form:
{quote}<html>
<body>
<form action="./contentListener" method="POST"
enctype="multipart/form-data">
Name: <input type="textbox" name="name"> </input><br/>
Favorite Car: <select name="favoriteCar">
<option value="tesla">Tesla</option>
<option value="ford">Ford</option>
</select><br/>
File: <input type="file" name="fileField"></input><br/>
<input type="submit"></input>
</form>
</body>
</html>
{quote}
The current output from the ListenHTTP processor looks like this:
{quote}------WebKitFormBoundaryAJQzPAgIfJ9EHO7J
Content-Disposition: form-data; name="name"
Jim
------WebKitFormBoundaryAJQzPAgIfJ9EHO7J
Content-Disposition: form-data; name="favoriteCar"
tesla
------WebKitFormBoundaryAJQzPAgIfJ9EHO7J
Content-Disposition: form-data; name="fileField"; filename=""
Content-Type: application/octet-stream
[bytes would be here if I had selected a file]
------WebKitFormBoundaryAJQzPAgIfJ9EHO7J--
{quote}
I guess the processor would handle "application/x-www-form-urlencoded",
"multipart/form-data", and "text/plain" enctype's in different ways.
Enctypes "application/x-www-form-urlencoded" and "text/plain" values would be
converted to FlowFile properties with the FlowFile having no data, while I
think "multipart/form-data" would be handled like this:
1. Any non "application/octet-stream" Content-Types are converted to FlowFile
Properties.
2. For each "application/octet-stream" content, a FlowFile would be created
with the properties duplicated, and the data written to the FlowFile's data.
Outbound relationships could be pulled from the html form ("name" attribute of
input tags of type "file"), or rather set explicitly by the DFM. This would be
similar to the DistributeLoad processor's quasi-dynamic relationships but with
csv values that correspond to the form-data name field.
Perhaps a separate optional property would make the processor output the
multipart/form-data as is, and let another processor handle it, or maybe
someone else has a better idea.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
