Forum Discussion

Bruce_Hampton_1's avatar
Bruce_Hampton_1
Icon for Nimbostratus rankNimbostratus
Jun 27, 2012

Logging HTTP::request pre and post HTTP profile

I thought this was simple, but I don't have it working just yet.

 

 

I need to log to the local0. the HTTP request as it was received by the LTM, and ALSO as it is being sent out on the server side.

 

 

when HTTP_REQUEST {

 

log local0. [HTTP::request] }

 

 

when HTTP_REQUEST_SEND {

 

log local0. [HTTP::request] }

 

 

 

Of course this doesn't work as HTTP::request is not valid within the server side context.

 

 

Any thoughts?

 

 

Bruce

 

 

8 Replies

  • Hi Bruce,

    HTTP_REQUEST_SEND is a serverside context event. You can use the clientside command to run commands in the clientside context for a serverside event.

    But in this case, you could use priority to log the updated [HTTP::request] value:

    when HTTP_REQUEST {
        log local0. "Pre: [HTTP::request]"
    }
    
    when HTTP_REQUEST priority 501 {
        log local0. "Post: [HTTP::request]"
    }
    
     Not needed to log the updated value, but you can use clientside {} to run the command in HTTP_REQUEST_SEND
    when HTTP_REQUEST_SEND  {
    clientside {
        log local0.   [HTTP::request]
    }
    }
    

    Also note that in 11.0+ HTTP:: get commands show updated values within the same event, if they've been updated.

    Aaron
  • Aaron, clientside {} does not work to me. i still got command is not valid in current event context (HTTP_REQUEST_SEND).

    bhampton, i think pre/post is not different since both log commands are done in HTTP_REQUEST.

    this is an example vip targeting vip. not sure if there is another way to achieve what you want.

    [root@ve1024:Active] config  b virtual bar list
    virtual bar {
       destination 172.28.19.79:80
       ip protocol 6
       rules myrule
       profiles {
          http {}
          tcp {}
       }
    }
    [root@ve1024:Active] config  b rule myrule list
    rule myrule {
       when HTTP_REQUEST {
       log local0. [HTTP::request]
       HTTP::uri "/test"
       virtual bar2
    }
    }
    [root@ve1024:Active] config  b virtual bar2 list
    virtual bar2 {
       snat automap
       pool foo
       destination 1.1.1.1:80
       ip protocol 6
       rules myrule2
       profiles {
          http {}
          tcp {}
       }
    }
    [root@ve1024:Active] config  b rule myrule2 list
    rule myrule2 {
       when HTTP_REQUEST {
       log local0. [HTTP::request]
    }
    }
    
    [root@ve1024:Active] config  curl -I http://172.28.19.79/something
    HTTP/1.1 404 Not Found
    Date: Wed, 27 Jun 2012 17:38:40 GMT
    Server: Apache/2.2.3 (CentOS)
    Content-Type: text/html; charset=iso-8859-1
    
    [root@ve1024:Active] config 
    
    /var/log/ltm
    Jun 27 10:38:29 local/tmm info tmm[4861]: Rule myrule : HEAD /something HTTP/1.1  User-Agent: curl/7.15.5 (i686-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5  Host: 172.28.19.79  Accept: */*
    Jun 27 10:38:29 local/tmm info tmm[4861]: Rule myrule2 : HEAD /test HTTP/1.1  User-Agent: curl/7.15.5 (i686-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5  Host: 172.28.19.79  Accept: */*
    
  • Sorry, you can actually run HTTP::request in HTTP_REQUEST_SEND (for most scenarios), but you need to hide it from the parser (set http_req_cmd "HTTP::request"; log local0. [eval $http]).

     

     

    Regardless, it sounds like Bruce might be trying to log the HTTP request headers before the HTTP profile modifications are performed. This isn't possible using HTTP:: commands as the HTTP profile actions are performed before HTTP_REQUEST is triggered.

     

     

    Bruce, can you clarify what you're trying to accomplish?

     

     

    Aaron
  • You are correct Aaron.

     

     

    I need to show what the LTM received from client , and what it sent - to server - w/o using TCPDUMP.

     

     

    Bruce

     

  • This isn't possible using HTTP:: commands as the HTTP profile actions are performed before HTTP_REQUEST is triggered.thanks!

    just fyi.

    [root@ve1024:Active] config  b virtual bar list
    virtual bar {
       snat automap
       pool foo
       destination 172.28.19.79:80
       ip protocol 6
       rules myrule
       profiles {
          myhttp {}
          tcp {}
       }
    }
    [root@ve1024:Active] config  b profile myhttp list
    profile http myhttp {
       defaults from http
       insert xforwarded for enable
    }
    [root@ve1024:Active] config  b rule myrule list
    rule myrule {
       when HTTP_REQUEST {
       log local0. [HTTP::request]
    }
    
    when HTTP_REQUEST_SEND {
       set req "HTTP::request"
       log local0. [clientside { $req }]
    }
    }
    
    [root@ve1024:Active] config  curl -I http://172.28.19.79
    HTTP/1.1 200 OK
    Date: Wed, 27 Jun 2012 18:16:37 GMT
    Server: Apache/2.2.3 (CentOS)
    Last-Modified: Fri, 11 Nov 2011 14:48:14 GMT
    ETag: "4183e4-3e-9c564780"
    Accept-Ranges: bytes
    Content-Length: 62
    Content-Type: text/html; charset=UTF-8
    
    [root@ve1024:Active] config  
    
    /var/log/ltm
    Jun 27 11:16:26 local/tmm info tmm[4861]: Rule myrule : HEAD / HTTP/1.1  User-Agent: curl/7.15.5 (i686-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5  Host: 172.28.19.79  Accept: */*  X-Forwarded-For: 172.28.19.80
    Jun 27 11:16:26 local/tmm info tmm[4861]: Rule myrule : HEAD / HTTP/1.1  User-Agent: curl/7.15.5 (i686-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5  Host: 172.28.19.79  Accept: */*  X-Forwarded-For: 172.28.19.80
    
  • I can't think of a simple, efficient way to do this with HTTP commands in an iRule. Are there other HTTP profile options you're using besides XFF? If not, maybe you could log the request in HTTP_REQUEST and then insert the XFF after in the iRule?

     

     

    Aaron
  • Actually, as Nitass suggested you could have a frontend VS which doesn't have any HTTP profile options enabled with a logging iRule that also calls a second VS. You could configure the customized HTTP profile on the second VS.

     

     

    Which LTM version are you testing this for?

     

     

    Aaron
  • Testing for 10.2.3

     

     

    VIP to VIP is easy enough - but it is in production - so an irule would be easier to slip in / out than re-plumbing it

     

     

    I'll try to play with a manual insertion of XFF in iRule vs. using the HTTP profile.

     

     

    Bruce