Best method to rewrite Request and Response URI, preserve URI data, and with no client redirect

[jba3126]

Looking for the best method (iRule, HTTP Class, etc) to rewrite URI while preserving the trailing data in the URI and ensuring that no client redirect occurs. I also need to insert a header in the mix of all this.

Client request - https://www.site.com/123

F5 Rewrite - Request - https://www.site.com/123 to https://www.site.com/321 Insert Header SetContextURI: http://www.site.com/123

F5 Rewrite - Response - https://www.site.com/321/blah/data (Preserve Data) to https://www.site.com/123/Blah/data

I have looked at several options, but none bring both the Request, Response, and header insert together or will do a client redirect.

[Brad_Parker]

Try adding the default stream profile and using and iRule like this:

when HTTP_REQUEST { HTTP::header insert "SetContextURI" "http://[HTTP::host][HTTP::path]" HTTP::path [string map {/123 /321/PRServlet} [HTTP::path]] Disable the stream filter for all requests STREAM::disable LTM does not uncompress response content, so if the server has compression enabled and it cannot be disabled on the server, we can prevent the server from sending a compressed response by removing the compression offerings from the client HTTP::header remove "Accept-Encoding" } when HTTP_RESPONSE { STREAM::expression {@/321/PRServlet@/123@} Enable the stream filter for this response only STREAM::enable re-write Location header HTTP::header replace Location [string map {/321/PRServlet /123} [HTTP::header Location]] }

[jba3126]

Brad, Thank you for the response. I believe this is going to work. I'm curious was a piece missing for the http:// to https:// ?

when HTTP_RESPONSE { Replace http:// with https:// STREAM::expression {@/321/@/123/@}

[jba3126]

Brad, I apologize for the delay. We were not able to test this as the systems were Production. We bought a set of Dev-QA F5 VEs, deployed them, and are testing this solution. Unfortunately things aren't working as we'd hoped. In doing packet captures the request is getting re-written but sending a 303 back to the requesting application server which causes an error. Let me see if I can update what I see as the task our Dev/Middleware team is trying to accomplish.

1. Client Browser Request comes in https://www.site1.com/123 (SSO site).
2. Backend SSO application server authenticates and makes a call to 123 (IAC) application VIP using https://www.site2.com/123
3. The URI of /123 needs to be re-written prior to going to the IAC application server to /321 with no 303 or redirect message sent to the requesting application server. Doing so causing a failure.
4. Once the IAC app processes the request /321 it will respond with /321/blah/data and will need to be re-written to /123/blah/data prior going to the requesting application server (SSO) and then back to the client. We had an F5 training class with the guy that wrote the training modules for iRules, but unfortunately we did not get to take a look at this prior to his early flight departure 😐 Hopefully you or someone on here can provide some guidance. Is this something that is going to require an OnDemand iRule? One final note is we are running v11.6 and tried a rewrite profile; however it also sends 303.

[jba3126]

Hey Brad, Thank you for the response! So I applied the irule to site2. The 303 is coming from the server and is not being re-written on the outbound portion of the irule. Also the user indicated he had to add hit /123/ vs just /123, so modified the rule slightly.

So in the packet capture I see /123 come in and being re-written to /321, but I don't see the reciprocal.

Current iRule: when HTTP_REQUEST { HTTP::header insert "SetContextURI" "http://[HTTP::host][HTTP::path]" HTTP::path [string map {/123 /321/PRServlet} [HTTP::path]] Disable the stream filter for all requests STREAM::disable LTM does not uncompress response content, so if the server has compression enabled and it cannot be disabled on the server, we can prevent the server from sending a compressed response by removing the compression offerings from the client HTTP::header remove "Accept-Encoding" } when HTTP_RESPONSE { STREAM::expression {@/321/PRServlet@/123@} Enable the stream filter for this response only STREAM::enable }

Samples from the packet capture External - Original Request GET /123/ HTTP/1.1\r\n

Internal - What was sent to the server GET /321/PRServlet/ HTTP/1.1\r\n

Internal - Response from the server */!STANDARD?

External - Response sent to the requesting device */!STANDARD?

External - Next request from the requesting device GET /321/PRServlet/-j04puREN5KesgWh7fQGTaX18YQyXIPY*/!STANDARD? HTTP/1.1\r\n

Internal - What was sent to the server GET /321/PRServlet/-j04puREN5KesgWh7fQGTaX18YQyXIPY*/!STANDARD? HTTP/1.1\r\n

[jba3126]

I have the default stream profile added.

ltm profile stream stream { app-service none source none target none }

[jba3126]

ltm virtual VS_Site2-8050 { destination 10.1.1.3:8050 ip-protocol tcp mask 255.255.255.255 partition Surround pool Pool-Site2-IAC-SSO-App-8050 profiles { /Common/http { } /Common/stream { } tcp-lan-optimized { } } rules { Site2-IAC-URI-Rewrite-IRULE Site2-WebSphere-JSESSIONID-Persist-iRule } source 0.0.0.0/0 source-address-translation { pool Site2-IAC-SSO-SnatPool type snat } vs-index 10 }