Friendly URI Re-Write based off of User-Agent?

Hi,

 

 

What do you mean by "redirected to url2.domain.com at the website level"? Do you mean they make an HTTP request to url1.domain.com and get a 302 redirect to https://url2.domain.com? Do you want to change this so that some user-agents don't see the redirect to https://url2.domain.com but are instead proxied through to the url2 pool?

 

 

Aaron

if the cn on the cert if for "url2" then if their browser sauys "url1" and they are using an SSL connection with that cert, then they will always see an error. I don't really understand what you're asking to happen, but as you've mentioned the cert names etc, I think it must be the case that you somehow want the ssl connection to be "happy" despite it being for the wrong domain... You do sound like you are using internal redirection, as opposed to a 302, but then I'd not call that a "friendly" rewrite as the user would be oblivious to it.

 

 

It's certainly possible to use the UA value from [HTTP::header "User-Agent"] with a switch block (or equivalent) to match to your UA requirements, but none of this deals with the SSL side of things, which seems to be where the real issue is.

Sorry if I am not being clear. I was told this could be done, at the F5 level, but now I am not so sure.

 

 

This application will always trust our domain, so I don't think that cert errors will be an issue. It is not a normal browser, but the agent sometimes shows up as mozilla, or TestAgent.

 

 

Right now:

 

 

User comes in on url1.domain.com (cname), and is redirected behind the f5 to url2.domain.com (A record, SSL Cert for this siite). This application can see this.

 

 

What I want to be able to do:

 

 

User comes in on url1.domain.com (cname), and is redirected behind the f5 to url2.domain.com (A record, SSL Cert for this siite). The application to not see the redirect and still think it is url1.domain.com. Only do this for User-Agents Moziilla, and TestAgent.

 

 

The F5 does not need to do any redirecting outside of what it normally does.

OK, well SSL aside for now, can you be more specific about your use of the word "redirect"? A redirect would generally be taken to be sending an HTTP 302 redirect response back to the client and have them come back again asking for a different resource. A rewrite, however, would generally be the manipulation of the existing request to do something other than what was originally requested.

 

 

It sounds like you're talking about rewriting, not redirecting, is that correct? if so, I'm not sure what you want to redirect. If you don't want the end server to notice then it should just be a case of NOT doing anything. as the LTM works initially at a TCP level, not an HTTP level, you would have to go out of your way to change the HTTP Host headers etc. If you just load balance this request to the right servers, without using any irules or such like, then they will get the original request, there is no manipulation of the HTTP details unless you explicitly tell it to do so.

 

 

I'm faaaairly sure I'm missing something here, but you don't seem to be asking the LTM to actually do anything in the first place.

 

 

Do you just want to be using the User-Agent header to pick a certain pool and nothing else? If so, this appears to be very similar... you're not sitting next to this guy are you?

 

 

http://devcentral.f5.com/Community/GroupDetails/tabid/1082223/asg/50/aft/2159207/showtab/groupforums/Default.aspx

Use of word redirect: We have an application we wrote on the backend that will look for a client coming in one URL, and redirect them to another. In the browser this is a 302. This helps us put the client on different versions of the application wiithout having to tell them a new URL each time.

 

 

Yes, I want a URL-Rewrite. I do not want to redirect anything at the bigip level. Just want the client to not see the redirect if they are coming in on a certain User-Agent.

So, currently you are sending back a 302 and want to make this not occur my pre-empting the destination that they will be redirected to and instead rewrite the incoming request? So when you say "The application to not see the redirect" you mean "The application to not need to provide the redirect", right? So what does this not satisfy?...

when HTTP_REQUEST {
      if { (string tolower [HTTP::header "User-Agent"] contains "mozilla") || (string tolower [HTTP::header "User-Agent"] contains "testagent") } {
             pool aaa
             HTTP::header replace "Host" "url2.domain.com"
      } else { 
             pool zzz
      }
} 

Thanks for the help Chris, I am probably not good at explaining this. Correct, I do not want the client to see the redirect (but it is still going to happen on the backend).

 

 

Can you help me understand this piece?

 

 

pool aaa

 

HTTP::header replace "Host" "url2.domain.com"

 

} else {

 

pool zzz

I don't see why the redirect (i.e. an actual 302) is going to still happen. In theory the LTM could intercept a 302 and act upon it itself, but if you can anticipate that situation, you'd just do a rewrite in the first place.

 

 

so the iRule just says if the user agent contains "mozilla" or "testagent" then send the request to the pool aaa, and change the HTTP Host header to suit what the end server is expecting. otherwise send it to pool zzz. I put the Host header change in as an example, maybe you actually want to change the uri as well or something. If pool zzz is the default pool on the vip then there's no need for the else {} block at all.

I think we still have a disconnect. We need the application to see this initial URL only. We still need the redirect to happen on the backend (this is not done on the bigip), but we just need the browser to only see the URL that it comes in on (url1.domain.com), and not the redirect to url2.domain.com. We need this to be dynamic so it works across all pools. In other words, if this agent comes in on this url, then make sure the url is displayed as that url for the entire session and don't show the redirect.