Events after HTTP_REQUEST

Here are the events you can write rules against, at least the ones that I'm aware of:

 

 

 

iRULE events

 

global

 

CLIENT_ACCEPTED

 

CLIENT_DATA

 

SERVER_SELECTED

 

SERVER_CONNECTED

 

SERVER_DATA

 

RULE_INIT

 

http

 

HTTP_REQUEST

 

HTTP_REQUEST_DATA

 

HTTP_RESPONSE

 

HTTP_RESPONSE_DATA

 

HTTP_RESPONSE_CONTINUE

 

ssl

 

CLIENTSSL_HANDSHAKE

 

CLIENTSSL_CLIENTCERT

 

SERVERSSL_HANDSHAKE

 

authentication

 

AUTH_FAILURE

 

AUTH_ERROR

 

AUTH_WANTCREDENTIAL

 

AUTH_SUCCESS

 

Looks like I might be able to use

 

 

LB_SELECTED (Triggered when the LTM system has selected a target node.)

For a single connection here's the order of the HTTP events fired

Request:

CLIENT_ACCEPTED

HTTP_REQUEST

HTTP_REQUEST_DATA (** if HTTP::collect called in HTTP_REQUEST)

LB_SELECTED

SERVER_CONNECTED

Response:

HTTP_REQUEST_SEND

HTTP_RESPONSE

HTTP_RESPONSE_DATA (** if HTTP::collect called in HTTP_RESPONSE)

SERVER_CLOSED

CLIENT_CLOSED

You can test this out with the following rule (look in /var/log/ltm for the output):

when RULE_INIT {  
    log local0. "in RULE_INIT"  
  }  
  when HTTP_CLASS_SELECTED {  
    log local0. "in HTTP_CLASS_SELECTED"  
  }  
  when HTTP_REQUEST {  
    log local0. "in HTTP_REQUEST"  
  }  
  when HTTP_REQUEST_DATA {  
    log local0. "in HTTP_REQUEST_DATA"  
  }  
  when HTTP_REQUEST_SEND {  
    log local0. "in HTTP_REQUEST_SEND"  
  }  
  when HTTP_RESPONSE {  
    log local0. "in HTTP_RESPONSE"  
  }  
  when HTTP_RESPONSE_DATA {  
    log local0. "in HTTP_RESPONSE_DATA"  
  }  
  when HTTP_RESPONSE_CONTINUE {  
    log local0. "in HTTP_RESPONSE_CONTINUE"  
  }  
  when CLIENT_ACCEPTED {  
    log local0. "in CLIENT_ACCEPTED"  
  }  
  when CLIENT_CLOSED {  
    log local0. "in CLIENT_CLOSED"  
  }  
  when CLIENT_DATA {  
    log local0. "in CLIENT_DATA"  
  }  
  when SERVER_CLOSED {  
    log local0. "in SERVER_CLOSED"  
  }  
  when SERVER_DATA {  
    log local0. "in SERVER_DATA"  
  }  
  when LB_SELECTED {  
    log local0. "in LB_SELECTED"  
  }  
  when LB_FAILED {  
    log local0. "in LB_FAILED"  
  }  
  when NAME_RESOLVED {  
    log local0. "in NAME_RESOLVED"  
  }  
  when USER_REQUEST {  
    log local0. "in USER_REQUEST"  
  }  
  when USER_RESPONSE {  
    log local0. "in USER_RESPONSE"  
  }  
  when SERVER_CONNECTED {  
    log local0. "in SERVER_CONNECTED"  
  }  
  when SERVER_LINE {  
    log local0. "in SERVER_LINE"  
  }

This isn't an exhaustive list of events, but the ones related to HTTP connections without ssl, auth, etc profiles associated with them.

One thing to note is that the LB_SELECTED event will only be fired when a new load balancing decision has been made. Keep-alive connections will receive the other events, but only the LB_SELECTED event when it's at the start of a new session. If you want the last event before the data is sent, I'd use the HTTP_REQUEST_SEND event.

-Joe

Joe~

 

 

Awesome, thanks for the information.

 

 

If I use the HTTP_REQUEST_SEND event, is there a way to access (in the iRule) which node the request is about to be sent to?

 

 

Basically I am trying to make it act like a true reverse proxy in this instance, and once it selects a server, I want to replace all occurrences of the Big IP's host name within HTTP::host with the host name of the selected server.

 

 

Thanks.

Sure is. The IP::server_addr and TCP::server_port should get you what you need.

when HTTP_REQUEST_SEND { 
   log local0. "server addr: [IP::server_addr]" 
   log local0. "server port: [TCP::server_port]"  
 }

-Joe

HTTP_REQUEST_SEND is a server-side event. Try using LB_SELECTED instead. You can use the LB::server command to get information about the selected pool member. I'm not entirely sure that the rule syntax checker will allow HTTP commands from within LB_SELECTED, but it might.

Here are some relevant subcommands. LB::server without any options returns a list that includes the pool name, address, and port.

 
 LB::server pool 
 LB::server addr 
 LB::server port 
 

I'm not quite sure I understand what your request is here. You implied above that you wanted it to act like a true reverse proxy. This would have more to do with modifying the response than the request, as the url's in the response should get mapped from the server's host name to the BigIP's host name. I can't think of how mapping the Host: request header into the target of the request would help you.

 

 

We had a guy here who configured up an iRule to do reverse proxying. I'll see if I can track it down and post it here.

Looks like I had it backward for the HTTP_REQUEST_SEND event. Thanks drteeth!

 

 

As for the HTTP commands in the LB_SELECTED method, it looks like you'll have to associated a FASTHTTP profile to your virtual to be able to access those methods in the LB_SELECTED event as I'm getting the following error message when trying to apply it

 

 

HTTP::header in rule (rulename) requires an associated FASTHTTP profile on the virtual server (servername).

 

 

-Joe

The error message about a FASTHTTP profile beging required is incorrect. Did you have an HTTP profile?

Our config for the virtual server is using an HTTP profile and TCP as the protocol