For more information regarding the security incident at F5, the actions we are taking to address it, and our ongoing efforts to protect our customers, click here.

Forum Discussion

faheda_5424's avatar
faheda_5424
Icon for Nimbostratus rankNimbostratus
Oct 04, 2013

fire and forget irule?

We have a use case where we need to intercept http requests to a certain URI, send the request to a specified pool, and then immediately respond to the client with a 204. I've tried the irule below, but the traffic never goes to the pool members, but the client does get the 204 response.

when HTTP_REQUEST{
if
{ [HTTP::uri] contains "/the-uri" } { pool my_pool }
HTTP::respond 204
clientside
{TCP::close}

Anyone have any ideas to accomplish this?

Thanks in advance!

application delivery
devops
iRules

3 Replies

  • What_Lies_Bene1's avatar
    What_Lies_Bene1
    Icon for Cirrostratus rankCirrostratus
    Oct 04, 2013

    I'm pretty sure you can't both respond to the client and send the request to the Pool Member. It makes sense that if the iRule is configured to respond to the client then why send the request to the Pool Member? What would be the point in doing both?

     

    I'm sure you are going to tell me that there is a need. Perhaps the HTTP::retry Command would be of some help here? https://devcentral.f5.com/wiki/iRules.HTTP__retry.ashx

     

  • JG's avatar
    JG
    Icon for Cumulonimbus rankCumulonimbus
    Oct 04, 2013

    I'd try to use "HTTP::respond 204" in the HTTP_RESPONSE phase, for that's after the client's request has made it to the backend server. You'll also need to remove all the stuff you received from the backend server.

     

  • Kevin_Stewart's avatar
    Kevin_Stewart
    Icon for Employee rankEmployee
    Oct 04, 2013

    Okay, this may be a little hokey, but I think I have something that'll work.

    when HTTP_REQUEST {
    set vip "access-test-internal-vs"

     prepare the sideband call
    set conn [connect -timeout 3000 -idle 30 -status conn_status $vip]

     send the sideband call
    log local0. "sending sideband call"
    set send_info [send -timeout 3000 -status send_status $conn [HTTP::request]]

    log local0. "sending 204"
    HTTP::respond 204 content "OK"

    log local0. "closing sideband"
    close $conn
}

    This rule initiates a sideband call to an internal virtual server, immediately closes it, and then sends a 204 to the client. This "external" virtual server has no pool. The internal virtual server is responsible for forwarding the traffic to a pool.

    For testing, the internal virtual server has the following iRule:

    when HTTP_REQUEST {
    log local0. [HTTP::request]
}
when HTTP_RESPONSE {
    log local0. "here"
}

    And here's what I get in the logs:

    external-rule : sending sideband call
external-rule : sending 204
external-rule : closing sideband
internal-rule : GET / HTTP/1.1  User-Agent: curl/7.16.4 (i586-pc-mingw32msvc) libcurl/7.16.4 OpenSSL/0.9.8d zlib/1.2.2  Host: 10.70.0.196  Accept: */*
internal-rule : here

    So it would appear that the 204 response is sent before a response is generated. Admittedly, setting up a sideband connection per request may not perform as well as simply sending to a pool, but it'd need to be tested to be sure.