OpenSAMLv3 HTTPPostEncoder sending OPTIONS request instead of POST

[Brent Putman]

On 3/15/19 8:21 PM, Mark Watson wrote:
>
>
> I've built a LogoutRequest and wrapped it in a MessageContext, but
> when I call the encode method the subsequent SAML request is sent
> using an OPTIONS request. My understanding of OPTIONS is that it's
> used for CORS to determine if the destination server will accept the
> subsequent requests, but when I use a SAML trace tool my
> LogoutRequest is being sent in the OPTIONS request body. Any idea
> where I could be going wrong? Here's my code:
>
Yeah, that's very odd.  As you probably know, in this binding the
actual HTTP request to the SAML protocol recipient is being sent by the
user's browser, based on the HTML form returned by the SAML protocol
sender.  I don't know of any reason off-hand why the browser would do
that.  Maybe Scott has heard of something like this.   I've heard
mention of Chrome doing weird things...  What browser is this?  Do you
see the same with a different browser?

In terms of confirming what is going on, it would be useful for you to
confirm exactly what the page/form returned by the encoder looks like. 
Either use browser debugging tools to see the HTTP response body from
the SAML sender, or turn off Javascript in the browser just prior to
invoking this so the form doesn't auto-post and then do a view source
in the browser.

I'm 99.99% certain that will show the form having method="post", since
that's pretty much all OpenSAML will do.  If that's the case, then the
OPTIONS request is due to something that the browser is doing, and
we'll just have to go from there.  That is out of our control, and very
troubling if browsers are starting to misbehave like that.

Thanks,
Brent

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20190315/4fb13b4b/attachment.html>