* Logging activity is currently focused on messages.
* Does command oriented logging still make sense for SMTP?
* Remaining (known) weak points:
* Poor handling of wrapped message headers.
* Poor separation into various scripts by functionality.
* base.bro will likely include nothing after 'DATA'.
* Out of order command/response pairs are not supported yet.
The customization point is provided between the time a file
to be extracted has it's file handled opened and when the first
chunk of data is written to disk.
* Multiple pipelined requests before any replies is now supported.
* HTTP::build_url function that takes a connection and builds a
url current request/response pair.
* I left in an example to show a likely bug with the record
extension mechanism.
* New script: http/file-extract.bro
* New script: http/file-ident.bro
* New script: http/file-hash.bro
* Lot of cleanup. The output logs are better than before.
Removing everything related to trace rewriting.
(I wasn't too careful in ensuring that I catch everything in the
scripts; Seth is working on those anyway.)
(Merging by cherry-picking the corresponding commit, as the branch was
accidentally made off of the logging stuff).
* The http.bro script only loads other scripts now.
* http/base.bro configures the analyzer in the core
and does minimal state collection.
* http/base-extended.bro adds extra state collection
that may not always be desired.
* http/detect-intel.bro is where intelligence based
detection that we ship will take place.
* http/detect.bro is where behavioral and scripted (known)
actions will be detected.
* http/utils.bro are http specific utility functions
* http/var-extraction* scripts add cookie and uri key values
to the base state collection and logging. They are also
maintained in a vector so that order is presevered.
The var-extraction* and base-extended scripts are good examples
of how the base script extension model works.
This also has an inital try at storing the "Info" state table
in the connection record.
The &log keyword now operates as discussed:
- When associated with individual record fields, it defines them
as being logged.
- When associated with a complete record type, it defines all fields
to be logged.
- When associated with a record extension, it defines all added
fields to be logged.
Note that for nested record types, the inner fields must likewise
be declared with &log. Consequently, conn_id is now declared with
&log in bro.init.
Vectors are now allowed to be logged and will be recorded as an
ordered set of items.
* I haven't removed handwritten analyzer code yet although it isn't built anymore.
* The ssl.bro script is just an example and doesn't keep any state yet.
We may be fixing up the binpac ssl analyzer and getting
rid of the C++ one. As I look closer and closer and at
C++ analyzer, I'm less impressed with the events it
outputs due to it maintaining state differently in the
core than most other analyzers. Subsequently, the
events that it generates are also significantly
different from those of other analyzers.
