General proposal for the developer guidelines: use protocol independent urls "//"

[Wikinaut]

As mentioned in #1202 (comment) in the context of bringing SSL to Etherpad Lite, it appears to be necessary to think of re-coding every URL in all links in the core and in plugins and in resources (css image urls) which are not relative to the server to become

• protocol-independent

to use "//" instead of http:// or https:// .

Everywhere.

References:

• Fix 1148 add native node https support #1202 (comment)
• http://stackoverflow.com/a/550164

Important

Of course this only works, if the resource servers actually deliver their contents also over https:// .

[joker-x]

The strangle thing is that not new, it appear in RFC 3986 of 1995: http://tools.ietf.org/html/rfc3986#section-4.2
22 years ago! :D
Must be very compatible xD

[Wikinaut]

Yes, I know this RFC very well. The http://stackoverflow.com/a/550164 has some thoughts.

[JohnMcLear]

Seems like a relatively sound proposal, assuming ws:// wont be affected.

[Wikinaut]

@johnyma22 ty for your kind words. Currently I am trying to download the yui from yahoo and supply a (really working) proof of concept. I am convinced that it will work.

https://yui.yahoo..... does not work, the Yahoo does not deliver its content via https://..I removed already the (somehow) misleading information on #1202 (sorry for that)

[Wikinaut]

I can now officially confirm, that "it" works.

"it" means:

when copying and unzipping http://yuilibrary.com/downloads/yui2/yui_2.9.0.zip to a server which delivers the stuff via https: (I used a non-Node server, running Apache), the protocol independent urls in my ep_tables fork https://github.com/Wikinaut/ep_tables/commit/c65c05924cbac89aa06e7ccbd2f92e76e2708a43 do work, and the ep_tables plugin in my SSL-EPL does work.

[Wikinaut]

added for sake of completeness

incorrectly written plugins may impose risks of mixed https/http content

when referencing an insecure (http) resource within a secure (https) page. Such references create vulnerabilities that put the privacy and integrity of an otherwise-secure page at risk, because the insecure content could be modified in transit. If added to the DOM, insecurely-delivered content can read or alter the rest of the page even if the bulk of the page was delivered over a secure connections. (cited from https://blogs.msdn.com/b/ieinternals/archive/2009/06/22/https-mixed-content-in-ie8.aspx?Redirected=true)

[JohnMcLear]

We're in agreement on this, this got implemented.