Strange behavior only via Internet Explore

Peter Schober peter.schober at
Tue Apr 23 06:26:25 EDT 2019

* Noriyuki TAKEI <ntakei at> [2019-04-23 04:37]:
> I guess the above-mentioned error proceeds in the following sequence from
> idp-warn.log, HTTP Header and  apache access logs.
> (1) At first, the browser access to an SP.
> (2) The SP redirects the browser to
> [IDP's FQDN]/idp/profile/SAML2/Redirect/SSO via Get method with SAML
> Request attached to query parameter.(However, it seems that the browser
> gets this response from cache according to IE's log )
> (3) The SP redirects the browser again to
> [IDP's FQDN]/idp/profile/SAML2/Redirect/SSO via Post method with SAML
> Request attached to query parameter.
> (4) the above-mentioned error occurs.

I find 2 and 3 to be very unlikely: The SP would have to know that
something bad happened to the first authn request (in 2) in order for
it to issue another (in 3): All the SP knows about an auth request
(with HTTP-Redirect protocol binding, as used in step 2) is that it's
sending an HTTP "Location" response header to the HTTP User Agent. So
how would the SP (or the SP's web server) determine that it needs to
send /another/ authentication request -- only this time (3) the SP
would use an incorrect protocol binding, sending the request with the
HTTP-POST protocol binding to an endpoint only meant for HTTP-Redirect

You don't mention the SP implementation but the Shibboleth SP would
not send a request using the HTTP-POST protocol binding to an
endpoints that's advertised for use with the HTTP-Redirect binding.

While for other SP implementations all bets are off it's still
unlikely the SP has anything to do with this for the reason given


More information about the users mailing list