NIFI-15888 Add size limit to Standard Content Viewer

[exceptionfactory]

Summary

NIFI-15888 Adds an internal size limit of 10 MB to the Standard Content Viewer, avoiding attempts to load, format, and render large FlowFiles.

The internal limit of 10 MB aligns with a previous comment on Apache Avro formatting, which actually limited to the output size to 2 MB.

The implementation uses the LimitingInputStream to avoid reading more than 10 MB from the referenced FlowFile. The limit applies to both formatted and unformatted responses. Unformatted responses with content exceeding the limit return an HTTP 206 status indicating Partial Content returned. Formatted may throw an exception when the limit does not align with expected structural boundaries. In this case, the server returns an HTTP 500 with message indicating length exceeds maximum. As a best effort viewer, returning an error avoids both server and client memory consumption concerns. The hexadecimal viewer continues to provide a general way to view initial bytes.

Additional unit tests exercise length limiting behavior with formatted and unformatted responses.

Tracking

Please complete the following tracking steps prior to pull request creation.

Issue Tracking

• Apache NiFi Jira issue created

Pull Request Tracking

• Pull Request title starts with Apache NiFi Jira issue number, such as NIFI-00000
• Pull Request commit message starts with Apache NiFi Jira issue number, as such NIFI-00000
• Pull request contains commits signed with a registered key indicating Verified status

Pull Request Formatting

• Pull Request based on current revision of the main branch
• Pull Request refers to a feature branch with one commit containing changes

Verification

Please indicate the verification steps performed prior to pull request creation.

Build

• Build completed using ./mvnw clean install -P contrib-check
  • JDK 21
  • JDK 25

Licensing

• New dependencies are compatible with the Apache License 2.0 according to the License Policy
• New dependencies are documented in applicable LICENSE and NOTICE files

Documentation

• Documentation formatting appears as expected in rendered files

[pvillard31]

For content larger than the response buffer, the response commits during transferTo, so does the later setStatus(SC_PARTIAL_CONTENT) actually reach the client, or does it silently return 200 with truncated content?

[exceptionfactory]

Good catch, the test behavior masked this important detail. I adjusted the approach to get the expected Content Length from the source, and used that to get and set the response status prior to handling the stream.

[pvillard31]

Since MockServletOutputStream never commits the response, does this test really verify that a real container would send 206 after the body is written?

[exceptionfactory]

Thanks for pointing this out, I reworked the implementation to set the response status earlier.

[exceptionfactory]

Thanks for the review @pvillard31, good catch on the order of setting the response status.

I made some adjustments to get the source content length and pass it to the DownloadableContent object, enabling determination of partial content status prior to stream handling.

The LimitingInputStream still enforces the limit, even if the content length is something unknown, like -1, but the response status determination provides a best-effort approach to indicate whether truncation occurred.

[pvillard31]

Thanks @exceptionfactory - latest LGTM