Details
-
Wish
-
Status: Open
-
Minor
-
Resolution: Unresolved
-
None
-
None
-
None
Description
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:
<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>
The current output from the ListenHTTP processor looks like this:
------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-
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.
Attachments
Issue Links
- mentioned in
-
Page Loading...