Fetching content from external source

anyone know if you can use standard tcl geturl?

 

 

eg

 

 

http::geturl $url

I don't think so... I get an undefined procedure on that one when checking syntax. The url can be constructed, however, with HTTP::host and HTTP::uri.

The iRules are event driven, so when a request/response arrives, do this... HTTP::host and HTTP::uri will give you the information from within a request, but I'm not sure what you are looking to do is possible within the context of iRules.

 

 

Could you give a little more detail into what you are trying to accomplish?

You could build a class up front for each country and put as grand a summarization of those spaces as possible, or you could sub-optimally route the first request from each range, log any new range request, which could kick off an event to an iControl app that can build the class for you for future requests from that range.

the tables for a country would be huge!!

 

 

is there anyway to forward a request to a specific url, get a http 200 or 404 from that url, for 200's let the request continue to the original destination and reject anything else?

 

 

 

thanks for your help btw

Yes. In fact, if you sent the initial request to server X, you could have it check the country and forward it back in the response, then you could resend the request to the appropriate pool.

 

 

Framework:

 

 

when client is accepted, set a variable to 1 to establish as new connection

 

when first http_request event triggers, forward to server X to process country of origin

 

when first http_response event triggers, pull out country information from response and set the variable to 0.

 

when subsequent http_request events trigger, match country to appropriate pool

 

 

Write back if you get stuck with the context, or if my assumption that your server X will process the country is way off base.

Hi

 

 

server x can indeed process the country lookup.

 

 

that will then force the user to be sent a re-direct and then follow that to generate a second call back to the original URL which would then be able to lookup which country they are in.

 

is there anyway to do it in a single fetch? ie get the response back from server x and then re-submit the request back to the correct pool?

 

 

is there any way to add custom TCL commands? ie I could put an app on the F5 itself that does the geo lookup if I can call it from the TCL? Or opening a tcp socket connection to server x, etc?

 

 

I can think of so many ways that it would be good to be able to use GeoIP based lookups in IANA rules, wonder if it would ever become a feature!

 

 

Thanks for your help, appreciate it, think I'm nearly there...

 

 

 

Hi Adrian --

The "HTTP::retry" command offers a useful trigger for scenarios like this, where there is a requirement for an out-of-band socket connection to a 3rd host. Something like this might be a good start to what you're after:

when HTTP_REQUEST {
   save original request
  set req [HTTP::request]
   flag as new request needing lookup
  set lookup 1
   inject lookup URI in place of original request
  HTTP::uri "/page.aspx?ip=[IP::client_addr]"
   set pool to lookup server pool
  pool lookup_server
}
when HTTP_RESPONSE {
  if {$lookup == 1 }{
     collect first response (from lookup server) only
    HTTP::collect
  }
}
when HTTP_RESPONSE_DATA {
   Get poolname from server response
   Response would ideally be in the form of a pool name only.
   Otherwise parse or derive the poolname here
  set myPool [HTTP::payload]
   verify pool exists and has members
  if { ![catch [pool $myPool]] }{
    HTTP::retry $req
  } else {
    
     insert dead/non-existent pool logic here
    
  }
   re-set flag so that subsequent response to re-tried 
   request from real server is not processed as a lookup
  set lookup 0
}

HTH

/deb

I would like to get this example to work, but all my requests go

 

to a virtual server with a full 0.0.0.0 destination.

 

 

vs_main_http Common 0.0.0.0 80 (HTTP) Standard

 

 

As such I don't really use a pool for the HTTP requests, so the

 

"set myPool [HTTP::payload]" does not seem to make sense in my

 

use case as I don't think I have a pool.

 

 

I think I would have to somehow undo and remove the "pool lookup_server"

 

statement in my use case to get back to the default routing behavior.

 

 

/jon

Hi Jon,

 

 

Can you explain what are you trying to do by making an out of band request to a pool? Are you determining if the client request is valid? Or something else?

 

 

Thanks,

 

Aaron