iRule help for

Hi,

The problem is when you oper your redirect you lost your post data that's the reason why.

Could you explain why you redirect your Post request, (your irule seems correct)

Regards

So to clarify, you need to change the client-side POST to a GET on the server-side, and inject some static credentials?

Will the POST have payload? And if so, do you want to mirror that payload to the server?

Will all requests be coming in as POSTs?

An HTTP::redirect command sends a 302 HTTP redirect back to the client, so probably not what you want. Can you elaborate on the desired traffic flow?

Hi Kevin,

Below are the answers to address your query

Will the POST have payload? And if so, do you want to mirror that payload to the server?

Here there is no pool, it redirects to another VIP on a second external F5, So on the 1st External F5e we use HTTP::redirect "https://www.abc.com[HTTP::uri]" Also we need to add static creds and the POST shall go as a POST (right mow server Sees it becomes a GET, which should not be the case)

.

Ah, I see. You're saying that the redirect changes the POST to a GET.

This is an expected behavior when you send a 301 or 302 redirect to a browser. Not all clients support this, but the better option may be to send a 307 instead.

See this: https://httpstatuses.com/307

You'd do this with an HTTP::respond instead:

HTTP::respond 307 Location "http://foo"

Thanks Kevin,

I will try with the below and check with the customer.

when HTTP_REQUEST { set logindata [b64encode "username:password"]

Hi Kevin,

only missing is username/password in authorization headers -> the server do not see any authorization header

Response Error Message =Authentication challenge issued

Aditya,

As Youssef is alluding, you're most likely going to have to proxify the request to the other VIPs, that is, pass the traffic through the first VIP to the second. A 307 redirect will cause the client to maintain the original POST method, but there's NO WAY to also pass an authorization header through the client into the next request. So you have maybe two options here:

• Pool the traffic through VIP1 to VIP2 on the other F5, in which case you don't have to send a redirect and don't have to worry about the POST method changing. And you can insert the static authorization header here.

   

• Have VIP2 insert the static credentials. Assuming the authentication isn't actually being consumed by VIP2, but rather the application servers behind it, it would be conceivable to simply have VIP2 insert the authorization header on the way to the application.

   

Thanks Kevin,

Yes. You'd simply need to decrypt, insert your authorization header, and send it on its way. The contents of the HTTP request (method, headers and payload) will remain intact.

ok, but there is problem