<div dir="ltr"><div>It's an oversight that there isn't a helper function to retrieve transactions on a connections. I will add one tomorrow.<br><br></div>Having said that, what is your use case that you require to retrieve transactions? I thought your code was driven by the callbacks, which all come with a tx instance (via connp)? For my education, can you explain how you process connection data?<br>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Apr 8, 2013 at 3:54 PM, Anoop Saldanha <span dir="ltr"><<a href="mailto:anoopsaldanha@gmail.com" target="_blank">anoopsaldanha@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Mon, Apr 8, 2013 at 7:50 PM, Brian Rectanus <<a href="mailto:brectanu@gmail.com">brectanu@gmail.com</a>> wrote:<br>

><br>
> On Mon, Apr 8, 2013 at 9:16 AM, Brian Rectanus <<a href="mailto:brectanu@gmail.com">brectanu@gmail.com</a>> wrote:<br>
>><br>
>><br>
>> On Mon, Apr 8, 2013 at 8:47 AM, Anoop Saldanha <<a href="mailto:anoopsaldanha@gmail.com">anoopsaldanha@gmail.com</a>><br>
>> wrote:<br>
>>><br>
>>> On Mon, Apr 8, 2013 at 3:42 PM, Victor Julien <<a href="mailto:victor@inliniac.net">victor@inliniac.net</a>><br>
>>> wrote:<br>
>>> > (moving to oisf-devel)<br>
>>> ><br>
>>> > On 04/08/2013 06:17 AM, Anoop Saldanha wrote:<br>
>>> >>>> I recollect we introduced path and query double decoding through<br>
>>> >>>> configurable params, and also we had this thing with query<br>
>>> >>>> decoding(single level).  Can you explain a bit what the status was<br>
>>> >>>> previously.  Seeing related failed uts.<br>
>>> >>>><br>
>>> >>><br>
>>> >>> We run the path normalization on the query through our<br>
>>> >>> HTPCallbackRequestUriNormalizeQuery callback. Previously we used<br>
>>> >>> htp_decode_path_inplace to normalize the query (e.g. for<br>
>>> >>> uridecoding).<br>
>>> >>> However, this was causing issues (remember that pcre "bug" we<br>
>>> >>> discussed<br>
>>> >>> a while back, where http:// turned into http:/).<br>
>>> >>><br>
>>> >>> In libhtp I copied htp_decode_path_inplace to<br>
>>> >>> htp_decode_query_inplace<br>
>>> >>> and also copied the config params and cfg funcs:<br>
>>> >>><br>
>>> >>> <a href="https://github.com/inliniac/suricata/commit/d41c762689a08e6814dc93e8bfebeceab97175c3" target="_blank">https://github.com/inliniac/suricata/commit/d41c762689a08e6814dc93e8bfebeceab97175c3</a><br>

>>> >>><br>
>>> >>> Hack of the 1st order, which is wrong in many ways. But it basically<br>
>>> >>> allowed me to make sure we don't normalize the query as if it's path,<br>
>>> >>> esp with turning ftp:// into ftp:/ and such.<br>
>>> >>><br>
>>> >>> For 0.5 integration I think we need a proper solution. The only<br>
>>> >>> reason I<br>
>>> >>> pushed my hack like this was that I knew in 0.5 we would make things<br>
>>> >>> right.<br>
>>> >>><br>
>>> >><br>
>>> >> I think if we still want to double decode, we still require all of<br>
>>> >> these above things from our bundled htp.<br>
>>> >><br>
>>> >> -----<br>
>>> >><br>
>>> >> In 0.5.x, tx->request_uri_normalized has been removed, and we'd now<br>
>>> >> have to use the REQUEST_URI hook.  We'll have to carry out the<br>
>>> >> reconstruction ourselves, and store it ourselves in our HTPState.<br>
>>> >><br>
>>><br>
>>> What are your thoughts on this?<br>
>>><br>
>>> ><br>
>>> > IIRC there is some function in libhtp that does just the decoding of<br>
>>> > uriencoding and unicode. We should probably just use that on the query<br>
>>> > and do the full normalization on the path.<br>
>>> ><br>
>>> > As a side thought: I think it would be nice to store path and query<br>
>>> > separately so that we can add http_path and http_query keywords later<br>
>>> > on.<br>
>>> ><br>
>>><br>
>>> We'd pretty much extract it directly from parsed_uri.  Will have to<br>
>>> check if we need the extract double decode phase we have currently in<br>
>>> our bundled htp, in which case we'd need to store them separately.<br>
>>><br>
>><br>
>> Yes, all the normalized components are in tx->parsed_uri.  This is what is<br>
>> used in ironbee to expose all the various parts like tx->parsed_uri->path<br>
>> and tx->parsed_uri->query.<br>
>><br>
>> Also note that the hostname should now be obtained from<br>
>> tx->request_hostname in 0.5.<br>
>><br>
>> -B<br>
><br>
><br>
> FYI, for an example using libhtp 0.5 see ironbee code.  This was all<br>
> recently updated for 0.5.<br>
><br>
> <a href="https://github.com/ironbee/ironbee/blob/0.7.x/modules/modhtp.c" target="_blank">https://github.com/ironbee/ironbee/blob/0.7.x/modules/modhtp.c</a><br>
><br>
<br>
</div></div>Will have a look.  Thanks.<br>
<br>
Previously we would use tx->connp->conn->transactions to access txs<br>
in the state.  Now that htp_connp_t is an opaque pointer how do I<br>
access the txs? Tried locating helper functions to retrieve it, but I<br>
didn't find any.<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
Anoop Saldanha<br>
_______________________________________________<br>
Suricata IDS Devel mailing list: <a href="mailto:oisf-devel@openinfosecfoundation.org">oisf-devel@openinfosecfoundation.org</a><br>
Site: <a href="http://suricata-ids.org" target="_blank">http://suricata-ids.org</a> | Participate: <a href="http://suricata-ids.org/participate/" target="_blank">http://suricata-ids.org/participate/</a><br>
List: <a href="https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-devel" target="_blank">https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-devel</a><br>
Redmine: <a href="https://redmine.openinfosecfoundation.org/" target="_blank">https://redmine.openinfosecfoundation.org/</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Ivan Ristić<br>
</div>