Masking/Hiding original URL?

Right now, to get to the virtual server you have to go to the following: https://users.test.com:50100/irj/portal. What I would like to see is https://users.test.com within the URL.First change the port on the virtual server from port 50100 to 443. That way clients can browse to https://host/uri. Virtual servers by default translate the port to the real ports of the pool members.

Next create and associate a stream profile (Local Traffic/Profiles/Other/Stream) to strip the port/path in any links or references imbedded in the server response, thus presenting to the broswer links of the form https://host/uri where hostname no longer includes the port, and URI no longer contains the portal-specific preamble:

- Source: :50100/irj/portal

- Target:

The stream profile will only replace URLs in the payload, not the headers, so we also need to catch any server-originated redirects and rewrite them. If you didn't need to mask the URI, you could re-write all redirect headers to the correct hostname/port simply by setting "Redirect Rewrite" to "Matching" in the associated http profile. This simple iRule snip will handle both for you instead:

when HTTP_RESPONSE {
  if { [HTTP::status] starts_with "3" } {
    HTTP::header replace Location [string map {":50100/irj/portal" "" } [HTTP::header Location]]
  }
}

And last, you also will need to translate inbound requests to prepend the real portal path to the URI, which is also handled by an iRule:

when HTTP_REQUEST {
  HTTP::uri "/irj/portal[HTTP::uri]"
}

Put the 2 snips together in 1 iRule and apply to the port 443 virtual server, and you should be set.

/deb

deb,

 

 

I Changed the port to 443, configued the stream profile and applied it to the virtual server, and configured the 2 iRules specified above, and applied those to the virtual server.

 

 

Now when I try to get to the web page, I get a "page can not be displayed" error.

 

 

Thoughts?

 

 

-GW

 

Let's add some logging to the iRule to see what's going on:

when HTTP_REQUEST {
  set origURI [HTTP::uri]
  set newURI "/irj/portal[HTTP::uri]"
  HTTP::uri $newURI
  log local0. "Original URI: $origURI"
  log local0. "Rewritten URI: $newURI"
}
when HTTP_RESPONSE {
  if { [HTTP::status] starts_with "3" } {
    set origRedir [HTTP::header Location]
    set newRedir [string map {":50100/irj/portal" "" } [HTTP::header Location]]
    HTTP::header replace Location $newRedir
    log local0. "Original redirect: $origRedir."
    log local0. "Rewritten redirect $newRedir"
  }
}

Log will write to /var/log/ltm, or Local Traffic log in the GUI. Examine output for clues.

If it doesn't reveal itself, I'd recommend making one change at a time & verifying each is having the desired effect per the descriptions in my previous post, then posting back with any specific challenges you encounter, and we'll take it from there.

HTH

/deb

Meant also to say, since you're not seeing even the first page, I suspect the URI re-writing in the HTTP_REQUEST event is not happening as expected, and I'd start looking more closely at that first.

 

um, yeah...

 

 

I almost forgot a critical bit: You'll also need to change the "Response Chunking" option in your http profile to "Re-chunk", otherwise the mismatch in content length after the stream profile does its thing will cause some browsers to hang.

 

 

/deb

Here is the output from the log file...

 

 

Apr 25 18:13:36 tmm tmm[1507]: Rule SAP_443 : Original URI: /

 

Apr 25 18:13:36 tmm tmm[1507]: Rule SAP_443 : Rewritten URI: /irj/portal/

 

Apr 25 18:13:36 tmm tmm[1507]: 011f0007:3: http_process_state_prepend - Invalid action EV_EGRESS_DATA during ST_HTTP_PREPEND_HEADERS

 

Click here for a post containing a discussion of that error.

 

 

Given that, I would start by testing without the iRule and with the http profile applied to see if it has something to do with LTM's interpretation of the state of HTTP events for that connection. If the problem persists with the profile but not without, contact Support to open a case to review, then once that's resolved, put the iRule back & test again.

 

 

If http profile doesn't seem to be the culprit, post back and maybe somebody smarter than I will be able to help...

 

 

If you end up finding the resolution elsewhere, it would be great if you could post back & clue us in for future reference.

 

 

Good luck!

 

/deb

Thanks deb.

 

 

I did some packet captures, and I am seeing 404 errors coming from the server, and after reviewing the post above that you link'ed, I do believe this might be a profile issue.

 

 

I have attached the capture for you or anyone else to see. Make sure you open it in notepad.

 

 

-GW

Well, the 400 Bad Request error is because the request received by the server was for ":50100/irj/portal/" -- the ":50100" part shouldn't be there.

 

 

I can't see how the iRule above could have generated such a request. The intended translation seems to have been verified by your earlier testing: We can see in the log that, as expected, a URI of "/irj/portal/" was derived by the iRule when the client requested "/".

 

 

Some clarification about your testing might help shed some light on the situation:

 

 

- Was this request submitted against a port 443 virtual?

 

- Was the iRule applied?

 

- Was the http profile applied?

 

- Is the original error still appearing in the LTM log?

 

 

If the iRule was in place, comparing client-side and sever-side traces would help us see whether that transformation was performed by the load balancer, or it was munged elsewhere by examining both the request as submitted by the client and as received by the server. It would also be good to see the LTM log corresponding to the traces to see if any unexpected values are logged.

 

 

I would still recommend going back to where you started & making one change at a time, testing at each step as detailed above. (Only exection being that you must be sure to add re-chunking when adding the stream profile.)

 

 

/deb

 

More information about what you saw in your incremental testing would be helpful. Does it work without the iRule, or are the errors still seen? If errors are still seen without the iRule applied, how about without the HTTP profile or the iRule?

 

 

If it works without error with the HTTP profile applied, then we need to look at what the iRule is doing -- how the request was submitted and translated. Traces on both interfaces and examination of the log should be helpful in that regard.

 

 

/d