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

Question

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.&nbsp;
Client request -
https://www.site.com/123&nbsp;
F5 Rewrite -
Request -
https://www.site.com/123 to https://www.site.com/321
Insert Header
SetContextURI: http://www.site.com/123&nbsp;
F5 Rewrite -
Response -
https://www.site.com/321/blah/data (Preserve Data) to https://www.site.com/123/Blah/data&nbsp;
I have looked at several options, but none bring both the Request, Response, and header insert together or will do a client redirect.&nbsp;

brad_parker · Answer

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 · Answer

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:// ?&nbsp;
when HTTP_RESPONSE {
     Replace http:// with https://
    STREAM::expression {@/321/@/123/@}&nbsp;

jba3126 · Answer

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.&nbsp;
Client Browser Request comes in https://www.site1.com/123 (SSO site).Backend SSO application server authenticates and makes a call to 123 (IAC) application VIP using https://www.site2.com/123The 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.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 · Answer

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.  &nbsp;
So in the packet capture I see /123 come in and being re-written to /321, but I don't see the reciprocal. &nbsp;
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
}&nbsp;
Samples from the packet capture
External - Original Request
GET /123/ HTTP/1.1
&nbsp;
Internal - What was sent to the server
GET /321/PRServlet/ HTTP/1.1
&nbsp;
Internal - Response from the server
*/!STANDARD?&nbsp;
External - Response sent to the requesting device
*/!STANDARD?&nbsp;
External - Next request from the requesting device
GET /321/PRServlet/-j04puREN5KesgWh7fQGTaX18YQyXIPY*/!STANDARD? HTTP/1.1
&nbsp;
Internal - What was sent to the server
GET /321/PRServlet/-j04puREN5KesgWh7fQGTaX18YQyXIPY*/!STANDARD? HTTP/1.1
&nbsp;

jba3126 · Answer

I have the default stream profile added.&nbsp;
ltm profile stream stream {
    app-service none
    source none
    target none
}&nbsp;

Forum Discussion

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

Recent Discussions

Which process is consuming higher CPU

F5 Health Monitor Receive String as JSON

Background Tasks

SSL bridging without SSL proxy forward

Big-IP VE edition for MacBook M4 Chip

Related Content

HTTP POST redirect preserving POST data

Introduction of Incident Response

custom response page for api

Anchor Link Redirect

FIX Message Response

ABOUT DEVCENTRAL

RESOURCES

SUPPORT

PARTNERS