[ 
https://issues.apache.org/jira/browse/NIFI-3469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16637934#comment-16637934
 ] 

ASF GitHub Bot commented on NIFI-3469:
--------------------------------------

Github user ijokarumawak commented on a diff in the pull request:

    https://github.com/apache/nifi/pull/2991#discussion_r222560481
  
    --- Diff: 
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/HandleHttpRequest.java
 ---
    @@ -229,7 +252,25 @@
                 .name("container-queue-size").displayName("Container Queue 
Size")
                 .description("The size of the queue for Http Request 
Containers").required(true)
                 
.addValidator(StandardValidators.POSITIVE_INTEGER_VALIDATOR).defaultValue("50").build();
    -
    +    public static final PropertyDescriptor MAX_REQUEST_SIZE = new 
PropertyDescriptor.Builder()
    +            .name("max-request-size")
    +            .displayName("Max Request Size")
    +            .description("The max size of the request. Only applies for 
requests with Content-Type: multipart/form-data, "
    +                    + "and is used to prevent denial of service type of 
attacks, to prevent filling up the heap or disk space")
    +            .required(true)
    +            .addValidator(StandardValidators.DATA_SIZE_VALIDATOR)
    +            .defaultValue("1 MB")
    +            .build();
    +    public static final PropertyDescriptor IN_MEMORY_FILE_SIZE_THRESHOLD = 
new PropertyDescriptor.Builder()
    +            .name("in-memory-file-size-threshold")
    +            .displayName("The threshold size, at which the contents of an 
incoming file would be written to disk. "
    +                    + "Only applies for requests with Content-Type: 
multipart/form-data. "
    +                    + "It is used to prevent denial of service type of 
attacks, to prevent filling up the heap or disk space.")
    --- End diff --
    
    This display name is too long to be fit in the UI, please move it to 
description and user shorter display name. How about "Multipart Read Buffer 
Size"?


> Add multipart request support to HandleHttpRequest Processor
> ------------------------------------------------------------
>
>                 Key: NIFI-3469
>                 URL: https://issues.apache.org/jira/browse/NIFI-3469
>             Project: Apache NiFi
>          Issue Type: Improvement
>          Components: Extensions
>            Reporter: Koji Kawamura
>            Assignee: Endre Kovacs
>            Priority: Major
>
> Currently, HandleHttpRequest outputs a single FlowFile containing all 
> multipart values as following:
> {code}
> --------------------------ef07e8bf36c274d3
> Content-Disposition: form-data; name="p1"
> v1
> --------------------------ef07e8bf36c274d3
> Content-Disposition: form-data; name="p2"
> v2
> --------------------------ef07e8bf36c274d3--
> {code}
> Many users requested adding upload files support to NiFi.
> In order for HandleHttpRequest to support multipart data we need to add 
> followings (this is based on a brief researching and can be more complex or 
> simple):
> We need to use HttpServletRequest#getParts() as written in this stackoverflow 
> thread:
> http://stackoverflow.com/questions/3337056/convenient-way-to-parse-incoming-multipart-form-data-parameters-in-a-servlet
> Also, we probably need a custom MultiPartInputStreamParser implementation. 
> Because Jetty's default implementation writes input data to temporary 
> directory on file system, instead, we'd like NiFi to write those into output 
> FlowFiles content in streaming fashion.
> And we need request size validation checks, threshold for those validation 
> should be passed via javax.servlet.MultipartConfigElement.
> Finally, we have to do something with HandleHttpResponse processor.
> Once HandleHttpRequest processor start splitting incoming request into 
> multiple output FlowFiles, we need to wait for every fragment to be 
> processed, then execute HandleHttpRequest.
> I think Wait/Notify processors (available from next version) will be helpful 
> here.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to