http -> https automatic forwarding

[Brian Major]

Hi everyone,

We've scheduled a slot at the end of the first GWS session in Shanghai
(Tuesday, 11am) to discuss this very issue.

Cheers,
Brian

On Mon, Feb 13, 2017 at 4:28 AM, Mark Taylor <M.B.Taylor at bristol.ac.uk>
wrote:

> 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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/grid/attachments/20170509/1fc48862/attachment.html>