Forum Discussion
Julio_Vivero_48
Nimbostratus
NimbostratusHTTP Payload replace - charset problem
Hi everyone,
I'm trying to use the HTTP payload replace irule that is available at this forum but i'm facing the following problem:
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.
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:
"TCL error: Rule response_change_https - invalid command name "encoding" while executing "encoding convertto iso-8859-1 $new_response"
Any idea would be of great help.
Thanks in advance.
Best regards,
Julio
David_SlimoviciHi,
I have the same problem as you , and it does not seem to be a specific problem (forum question 9062 for instance).
I have created a case with F5 support, I will tell tou the answer in the next few days(if I get one).- Have you tried using the stream profile instead of the iRule?
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.
I'd be interested to hear if you had the same issue.
Thanks,
Colin - 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)
/deb 
Tomasz_RadziszeI 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?
I found another threads on this forum, referencing similar problems
http://devcentral.f5.com/Default.aspx?tabid=53&view=topic&forumid=5&postid=9062
http://devcentral.f5.com/Default.aspx?tabid=53&view=topic&forumid=5&postid=3093- 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.
/deb - Tomasz_RadziszeI am using BIG-IP 9.4.0 and I have already reported a support case regarding the problem with TCP::payload replace. The case number is C371366. I am waiting for solution now.
- OK, great.
Looks like you've discovered a product defect, and the case is progressing well, so I'll wait for resolution as well before escalating anything further.
/deb - CR47762 created-- but the RFE seems not to be accept, workaround is to use
binary format c* {1 2 3 0 }
instead of "\0x01\0x02\0x03\0x00"
