[
https://issues.apache.org/jira/browse/NIFI-221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14279783#comment-14279783
]
Joseph Witt commented on NIFI-221:
----------------------------------
Mark
I've done a bit of a review. Comments for that are below. Perhaps to Adam's
point and your counter there is a middle ground here. I can see merit in both
approaches. Perhaps we should offer both approaches. One approach would be a
single processor that can do both request/response (I feel like the cohesion
concern is less powerful than the later points made). And the other is what
you have here. Perhaps that is something we can add later. Just pointing out
that you're both right here...
Comments for the review of the StandardHTTPContextMap:
- Line 59: Todo. The thing it says to do appears to be there. So perhaps this
is a to delete.
- It would be good to support the ability to check if there is room before
attempting to register a session. Yes this becomes a check-the-modify case .
However, it just gives the caller a chance to find out whether it is worth
going ahead and attempting to register.
- We really should have some way of evicting items in this map based on timing
out. If the flow file that holds the key/identifier gets aged-off or whatnot
then some sort of optional/auto-eviction would be critical.
HandleHTTPRequest:
- Should the allowable path concept be killed off? The rejection/404 could
just be part of the flow configuration. These processors allow a very powerful
power user to visually build and observe web services. Actually wondering the
same thing about the allowable methods. One really KISS approach here is to
simple accept requests, serialize the interesting headers, methods, details as
flow file attributes and body as flow file content and forward it on.
- Line 333: Adding destination queue fullness to the ProcessContext. That does
seem like a potentially more appropriate home than ProcessSession. That would
be a potentially unpleasant api change though no?
I have not executed it but this is really awesome.
> Build Processors that allow for receiving and responding to arbitrary HTTP
> requests
> -----------------------------------------------------------------------------------
>
> Key: NIFI-221
> URL: https://issues.apache.org/jira/browse/NIFI-221
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
> Reporter: Mark Payne
> Assignee: Mark Payne
>
> The idea here is that we can receipt an HTTP request and use NiFi, in essence
> to build a web server graphically. This opens up a wide range of
> possibilities, by allowing a DFM to easily add a web front-end to any service
> that NiFi can interact with or to perform any sort of action that NiFi has
> the ability to perform, such as data format conversion, etc.
> For example, if you want to provide a web-based front-end to an SFTP Server,
> you could do so by creating a flow like:
> ReceiveHTTPRequest -> PutSFTP -> RespondHTTPRequest
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
