On Fri, 16 Jan 2015 12:27:29 -0600 "Alan M. Carroll" <a...@network-geographics.com> wrote:
> Friday, January 16, 2015, 12:17:35 PM, you wrote: > > > Yeh +1 from me on not firing TXN_START unless it's really HTTP. Though, > > maybe the right approach is to keep the current event timing, but only fire > > TXN_START on HTTP ports? > > We still want to fire that event on HTTP transactions on SSL ports if it's > actually an HTTP transaction. The problem here is that we don't really know > it's HTTP even on an HTTP port until we've parsed the request header and at > that point we've advanced to the READ_REQUEST_HDR state. A plugin may also > want to switch to a blind tunnel before any request is parsed at all, based > on IP addresses. So I think we have to live with TXN_START happening even in > non HTTP cases. > Therein lies another question. Do we accept a 'hard' association between protocol and port? If yes, we configure port(s) as HTTP and reject anything arriving that's not HTTP (noting that HTTP processing is a subset of HTTPS, and may have commonality with other protocols) If no, then we need to parse (or at least pattern-match) an HTTP request line to detect HTTP. If starting from scratch I'd do both. That is to say, allow ports to be configured to a protocol (and drop/reject anything inappropriate thereunto), but also detect the request line in data before firing a TXN_START event. -- Nick Kew
