Recently we observed that our root protected SM URL is not coming up with the encrypted web-agent name and type, realmoid, guid, etc.
The URL to access is like this https://sm.abc.com/, where root / is protected.
If you hit the URL it should take you to the protected page and the URL should look like
But now if you hit the protected URL, it will show this above URL in the address bar, and will ultimately redirect to,
with no encrypted web-agent name, type, realmoid, etc.
Now, /page is in the ignore URL and it was there before as well, but upon hitting https://sm.abc.com/ , the complete SM URL only used to come.
The only change which we did was, we made the PostPreserveData "no".
But if we enable the PostPreserveData as "yes" also now, then also the complete SM URL gets redirected to https://sm.abc.com/page
When PostPreserveData is "no" , you can see 'METHOD=POST' in the SM URL query parameter,
When PostPreserveData is "yes", you can see 'METHOD=GET' in the SM URL query parameter.
Any suggestion, what could cause this behaviour ?
Does this behaviour has any relation with Cache-Control ?
I think it is dependent on how the WebServer OR Application Code handles the URI " /page ". So check the Web Server logs on why " /page " is doing a redirect and loosing all query parameters. I am pretty sure SM WebAgent does not have a role to play in what " /page " does. For the SM WebAgent is it a URI and it would treat it as such.
Can you change your authscheme URL to OOB Login.fcc, with OOB ACO and test. You would not see the anomaly.