[Bro] Bro Types Not Following Bro Types Documention
john at omernik.com
Mon May 18 09:35:15 PDT 2015
Solid point on the difference. Thanks for clarifying. This is a tough
problem. One of our systems, has a concept of null vs. empty strings in a
final storage, but as pointed out, that makes things difficult from a human
readable aspect. (What I mean there is if the referer doesn't exist, the
field is NULL, if it does and is empty it's a "")
I wonder if like (empty) unset may also be "more" verbose. I know that
seems counter intuitive, especially to my point on types, but - may be
error prone, especially on string fields (it's more obviously on non-string
fields), but what if we went with (unset) instead? at least in that case,
if it gets down stream to someone who isn't clear on how Bro is doing
things, there is more of a chance that they will understand that it didn't
exist vs. just assuming - is the value that was passed. Issues here are
obviously backwards compatibility and creating larger log files.
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