Forum Discussion

JCMATTOS_41723's avatar
JCMATTOS_41723
Icon for Nimbostratus rankNimbostratus
Dec 02, 2008

Proxypass with page content modification?

We are currently using the proxypass irule and are trying to add page content modifications and keep getting this error. We followed the instructions and uncommented the two STREAM lines below and added a blank stream profile but still no luck? Any ideas? (We are running 9.4.5 HotFix2 on the LTM). Has anyone else had problems enabling this feature?

 

 

Tue Dec 2 16:26:37 PST 2008 tmm tmm[10220] 01220001 TCL error: ProxyPass HTTP_RESPONSE - Operation not supported line 1 invoked from within STREAM::enable

 

 

7 Replies

  • Colin_Walker_12's avatar
    Colin_Walker_12
    Historic F5 Account
    Could you post your current iRule that is generating those errors? It would be helpful to see exactly what it is you're using, and what was uncommented, etc.

     

     

    Colin
  • In 9.3.1 and 9.4.2 there was a change to the validation for STREAM::enable. You must set the stream expression before enabling the stream filter. I'm pretty sure the proxypass rule was written before this restriction was added:

    The fix is simple (Click here). Just set the stream expression and then enable the filter:

      
               STREAM::expression "@$host_serverside$path_serverside@$host_clientside$path_clientside@"  
               STREAM::enable  
      

    Aaron
  • Excellent...Thx Hoolio! Strange though it doesnt seem that the page mod is working as expected? Shouldn't the changes be reflected on any matching links in the entire page when added to the data group list? It seems the links within the page are not being rewritten but the header is. Am I missing something? Our main goal is to rewrite image links with the corresponding names.

     

     

    This is what I have in my data group list:

     

     

    test-example.com www.example.com (working as expected)

     

    images-example.com images.example.com (page content links not being rewritten)
  • Can you log the value for "@$host_serverside$path_serverside@$host_clientside$path_clientside@" and see if that matches what you're seeing in the payload for the string(s) to replace?

     

     

    If it does look right, then it might be server compression. LTM doesn't decompress response content so the stream filter wouldn't match. Ideally, you would be able to reconfigure the pool members to disable compression. Else, you can disable compression by rewriting the Accept-Encoding header to no value in the request.

     

     

    Also, it would be more efficient to check if the response content type is text as you don't want to apply the stream filter against binary content. To update this you can change:

     

     

    if {1 != $bypass} {

     

     

    to:

     

     

    if {1 != $bypass && [HTTP::header value Content-Type] starts_with "text"} {

     

     

    Aaron
  • According to the logs looks like the the compression is affecting it. Still new to this so can I add a rewrite rule to the Accept header to "no" value in data group list or will it need to be in the irule itself? Can you please point me in the right direction? Thx!
  • I did this once before but can't find the exact rule. If I remember correctly, using HTTP::header replace Accept "" doesn't actually replace the value of the header. I ended up using something like this:

      
      when HTTP_REQUEST {  
        
         HTTP::header replace Accept-Encoding [list ""]  
      }  
      when HTTP_REQUEST priority 501 {  
         log local0. "\[HTTP::header value Accept-Encoding\]: [HTTP::header value Accept-Encoding]"  
      }  
      

    If that doesn't null the value of the Accept-Encoding header, can you try this:

      
      when HTTP_REQUEST {  
        
         HTTP::header replace Accept-Encoding [list {}]  
      }  
      when HTTP_REQUEST priority 501 {  
         log local0. "\[HTTP::header value Accept-Encoding\]: [HTTP::header value Accept-Encoding]"  
      }  
      

    Once you're done testing, you can remove the HTTP_REQUEST 501 event as it's just there for debugging. You could use this as a separate rule or add it into your full proxypass rule.

    Aaron
  • Sorry for any confusion. The header which determines compression methods that the client supports is 'Accept-Encoding' not Accept. If you remove the Accept-Encoding header altogether, the server should not compress the response content:

     
     when HTTP_REQUEST { 
      
        if {[HTTP::header exists "Accept-Encoding"]}{ 
      
           log local0. "Removing Accept-Encoding header" 
      
            Remove the Accept-Encoding header from the request 
           HTTP::header remove "Accept-Encoding" 
        } 
     } 
     

    Aaron