<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Thanks for the input.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">
1. At some point in the past, ISTR bro did have a connection_end event - at least thats what my failing memory tells me. In any event, it seems like a bug to not even give a warning if you have an event handler for a non-existent event - a typo could cause difficult to detect errors.</div>
<div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">2. Good catch, probably should have an expiration.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">
<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">The minor inconsistency that I had in mind is the fact that the length of the entity is checked whilst assembling the POST response without unescaping, and checked unescaped in the http_end_entity..</div>
<div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Wed, Apr 30, 2014 at 11:15 AM, Siwek, Jonathan Luke <span dir="ltr"><<a href="mailto:jsiwek@illinois.edu" target="_blank">jsiwek@illinois.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=""><br>
On Apr 30, 2014, at 12:18 PM, Jim Mellander <<a href="mailto:jmellander@lbl.gov">jmellander@lbl.gov</a>> wrote:<br>
<br>
> For a number of reasons, I elected to write the attached bro policy, which looks at http POSTs and performs regular expression matching on the posted data.<br>
<br>
</div>Thanks for sharing.<br>
<br>
> Kudos to the first person who finds the minor inconsistency that I elected not to address.<br>
<br>
Maybe not what you were referring to, but I had two concerns:<br>
<br>
(1) “connection_end” doesn’t seem to be a defined event, maybe it's meant to be “connection_state_remove”.<br>
<br>
(2) Having the global “POST_entities” and “POST_requests” tables without &read_expire (or another expiry attribute) makes me nervous. Though I think the clean up in “http_end_entity” should catch everything, if it doesn’t, that will lead to memory usage issues over time (especially since “connection_end” won’t be a cleanup safety net as intended).<br>
<br>
- Jon</blockquote></div><br></div>