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

ASF GitHub Bot commented on METRON-941:
---------------------------------------

Github user ctramnitz commented on the issue:

    https://github.com/apache/metron/pull/579
  
    @ottobackwards Where is the regression? If a user used the parser 
previously with a full syslog header it will continue to work the same way. The 
result will be the same odd domain field "<syslog header>, 1" instead of "1". 
The parser hasn't changed, only the test which expects just the message now. 
And since the test was non-functional before (it was never invoked), this 
cannot be regression either.
    
    The only thing that has changed is some field names, but since this was 
utterly broken before, i.e.
    BasicPaloAltoFirewallParser.java line 84++
    ```
     
    -  public static final String Bytes = "content_type";
    -  public static final String BytesSent = "content_type";
    -  public static final String BytesReceived = "content_type";
    -  public static final String Packets = "content_type";
    -  public static final String StartTime = "content_type";
    -  public static final String ElapsedTimeInSec = "content_type";
    -  public static final String Padding = "content_type";
    ```
    I wouldn't call this a regression, it may be worth a note though.


> native PaloAlto parser corrupts message when having a comma in the payload
> --------------------------------------------------------------------------
>
>                 Key: METRON-941
>                 URL: https://issues.apache.org/jira/browse/METRON-941
>             Project: Metron
>          Issue Type: Bug
>    Affects Versions: 0.4.0
>         Environment: full-dev master
>            Reporter: Christian Tramnitz
>            Priority: Minor
>
> When a data field contains a comma (i.e. the URL, not too uncommon), the 
> split(",") kicks in and the rest of the message if off by few fields due to 
> positional definition.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to