Forum Discussion

East_Coast_1151's avatar
East_Coast_1151
Icon for Nimbostratus rankNimbostratus
Aug 20, 2013

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

  • This has been asked in the other related posts, but have you tried with a STREAM profile?

     

  • 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 
      } 
    } 
    
  • 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?

     

  • 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 disable
    

    Changing 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

  • 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.