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