Forum Discussion
Chris_Phillips
Nimbostratus
Nimbostratusstream profile not rewriting 302's
Hi,
this isn't really iRule related, but as it was here that showed me the light baout using stream instead of HTTP::collect and regsub, i'm hoping you'll let this pass.
I have a stream profile which is generally running fine, with both a serverssl and clientssl profile on it. Sometimes though the stream does not rewrite the data correctly. I can not be 100% sure, but i have only seen this happen with HTTP 302 redirection pages. should the stream profile be catching these? could this behaviour be identified under other simnilar circumstances i could have missed?
another thought that struck me was should i possibly be handling the 302's myself within an irule, and never bothering to tell the client end? is that even possible? to me it doesn't sound too wise...
btw, I have followed more formal suport routes, but they gave back the party line that you should only use stream profiles for RTSP, end of. Certainly not the story I get here!
Thanks
Chris
hoolioCirrostratus
Hi Chris,
There was a misconception in some documentation (Click here for example) that the stream profile was for real time streaming protocol. That's incorrect and should be updated to note the actual purpose (search/replace within data content). SOL4486 has been drafted to note that the 9.x config guide's entry on the stream profile is incorrect.
I believe I found the case you opened with support and have asked them to work with you to troubleshoot the issue you reported.
In theory you could rewrite the request if you know it will be redirected, but that would require building a fair amount of application logic (which could change) into your rule. I think it would be better to figure out why the stream profile isn't working as expected though.
Aaron
Chris_Phillipsthanks 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:
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.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 } }
btw, is it possible to remove the need for that intermediate "newlocation" variable? any equivalent one liners?
Thanks
Chris- The stream profile will only transform payload, not headers, which is probably why you are not seeing the 302's being re-written...
And hoolio is correct, we use it for HTTP all the time.
HTH
/deb - Chris_Phillipswell certainly good to hear something back so definite. would you be able to explain why this is the case? if you're looking at the data outside of the http scope, how does the stream profile know what to replace and what not to replace? doesn't a header just look like generic text data like the content? i mean.. you could run a stream profile on Telnet or snmp if you chose to, right?
- Depends what you mean as data (that's a loaded question when you deal with different protocols).
When you do add an HTTP profile to the virtual as in your case, the stream filter will see just the data as in HTTP data and none of the headers (HTTP headers). I can understand this can be confusing if you don't understand the subtlety.
You can treat the HTTP headers as data by associating just the tcp profile but you may be throwing the baby out with the bath water. - Chris_Phillipsahh right, i assumed that the stream runs outside of any protocol knowledge, and would just see all raw data as it flew past on the wire. that makes sense now, thanks.
- hoolioA one-liner for the Location header rewrite? This is close (no variables anyhow). Also, string map should be more efficient than regsub.
when HTTP_RESPONSE { if { [HTTP::status] contains "302" && [string tolower [HTTP::header Location]] contains "host_to_replace" }{ HTTP::header replace Location [string map -nocase {"host_to_replace" "new_host"} [HTTP::header Location]] } } - Chris_Phillipsoops, forgot to reply... thanks that's great, just what i needed!
Bert_Vandebroekdude !!!!
life saver!!!!!!!
lost almost a day wiresharking what went wrong with the redirects while I had the stream in place
thanks for this
