http -> https automatic forwarding

[Mark Taylor]

Hi Walter et al.

On Wed, 8 Feb 2017, Walter Landry wrote:

> Our organization is in the process of migrating everything we do to
> https.  Getting the services running under https and updating our
> registry entries is straightforward.  However, people have various
> scripts that they have already written, and we would like to avoid
> breaking them.  So we were wondering what is the best thing to do for
> clients that try to access the old http url's.
> 
> My inclination is to provide a redirect.  As I understand it, the
> simple access methods (e.g. Simple Cone Search) allow a service to
> provide a redirect for the original query, so any compliant client
> should be able to handle a redirect to a https service.  I am less
> confident about what might happen when a user tries to POST something.

This will depend on exactly what you're doing.
You can't just do a 303 redirect from an HTTP POST URL to the
equivalent HTTPS POST URL.  RFC2616 says, amongst other things:

   10.3.4 303 See Other

   The response to the request can be found under a different
   URI and SHOULD be retrieved using a GET method on that resource.
   This method exists primarily to allow the output of a POST-activated
   script to redirect the user agent to a selected resource.
   The new URI is not a substitute reference for the originally
   requested resource.

so you have to set up an HTTP POST URL that behaves the same as
the equivalent HTTPS URL, processing the arguments and returning
a corresponding GETtable URL, which may be HTTP or HTTPS.
If you set up your UWS services like that, I believe TOPCAT
will work with them.

On Fri, 10 Feb 2017, Walter Landry wrote:

> Patrick Dowler <pdowler.cadc at gmail.com> wrote:
> > - 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.

This appears to be designed behaviour in the JRE, as discussed at:
http://stackoverflow.com/questions/1884230/urlconnection-doesnt-follow-redirect

> That is ... really unfortunate.  That sounds like it would break
> Topcat :(

For GET-only (e.g. DALI-sync) type services, like cone search,
that want to be accessible via an HTTP->HTTPS redirect, that is
probably true.  If people want I could consider doing something
about that along the lines of the code that Pierre has posted.
If we do consider that to be generally desirable behaviour perhaps the
case of cross-protocol redirects ought to be mentioned in DALI sec 2.2,
since the language there is all about HTTP redirects, and it's not
explicit how it would map to HTTPS.  However note that in most
cases I'd expect topcat-based cone searches to pick up access URLs
direct from the registry and hence use the 'correct' endpoints
anyway rather than legacy HTTP ones.  As you say, those issues
are most likely from old shell scripts.

Mark

--
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-9288776  http://www.star.bris.ac.uk/~mbt/