[Bro] Bro Types Not Following Bro Types Documention

[Mike Dopheide]

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.

-Dop

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
> approach
> > so assumptions aren't made on the default material?
>
> I hope this helps,
>  Johanna
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20150518/56084049/attachment-0001.html