HTTP Payload replace - charset problem

Question

Hi everyone,&nbsp;
&nbsp;I'm trying to use the HTTP payload replace irule that is available at this forum but i'm facing the following problem:&nbsp;
&nbsp;The web where i'm trying to use this irule is encoded with iso-8859-1 charset, but for some reason it seems that the i-rule changes the encoding of the http payload to utf-8, and hence the client browser does not display correctly some characters like accents, etc.&nbsp;
&nbsp;I've tried to use the encoding command from tcl to force a conversion to iso-8859-1 but (though there is not error message when I introduce it at the LTMs administration web) I get the following error message at the ltm log, when the irule is executed:&nbsp;
&nbsp;"TCL error: Rule response_change_https  - invalid command name "encoding"     while executing "encoding convertto iso-8859-1 $new_response"&nbsp;&nbsp;
&nbsp;Any idea would be of great help.&nbsp;
&nbsp;Thanks in advance.&nbsp;
&nbsp;Best regards,
&nbsp;Julio&nbsp;&nbsp;

david_slimovici · Answer

Hi,&nbsp;
&nbsp;I have the same problem as you , and it does not seem to be a specific problem (forum question 9062 for instance). 
&nbsp;I have created a case with F5 support, I will tell tou the answer in the next few days(if I get one).

colin_walker_12 · Answer

Have you tried using the stream profile instead of the iRule?&nbsp;
&nbsp;The stream profile is a relatively new feature that provides the payload replacement functionality out of the box.  It's also a bit more robust, faster, etc.&nbsp;
&nbsp;I'd be interested to hear if you had the same issue.&nbsp;
&nbsp;Thanks,
&nbsp;Colin

deb_allen_18 · Answer

Don't forget that if you use the stream profile with different length source and target values, and your servers are sending data unchunked, you'll need to enable re-chunking on the HTTP profile, otherwise the Content-Length header will still contain the original (now incorrect) content length value (headers are sent before the stream replacement is performed)&nbsp;
&nbsp;/deb

tomasz_radzisze · Answer

I have found similar problem. I am reading packet content with TCP::payload and then writing it to another packet using TCP::payload replace. The packet contains binary data (including a lot of zeros). After rewriting it is different and longer than original. In particular, it seems that byte 00 is changed to two bytes: C080. It damages my data. What can I do about it? Did the support solve this?&nbsp;
&nbsp;I found another threads on this forum, referencing similar problems
&nbsp;http://devcentral.f5.com/Default.aspx?tabid=53&amp;view=topic&amp;forumid=5&amp;postid=9062
&nbsp;http://devcentral.f5.com/Default.aspx?tabid=53&amp;view=topic&amp;forumid=5&amp;postid=3093&nbsp;

deb_allen_18 · Answer

I've dug up a number of other posts on the same topic as well. Please post back with the version(s) you've tested on, and I'll escalate a consolidated case to Support.&nbsp;
&nbsp;/deb

Forum Discussion

HTTP Payload replace - charset problem

8 Replies

Recent Discussions

Need help on i-rule to specific uri path

Reverse Proxy Not Behaving

F5 terminal - help to run commands - disk space full

vulnerabilities-CVE-2020-16150 & CVE-2013-0169

google autenticator broken barcode

Related Content

SSL::payload replace - silent failure?

Replacing packet payload contents

Large payload post requests aren't responding

string first replacement procedure for ID999881

ADFS Proxy Replacement on F5 BIG-IP