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 dsp
mailing list