Web Profile use from HTTPS pages

[Mark Taylor]

Hi SAMP,

The Science Archives and VO Team at ESAC have come up against a
deficiency of the SAMP Web Profile.

They are providing archive access web pages (for Gaia data) which
try to pass catalogue data out of the browser to local SAMP-compliant
applications using the SAMP Web Profile.  This is a common pattern,
successfully used by various archives.  However, the ESA web pages
are provided using the HTTPS protocol rather than HTTP.

Most(?) modern browsers refuse to access "active" HTTP services
from within an HTTPS page for security reasons [which I don't
understand, but I'm sure they know what they're doing].
The objection is to "mixed active content"; you can see a
discussion here:

   http://stackoverflow.com/questions/18251128/why-am-i-suddenly-getting-a-blocked-loading-mixed-active-content-issue-in-fire

There are browser-specific ways to work around this security restriction
if you really want to, but it's not a good solution.

You can see the problem in action e.g. by looking at examples from
the sampjs documentation (these pages are hosted in parallel by
github in both http and https form).  For me (firefox 24.6.0)
this one works:

   http://astrojs.github.io/sampjs/examples/pinger.html

but this one doesn't:

   https://astrojs.github.io/sampjs/examples/pinger.html

I'm slightly surprised that this hasn't come up before - maybe nobody
has used Web SAMP from HTTPS before or maybe there's some easy
workaround I haven't thought of.

I can see the following ways forward:

   1. Accept that SAMP Web Profile will not work from HTTPS.

   2. Modify the SAMP Web Profile (->SAMP 1.4) to provide an alternative
      HTTPS endpoint on a new port, alongside the existing HTTP endpoint
      (on port 21012).

For 2 I *think* the changes to the standard would be rather small
(though there may be implications I haven't thought of).
I wouldn't expect any disruption to existing (HTTP) web clients.
There would be some implementation effort required for existing
hubs (JSAMP, AstroPy, others?) and general purpose web profile client
toolkits (sampjs, others?).  I'm not sure how difficult this
implementation would be - I could imagine it being either fairly
easy or fairly hard, not sure which.

I invite comments.  Can anybody think of an option 3 or other workaround
for this?  How undesirable do people think option 1 is?

Festive wishes to all our readers!

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/