Add support for honoring flow-asserted “chunked” transport encoding within HTTPReply nodes

As part of our regular commitment to reviewing RFEs, we have analysed the status and comments which have been made since the last update. We note the use case, and also note that it may be relevant for MTOM and SOAP with Attachments scenarios as well. Status of this RFE remains for now as Uncommitted candidate. We will continue to monitor for further votes and supportive comments.

Thank you for raising this RFE, and for taking the time to describe the use case surrounding the requirement both here on the RFE and also in conversations with your Lab Advocate Paul, and phone calls with Trevor from our architecture team. This is an interesting requirement, which we should begin by noting is not one that we've had raised by our client base before. Of course we have large numbers of IIB users implementing flow logic similar to the use case presented, where IIB acts as a mediator between an HTTP REST API based invoking application client, and a persistent asynchronous based backend (such as via MQ transport for example). However, the typical architectural pattern in this circumstance is to use aggregation/collector logic in the flow using a persistent state store, or gather the required responses in memory before returning the data to (and closing) the socket. As noted, there may be cases where the amount of data makes these methods of solving the problem inappropriate for non-functional reasons, so for this reason we are not against the suggestion. However, whilst noting that this would be valuable for some users / usecases, the more standard approach observed is to use smaller transmission packets more frequently. We'll continue to monitor the RFE and would be very keen to hear from other clients in the comments section (please include your company name, or alternativelt contact us directly if privacy is required) if they are facing a similar need. Status of the RFE is updated to Uncommitted Candidate.