Forum Discussion

Max_Heffler2_30's avatar
Max_Heffler2_30
Icon for Nimbostratus rankNimbostratus
Apr 02, 2018

Request modification and forwarding to pool without client side redirect

We have “portal.xyz.com” & “api.xyz.com”; for all HTTP POST requests with a specific URI i.e. “portal.xyz.com/portal/server.pt?” we want to modify only the HOST & URI to “api.xyz.com/v1/?” and put it in an existing F5 POOL i.e. pool HTTP-api.xyz.com. Additionally we want to do https upgrade as well for all requests.

Nonworking Solution: Use iRule: check for HTTP POST requests with URI then for that request rewrite complete URL and forward that request to be served by another pool.

when HTTP_REQUEST{

HTTP::redirect https://[getfield [HTTP::host]:1]:443[HTTP::uri] 

}

when HTTP_REQUEST{

log local0. "TEST HR: clientIP:[IP::client_addr][TCP::client_port]:[HTTP::method] request to host:[HTTP::host], uri:[HTTP::uri]"

if{ [HTTP::method] eq "POST" && [HTTP::uri] eq "/portal/server.pt?"} {
    log local0. " TEST HR: in POST"
    HTTP::header replace "Host" "api.xyz.com"
    HTTP::uri “/v1/?"    
    pool HTTP-api.xyz.com
}

}

Result: We tested this solution and it didn’t work. No logs show up for POST request but https upgrade works fine.

Someone please help us correct this and let us know if this is the correct way to accomplish this. Thanks in advance!

  • Have you used the browser developer tools to determine what is happening with your request?

     

    You are probably hitting a redirect issue - your POST request is being changed to a GET by the browser:

     

    HTTP 302

     

    Many web browsers implemented this code in a manner that violated this standard, changing the request type of the new request to GET, regardless of the type employed in the original request (e.g. POST). For this reason, HTTP/1.1 (RFC 2616) added the new status codes 303 and 307 to disambiguate between the two behaviours, with 303 mandating the change of request type to GET, and 307 preserving the request type as originally sent. Despite the greater clarity provided by this disambiguation, the 302 code is still employed in web frameworks to preserve compatibility with browsers that do not implement the HTTP/1.1 specification.