<div dir="ltr">Hi everyone,<div><br></div><div>We've scheduled a slot at the end of the first GWS session in Shanghai (Tuesday, 11am) to discuss this very issue. </div><div><br></div><div>Cheers,</div><div>Brian<br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 13, 2017 at 4:28 AM, Mark Taylor <span dir="ltr"><<a href="mailto:M.B.Taylor@bristol.ac.uk" target="_blank">M.B.Taylor@bristol.ac.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Walter et al.<br>
<span class=""><br>
On Wed, 8 Feb 2017, Walter Landry wrote:<br>
<br>
> Our organization is in the process of migrating everything we do to<br>
> https. Getting the services running under https and updating our<br>
> registry entries is straightforward. However, people have various<br>
> scripts that they have already written, and we would like to avoid<br>
> breaking them. So we were wondering what is the best thing to do for<br>
> clients that try to access the old http url's.<br>
><br>
> My inclination is to provide a redirect. As I understand it, the<br>
> simple access methods (e.g. Simple Cone Search) allow a service to<br>
> provide a redirect for the original query, so any compliant client<br>
> should be able to handle a redirect to a https service. I am less<br>
> confident about what might happen when a user tries to POST something.<br>
<br>
</span>This will depend on exactly what you're doing.<br>
You can't just do a 303 redirect from an HTTP POST URL to the<br>
equivalent HTTPS POST URL. RFC2616 says, amongst other things:<br>
<br>
10.3.4 303 See Other<br>
<br>
The response to the request can be found under a different<br>
URI and SHOULD be retrieved using a GET method on that resource.<br>
This method exists primarily to allow the output of a POST-activated<br>
script to redirect the user agent to a selected resource.<br>
The new URI is not a substitute reference for the originally<br>
requested resource.<br>
<br>
so you have to set up an HTTP POST URL that behaves the same as<br>
the equivalent HTTPS URL, processing the arguments and returning<br>
a corresponding GETtable URL, which may be HTTP or HTTPS.<br>
If you set up your UWS services like that, I believe TOPCAT<br>
will work with them.<br>
<br>
On Fri, 10 Feb 2017, Walter Landry wrote:<br>
<span class=""><br>
> Patrick Dowler <<a href="mailto:pdowler.cadc@gmail.com">pdowler.cadc@gmail.com</a>> wrote:<br>
> > - at least in java, redirects that change protocol are not followed<br>
> > automatically by the http library as the design means backing out of<br>
> > using an HttpURLConnection and instantiating an HttpsURLConnection<br>
> > instead; iirc applications have to detect the redirect and create a<br>
> > new URLConnection from the Location even if they told the last one to<br>
> > follow redirects.<br>
<br>
</span>This appears to be designed behaviour in the JRE, as discussed at:<br>
<a href="http://stackoverflow.com/questions/1884230/urlconnection-doesnt-follow-redirect" rel="noreferrer" target="_blank">http://stackoverflow.com/<wbr>questions/1884230/<wbr>urlconnection-doesnt-follow-<wbr>redirect</a><br>
<span class=""><br>
> That is ... really unfortunate. That sounds like it would break<br>
> Topcat :(<br>
<br>
</span>For GET-only (e.g. DALI-sync) type services, like cone search,<br>
that want to be accessible via an HTTP->HTTPS redirect, that is<br>
probably true. If people want I could consider doing something<br>
about that along the lines of the code that Pierre has posted.<br>
If we do consider that to be generally desirable behaviour perhaps the<br>
case of cross-protocol redirects ought to be mentioned in DALI sec 2.2,<br>
since the language there is all about HTTP redirects, and it's not<br>
explicit how it would map to HTTPS. However note that in most<br>
cases I'd expect topcat-based cone searches to pick up access URLs<br>
direct from the registry and hence use the 'correct' endpoints<br>
anyway rather than legacy HTTP ones. As you say, those issues<br>
are most likely from old shell scripts.<br>
<br>
Mark<br>
<br>
--<br>
Mark Taylor Astronomical Programmer Physics, Bristol University, UK<br>
<a href="mailto:m.b.taylor@bris.ac.uk">m.b.taylor@bris.ac.uk</a> <a href="tel:%2B44-117-9288776" value="+441179288776">+44-117-9288776</a> <a href="http://www.star.bris.ac.uk/~mbt/" rel="noreferrer" target="_blank">http://www.star.bris.ac.uk/~<wbr>mbt/</a><br>
</blockquote></div><br></div></div></div>