[jira] [Commented] (TIKA-1519) Don't allow whatever is in http-equiv Content-Type to overwrite actual Content-Type in HtmlParser

["Luis Filipe Nassif (JIRA)" <ji...@apache.org>]

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

Luis Filipe Nassif commented on TIKA-1519:
------------------------------------------

Maybe a more general "Content-Type-Hint"? I have had problems with other parsers using the Content-Type key for both hints and recognized mimetypes. For example, the RFC822 parser can set a wrong Content-Type for an attachment. I think we should use separete keys for hints and detected mimetypes.

> Don't allow whatever is in http-equiv Content-Type to overwrite actual Content-Type in HtmlParser
> -------------------------------------------------------------------------------------------------
>
>                 Key: TIKA-1519
>                 URL: https://issues.apache.org/jira/browse/TIKA-1519
>             Project: Tika
>          Issue Type: Bug
>    Affects Versions: 1.6
>            Reporter: Tim Allison
>            Priority: Trivial
>             Fix For: 1.8
>
>
> The HtmlParser will overwrite the value of Content-Type in Metadata with any value of content in an http-equiv=Content-Type header, e.g.
> {noformat}
> <meta http-equiv=Content-Type content="blah de blah blah">{noformat}.
> or even worse, perhaps:
> <meta http-equiv=Content-Type content="application/pdf">
> Let's capture the content type alleged by the html file in a different key from Content-Type; I'd prefer to reserve Content-Type for "text/html; charset=X".
> Candidate key/Property: Content-Type-Meta-HTTP-Equiv?
> See TIKA-1514 for example output.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)