ProxyPass redirect problem

Can you enable logging on the iRule and post anonymized copies of the logs from a success and a failure?

 

 

Thanks,

 

Aaron

Checking out the debug log it appears that it is working correctly. The /login is proxy'd, however when being transferred to /admin I'm still get responses from the backend server that is being served through proxypass only, even though in the log it says "no rule found".

 

 

The actual line is "Host=some.server.edu, URI=/admin): No rule found" which ends up being processed by the wrong backend server.

To note if I leave the page alone for about two minutes and click refresh it will go to the correct server then.

The first was a failure. This is a log from a success under Safari.

Unless I'm missing something here, you are only using ProxyPass to choose alternate pools in those two cases. If so, I recommend using HTTP Classes to do the same thing a lot more efficiently and with less hassle.

I'm willing to try using HTTP classes, however some of the backend authentication may or may not work, which was why I was going with the ProxyPass rule first. Are there any examples that I can code this from, as I am very new to the BigIP? This is really odd behavior for the ProxyPass irule though, if anyone still has some idea what's happening?

Is this the symptom of the failure?

 

 

You expect the request which fails to go to the default pool on the VIP, but instead it's going to the pool specified in the datagroup? If so, it might be a relatively simple fix to get the name of the VIP's default pool and then use it if the pool isn't specified in the datagroup.

 

 

Aaron

Yes, I expect the failed match to go to the default pool on the VIP. It works for everything except when I try to redirect back to the default pool from within an alternate pool specified in the datagroup.

 

 

Hmm, might be able to hard code it into the proxypass irule. The weird thing is the debug log says it isn't a match, yet it still gives me the alternate pool. I might need to look further into the actual code as their might a bug, but it works for one browser perfectly.

I think there are two possible issues with the ProxyPass iRule:

 

 

- the default pool might not get used for multiple requests on the same TCP connection if one request has a pool set from the class and a subsequent request doesn't.

 

 

- the stream filter is left enabled for all responses on the same TCP connection.

 

 

Are you using a stream profile on the VIP?

 

 

I'm working on a couple of tweaks to the iRule now to fix these problems. I should have it ready to test shortly.

 

 

Aaron

Actually, a lot of the rule doesn't seem to be working for me as I would have expected. I'll see if I can test it more thoroughly later. For now, can you try replacing this section:

 
              if {$newpool != ""} { 
                  pool $newpool 
                  if {$snataddr != ""} { 
                      snat $snataddr 
                      HTTP::header insert X-Forwarded-For [IP::remote_addr] 
                  } 
              } 
 

with this section:

 
              if {$newpool eq ""} { 
                  pool $default_pool 
              } else { 
                  pool $newpool 
                  if {$snataddr != ""} { 
                      snat $snataddr 
                      HTTP::header insert X-Forwarded-For [IP::remote_addr] 
                  } 
              } 
 

You'll also need to add a section above "when HTTP_REQUEST":

 
 when CLIENT_ACCEPTED { 
  
     Get VIP's default pool name 
    set default_pool [LB::server pool] 
 } 
 

That should fix the potential issue where a request would be sent to the pool specified in the class instead of the default pool.

I couldn't get the response payload rewriting to work at all. But if you're using the stream filter and seeing an error with the incorrect rewriting of response content, I think this change should fix the problem. Note that this change will actually generate a runtime error if you use it without a stream profile.

Original:

 
 when HTTP_RESPONSE { 
    if {1 != $bypass} { 
 

Updated:

 
 when HTTP_RESPONSE { 
    if {$bypass == 1} { 
        Disable the stream filter by default 
       STREAM::disable 
    } else { 
 

Aaron