Forum Discussion
Chris_Phillips
Sep 26, 2006Nimbostratus
thanks for the reply. i assume you've seen the response (C297305) we got but the wording was really fairly unambiguous...unfortunately I must tell you that the stream profile is only intended to manipulate RTSP traffic, and may lead to 'unpredictable results' if you're using it to manipulate HTTP traffic.certainly contrasts heavily with you guys.
what i did today was add back in an HTTP_RESPONSE event:
when HTTP_RESPONSE {
do replace on Location header if we get one (e.g. http redirections) - not covered by stream profile
if { [HTTP::header exists Location] } {
regsub "remotedomain.com" [HTTP::header Location ] "localdomain.com" newlocation
HTTP::header replace Location $newlocation
}
}
which has exactly cleared up what i was seeing and i've not had any other issues, although my testing has not been that extensive. if the stream profile is protocol agnostic, then i can't see any reason this shouldn't work without this addition, unless the encoding of the strings is different here than in the http payload itself. not checked this to be honest. i'll see what wireshark has to say about it maybe.btw, is it possible to remove the need for that intermediate "newlocation" variable? any equivalent one liners?
Thanks
Chris