http -> https automatic forwarding
Walter Landry
wlandry at caltech.edu
Sat Feb 11 00:02:25 CET 2017
Patrick Dowler <pdowler.cadc at gmail.com> wrote:
> Yeah, extraneous redirects generally mess up the post-redirect-get
> pattern (eg as used in UWS async job creation).
>
> We have also run into a few issues with redirects that change protocol:
>
> - users think they are calling an http url but then they get some
> obscure SSL error because their system CA bundle doesn't contain the
> necessary certficicates to validate your server cert and that can
> happen when your server cert is signed by a valid but intermediate CA
> and the full chain isn't propagated correctly. I think this can be
> correctly handled server-side by configuring correctly, but many
> incorrect configurations work for some people so testing corner cases
> is necessary (and difficult)
I ran into this problem as well. As you said, it is purely a
server-side configuration problem. It was very confusing, because the
browser can cache intermediate certificates. I found running tests
with curl was a good way to catch this issue.
> - at least in java, redirects that change protocol are not followed
> automatically by the http library as the design means backing out of
> using an HttpURLConnection and instantiating an HttpsURLConnection
> instead; iirc applications have to detect the redirect and create a
> new URLConnection from the Location even if they told the last one to
> follow redirects.
That is ... really unfortunate. That sounds like it would break
Topcat :(
Thanks,
Walter Landry
More information about the grid
mailing list