XML Reporting Element URI Redirect

HI,

 

 

Not to contradict support, but I believe a stream profile will operate against any payload (as opposed to header) content regardless of whether it's XML or pure HTML.

 

 

Have you been able to actually test a stream profile and found it to not work?

 

 

Here are a couple of posts related to the stream profile:

 

 

Click here

 

Click here

 

 

Note that when you replace content in the packet with a stream profile you have to set 'Response Chunking' to 'Rechunk' on the HTTP profile.

 

 

Aaron

Support just updated my case with this:

 

 

"Version 9.4 is XML aware. In fact there is an XML profile that you can use prebuilt in the Profiles section, under the Other tab."

 

 

I agree with you that stream profiles are supposed to tear through the entire payload and execute a find and replace opertation on all data types. It was not working that way so I opened a support case.

 

 

At this point, I am going to upgrade to 9.4 and try out the XML Profile. I may be back....

 

 

Thanks for your help!

 

NB

While the case update regarding new features in 9.4 is accurate, hoolio's original comment is even more correct: A simple iRule using the STREAM commands or the stream profile should do the trick, no XML profile or upgrade to 9.4 required.

 

 

You didn't indicate what happens with the stream profile in place, so I'll just re-iterate another important point hoolio made: Be sure you are setting Response Chunking to Re-Chunk in your HTTP profile: If content-length changes due to differing lengths of source v. target strings, some browsers hang when the end of the data isn't @ the value of Content-Length header.

 

 

HTH

 

/deb

 

Stream profile should work with an adjustment to your syntax.

The special character delimiters are only required if you are using only the Target field to specify multiple replacment pairs, like this:

Source: 
Target: @replace this@with this@ @and this@with this@@

For a simple replacement pair, enter the actual text you wish to find and insert, like this:

Source: replace this
Target: with this

HTH

/deb

Thanks for the clarification on the stream profile syntax. I confirmed my config matched the syntax that you provided. I did get the EA key installed and I do now have an XML profile option however it throws an error at me when I click on the create button.

 

 

I took a stab at modifying the cool iRule that scrubs SSN's.

 

 

Here's what I came up with:

 

 

when HTTP_RESPONSE_DATA {

 

Find the text pvineprod01 (target)

 

set target [regexp -all -inline -indices {pvineprod01} [HTTP::payload]]

 

replace the text pvineprod01 with blink.brinker.com

 

foreach target_idx $target {

 

set target_start [lindex $target_idx 0]

 

set target_len [expr {[lindex $target_idx 1] - $target_start + 1}]

 

HTTP::payload replace $target_start $target_len "blink.brinker.com"

 

}

 

}

 

 

I think the switches on the "set target" line are not correct. I visited Sourceforge to view the documentation, but I'm in a little to deep to figure this out. If there is an easier way to accomplish this, please let me know. All I really need to do is swap out the text in a server's response packet.

 

 

Thank you very much for your help,

 

NB

 

 

 

 

 

 

We were able to resolve this issue. What we discovered was that the server had HTTP compression enabled which caused the XML data to be compressed as it passed through the LTM. We originally missed this because our friendly tcpdump tool, Ethereal, was automatically decompressing the HTTP data and displaying it. We modified the HTTP profile to remove the Accept-Encoding header and the STREAM profile began working. XML awareness was not required.

 

 

The LTM was licensed for HTTP compression so we enabled that in the HTTP profile and removed the setting that erased the Accept-Encoding header thinking that the default compression settings would remove that header for us. There's a checkbox in the compression section to remove the header. Unfortunately, that broke the STREAM profile again.

 

 

The moral of this story is that, regardless of enabling HTTP compression, we had to make sure that the Accept-Encoding header was erased in the HTTP profile to get the STREAM profile to work correctly.

 

 

Dave

test