Forum Discussion
HTTP:payload replace - problem with French characters
We are using an irule with "HTTP::payload replace" and "regsub" to modify responses coming from a Microsoft web server.
After replacement, all French characters (like "é", "à") get incorrectly encoded. The original responses use UTF-8.
The irule has been tested in a lab on a virtual BigIP (11.4) without any issues. However the production Viprion (11.4) boxes constantly have this issue.
I found two topics about similar issues.
https://devcentral.f5.com/questions/http-payload-replace-charset-problem15878
https://devcentral.f5.com/questions/modify-utf-8-strings-in-payload
Can anybody tell if this has been fixed?
Thank you in advance
6 Replies
- Kevin_Stewart
Employee
This has been asked in the other related posts, but have you tried with a STREAM profile?
- East_Coast_1151
Nimbostratus
Here is the formatted iRule.
The log file says : - Operation not supported (line 1) invoked from within "STREAM::disable"
What is wrong?
when HTTP_REQUEST { STREAM::disable if { [HTTP::uri] contains "/wcp/session.ashx" } { HTTP::header remove "Accept-Encoding" if { [HTTP::version] eq "1.1" } { if { [HTTP::header is_keepalive] } { HTTP::header replace "Connection" "Keep-Alive" } HTTP::version "1.0" } } } when HTTP_RESPONSE { if {[HTTP::header "Content-Type"] contains "application/x-javascript"} { STREAM::expression {@flag:\"true@flag:\"false@} STREAM::enable } } - Kevin_Stewart
Employee
Silly question, but do you have an empty STREAM profile applied to the VIP?
- Kevin_Stewart
Employee
I just tested that iRule code locally and honestly can't find anything wrong with it. Is there more to this iRule? Are there other iRules applied to the VIP? Is this your actual stream expression, or are you trying to use French characters?
- East_Coast_1151
Nimbostratus
Good point.
I checked the iRule list and found the iRule below that seems to cause a conflict. This iRule is made to avoid expired session errors if users bookmark the logon page.
when CLIENT_ACCEPTED { ACCESS::restrict_irule_events disable } when HTTP_REQUEST { if { [HTTP::uri] ends_with "/my.logout.php3?errorcode=19" } { HTTP::redirect "/" } }The line that causes the issue is
ACCESS::restrict_irule_events disableChanging the iRule order seems to have no effect.
I do not understand why this happens. What can I do to use this iRule with STREAM?
Or there maybe is another way to intercept expired session and f5 error pages before they are shown to users?
Thank you
- Kevin_Stewart
Employee
Ah, that makes more sense. The ACCESS::restrict_irule_events command is allowing you to see the access policy process in the HTTP event structure, and subsequently failing when you try to modify a response in the stream. Here's something, albeit crude, that should work. I've combined both iRules into one.
when CLIENT_ACCEPTED { ACCESS::restrict_irule_events disable } when HTTP_REQUEST { STREAM::disable if { [HTTP::uri] ends_with "/my.logout.php3?errorcode=19" } { HTTP::redirect "/" } elseif { [HTTP::uri] contains "/public" } { HTTP::header remove "Accept-Encoding" if { [HTTP::version] eq "1.1" } { if { [HTTP::header is_keepalive] } { HTTP::header replace "Connection" "Keep-Alive" } HTTP::version "1.0" } } } when ACCESS_ACL_ALLOWED { set procstream 1 } when HTTP_RESPONSE { if { [info exists procstream] } { if {[HTTP::header "Content-Type"] contains "text"} { STREAM::expression {@flag:"true@flag:"false@} STREAM::enable } } }It may require some tweaking, but the idea is to make sure the access policy evaluation is complete before attempting to rewrite the server's response. The ACCESS_ACL_ALLOWED event is only triggered on requests AFTER the policy is complete.
Help guide the future of your DevCentral Community!
What tools do you use to collaborate? (1min - anonymous)Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com