Forum Discussion
AltostratusHealth Check is returning HTTP code 302
Hi,
I'm testing a security change that was made in out .NET application, in order for the SessionId to be encrypted. In practice our application has 2 cookies ASP.NET_SessionId and .AUTHTOKEN.
What happens is that I'm getting a HTTP status code 302 instead of 200 and I don't know the reason why.
Before this change, the response on the health check is HTTP 200.
Talking with our IT team, we can see this information in the log
Is there any configuration missing in F5?
Thank you for your help
(edited)
[0][6360] 2025-03-10 16:02:11.534546: ID 93 :(_send_active_service_ping): pinging [ tmm?=false td=true tr=false addr=::ffff:127.0.0.1:443 srcaddr=::ffff:127.0.0.2%0:45404 ]
[0][6360] 2025-03-10 16:02:11.534566: ID 93 :(_send_active_service_ping): writing [ tmm?=false td=true tr=false addr=::ffff:127.0.0.1:443 srcaddr=::ffff:127.0.0.2%0:45404 ] send=GET /acp_sec/Pages/Diag.aspx?fun=availability HTTP/1.1\x0d\x0aHost: 127.0.0.1
...
[0][6360] 2025-03-10 16:02:11.544950: ID 93 :(_recv_active_service_ping): rcvd 917 bytes: -->HTTP/1.1 302 Found\x0d\x0aContent-Type: text/html; charset=utf-8\x0d\x0aLocation: /acp_sec/Pages/Diag.aspx?fun=availability\x0d\x0aX-XSS-Protection: 1; mode=block\x0d\x0aReferrer-Policy: strict-origin-when-cross-origin\x0d\x0aX-Content-Type-Options: nosniff\x0d\x0aX-FRAME-OPTIONS: SAMEORIGIN\x0d\x0aContent-Security-Policy: frame-ancestors 'self';\x0d\x0aStrict-Transport-Security: max-age=31536000\x0d\x0aSet-Cookie: ASP.NET_SessionId=yzxes2pnx; path=/; HttpOnly; SameSite=Strict\x0d\x0aSet-Cookie: .AUTHTOKEN=T/X1a+3DdstNk4A70880jJ69QqyLraOsY0IfBeYdCnvH7nB0MLs92+/AQqABdWbLpTf9eV/p7lbcMLmHUho0ZZEh4ylaXed/rJ1DaAxLe9RkFiKZCnmZ3gKA4k; path=/; HttpOnly; SameSite=Strict\x0d\x0aPersistent-Auth: true\x0d\x0aDate: Mon, 10 Mar 2025 16:02:01 GMT\x0d\x0aContent-Length: 158\x0d\x0a\x0d\x0a<html><head><title>Object moved</title></head><body>\x0d\x0a<h2>Object moved to <a href="/acp_sec/Pages/Diag.aspx?fun=availability">here</a>.</h2>\x0d\x0a</body></html>\x0d\x0aHTTP/1.1 302 Found\x0d\x0aContent-Type: text/html; charset=utf-8\x0d\x0aLocation: /acp_sec/Pages/Diag.aspx?fun=availability\x0d\x0aX-XSS-Protection: 1; mode=block\x0d\x0aReferrer-Policy: strict-origin-when-cross-origin\x0d\x0aX-Content-Type-Options: nosniff\x0d\x0aX-FRAME-OPTIONS: SAMEORIGIN\x0d\x0aContent-Security-Policy: frame-ancestors 'self';\x0d\x0aStrict-Transport-Security: max-age=31536000\x0d\x0aSet-Cookie: ASP.NET_SessionId=hokvzg33zqc2dmhr1uaqu31a; path=/; HttpOnly; SameSite=Strict\x0d\x0aSet-Cookie: .AUTHTOKEN=8xKxChGEQJ0vjt30f8K7soek3Iiemo5ZwkU9tG5YDU4xx6JrqhM/QCYShHpOXg8Ex/mL1sT+VO3Ug3T1gP94fDhsl3RwMZPYD7l3S; path=/; HttpOnly; SameSite=Strict\x0d\x0aPersistent-Auth: true\x0d\x0aDate: Mon, 10 Mar 2025 16:02:06 GMT\x0d\x0aContent-Length: 158\x0d\x0a\x0d\x0a<html><head><title>Object moved</title></head><body>\x0d\x0a<h2>Object moved to <a href="/acp_sec/Pages/Diag.aspx?fun=availability">here</a>.</h2>\x0d\x0a</body></html>\x0d\x0aHTTP/1.1 302 Found\x0d\x0aContent-Type: text/html; charset=utf-8\x0d\x0aLocation: /acp_sec/Pages/Diag.aspx?fun=availability\x0d\x0aX-XSS-Protection: 1; mode=block\x0d\x0aReferrer-Policy: strict-origin-when-cross-origin\x0d\x0aX-Content-Type-Options: nosniff\x0d\x0aX-FRAME-OPTIONS: SAMEORIGIN\x0d\x0aContent-Security-Policy: frame-ancestors 'self';\x0d\x0aStrict-Transport-Security: max-age=31536000\x0d\x0aSet-Cookie: ASP.NET_SessionId=piuo13cso4vt0z; path=/; HttpOnly; SameSite=Strict\x0d\x0aSet-Cookie: .AUTHTOKEN=dRf46GVVB2+hFIYUejBofDSWwvOaxVIH4VJcLPOD7NQcrl8rgoM4C7SWt/g98mL/cLffPpvmejfA5sRXT7XoQlwCNK3vVsPLxCQNhRcR5Hv5NK1NPk9iNEsa6m7eX; path=/; HttpOnly; SameSite=Strict\x0d\x0aPersistent-Auth: true\x0d\x0aDate: Mon, 10 Mar 2025 16:02:11 GMT\x0d\x0aContent-Length: 158\x0d\x0a\x0d\x0a<html><head><title>Object moved</title></head><body>\x0d\x0a<h2>Object moved to <a href="/acp_sec/Pages/Diag.aspx?fun=availability">here</a>.</h2>\x0d\x0a</body></html>\x0d\x0a<-- [ tmm?=false td=true tr=false addr=::ffff:127.0.0.1:443 srcaddr=::ffff:127.0.0.2%0:45404 ]
So, internally, together with the DEV and IT teams, we decided to exclude the page used in the health check from the authentication (code change).
This way it will stop to be necessary to have the cookies SessionId and AuthToken, thus the GET will return HTTP status code 200.
Thank you for all your help.
9 Replies
lcravoptSo, internally, together with the DEV and IT teams, we decided to exclude the page used in the health check from the authentication (code change).
This way it will stop to be necessary to have the cookies SessionId and AuthToken, thus the GET will return HTTP status code 200.
Thank you for all your help.
- Injeyan_Kostas
Cirrostratus
Can I ask you why you didn't just accepted 302 as valid response to consider that health check successful?
It's not mandatory to have 200 response.
In same cases even a 401 would be consider as valid response.
- lcravopt
The reason had to do with the fact that a 200 response is the more "normal" status code and everybody were more confortable with having that response code.
- lcravopt
If I do the request like:
C:\>curl --ntlm -u: https://myserver/ACP_SEC/Pages/Diag.aspx?fun=availability <html><head><title>Object moved</title></head><body> <h2>Object moved to <a href="/ACP_SEC/Pages/Diag.aspx?fun=availability">here</a>.</h2> </body></html>If I do the request like (passing cookies ASP.NET_SessionId and .AUTHTOKEN) I get:
C:\>curl --ntlm -u: -v --cookie "ASP.NET_SessionId=oq31muonjispmsqga; .AUTHTOKEN=JfHveRBZ083UOL2dmoR4mDBjsPlgKHKqO0o0xjuZHIXpzceVRd+fmhgGf4R8l28Vm6UNrzn7uxE5zBDxAt4r1ceuN5F4UlcC+lgp" https://myserver/ACP_SEC/Pages/Diag.aspx?fun=availability * Request completely sent off < HTTP/1.1 200 OK < Cache-Control: private < Content-Length: 309 < Content-Type: application/xml < Expires: Mon, 01 Jan 0001 00:00:00 GMT < Content-Disposition: inline; filename=DiagInfo.xml < Persistent-Auth: true < Date: Thu, 03 Apr 2025 22:32:14 GMT < <?xml version="1.0"?><test url="https://myserver/ACP_SEC/Pages/Diag.aspx?fun=availability" name="Availability" time="04/03/2025 23:32:14" duration="0"><result description="Call to Frontend was successful." expected="Ok" status="Ok" type="Ok" /><description>Frontend</description></test>* Connection #0 to host myserver left intactIs possible in the Health Monitor Send string to add a cookie parameter?
- Injeyan_Kostas
It is but whatever cookie you put there will be expired at some time.
I suggest to keep using the same string but accept 302 as valid response in health monitor.
- LiefZimmerman
Admin
Editing an original post is limited to a short time period (so as not to invalidate answers by changing the question)
I've temp removed it for you and replied in PM to see how you want to proceed.
- lcravopt
Hi Injeyan_Kostas
Thank you for your reply.
If I try to open the url directly I get the 200 response
Regarding, your remark, is there a way for me to edit my original message?
- Injeyan_Kostas
Can you try the same request with a curl?
- Injeyan_Kostas
Are you sure this isn't expected behavior?
Have you tried manually requesting this URL from your browser? What response do you get?From what I understand, the application needs to redirect you for some reason, so there’s no issue on the F5 side.
If this is expected, you could simply adjust your monitor to expect a 302 response.
Also, be aware that your monitor credentials are exposed in the logs you shared.
