[
https://issues.apache.org/jira/browse/NIFI-1539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15167267#comment-15167267
]
ASF GitHub Bot commented on NIFI-1539:
--------------------------------------
Github user mcgilman commented on a diff in the pull request:
https://github.com/apache/nifi/pull/242#discussion_r54104580
--- Diff:
nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-content-viewer/src/main/java/org/apache/nifi/web/ContentViewerController.java
---
@@ -150,6 +150,7 @@ protected void doGet(final HttpServletRequest request,
final HttpServletResponse
// buffer the content to support reseting in case we need to
detect the content type or char encoding
try (final BufferedInputStream bis = new
BufferedInputStream(downloadableContent.getContent());) {
final String mimeType;
+ final String normalizedMimeType;
// when standalone and we don't know the type is null as we
were able to directly access the content bypassing the rest endpoint,
// when clustered and we don't know the type set to octet
stream since the content was retrieved from the node's rest endpoint
--- End diff --
Yep, for complete clarity this is the additional commit I'll be including
[1].
[1]
https://github.com/mcgilman/nifi/commit/db02e18580a12b1321a9324bd0fb3d3354f9f7f5
> Add correct parsing of content type in accordance with RFC 2045
> ---------------------------------------------------------------
>
> Key: NIFI-1539
> URL: https://issues.apache.org/jira/browse/NIFI-1539
> Project: Apache NiFi
> Issue Type: Bug
> Affects Versions: 0.5.0
> Reporter: Sönke Liebau
> Priority: Minor
>
> The content viewer does not display json content when the content-type string
> does not exactly match "application/json" for example:
> "application/json;charset=UTF8" or "application/Json" trigger the error
> message "No viewer is registered for this content type."
> According to [RFC 2045|https://www.ietf.org/rfc/rfc2045.txt] there can be any
> number of parameters following the type and subtype values, so I believe
> these should not impact the viewer chosen to display this content.
> Furthermore, the rfc states that type and subtype are to be treated case
> insensitive, which is also not given as all checks I found in the code are
> purely against lowercase.
> As far as I can tell this is checked twice, the viewer for the content type
> is obtained from a Context object, if there is no viewer that matches exactly
> the error message stated above is shown.
> After this was successful a string comparison is done in the
> StandardContentViewerController class:
> {code:title=StandardContentViewerController.java|borderStyle=solid}
> if ("application/json".equals(contentType) ||
> "application/xml".equals(contentType) || "text/plain".equals(contentType) ||
> "text/csv".equals(contentType)) {
> ...
> }
> {code}
> So even if the Viewer was assigned to this content type if would fail here.
> h3. Proposed solution
> - Add code to DownloadableContent.java to parse content type string at
> creation and store only lowercased type and subtype, which is retrieved by
> getter method, so no changes are necessary to downstream code
> - Add map to object to store parameters that were contained in the original
> value
> - Either make the entire parameters map object retrievable or create getter
> to retrieve parameter from map by parameter name
> - Add method to retrieve original field value, I propose to build the value
> on request from stored type, subtype and parameters, this way we can
> implement some light error handling and ensure to always hand out properly
> formed strings, even if the input value may have had some small error (there
> is no need to pay attention to parameter order, as per rfc the order
> shouldn't matter)
> h3. Discussion points
> - Anything that actually relies on access to parameters in the content type
> would break, this could be avoided by not changing the getType method but
> instead adding a new method to return type without parameters instead.
> Drawback to this is that current implementation of ContentViewerController
> would need to be changed to use this new function. I am unsure which aproach
> is preferable..
> - If there are classes downstream that access the content type field not via
> DownloadableContent, this shouldn't break anything, as the status quo is
> preserved, but there is a small chance that you get two different content
> types, if you actually use both methods
> I am happy to create a pull request to this effect if open points can be
> clarified and this is deemed useful.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
