[Bro] Bro Types Not Following Bro Types Documention
dopheide at gmail.com
Mon May 18 08:00:02 PDT 2015
I'll just add one high level point. It's important to remember that, for a
lot of people, the logs are the final output. They must be human readable
and easily processed with simple unix command line tools.
On Mon, May 18, 2015 at 9:43 AM, Johanna Amann <johanna at icir.org> wrote:
> On Mon, May 18, 2015 at 08:37:04AM -0500, John Omernik wrote:
> > That all said... why put anything in a field (as a default) to represent
> > unset or empty? Are we at risk of evasion?
> I am not sure what you would should do instead. From a protocol point of
> view, there is often a huge difference between "an empty string was
> transferred" and "this was not seen at all". For example, in HTTP a
> Referrer of "-" means that no referrer header was set at all. "" (the
> empty string) instead means that it was seen, but empty. Same for sets,
> there is a difference between the set was not seen at all ("-"), the set
> was seen but empt ("(empty)") and the set was seen and contains one
> element with an empty string ("").
> > Besides obviously breaking typing, what about when the type actually
> > accepts the unset character... what if the user-agent is - or (empty)
> > couldn't that cause downstream errors?
> In that case, the character should be replaced by the escaped version of
> it (i.e. you should find \x[ascii-code] or similar) in the log-file
> instead of the -. Hence, it should still be decideable which of the two
> cases happened.
> > "You can change the logs to log however you want" is likely the
> > answer, and correct I can, but shouldn't we try be logical in our
> > so assumptions aren't made on the default material?
> I hope this helps,
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Bro