Why do you want this?

Do you want this for using present locally on your computer with https, or for using it remotely over the internet via https?

Also, are you aware of https://talks.godoc.org/? If not, does that help you achieve what you want to do?

CC @campoy

@shurcooL want using present locally with https

Since using HTTPS requires a TLS certificate (it could be self-signed, but that would display a red warning message that "the authenticity of this page cannot be verified", etc.), are you planning on bringing your own certificate to use with present, or is this issue also about finding a way to come up/create a certificate?

Doing the above seems pretty involved, and I'm not sure what the benefits would be. If you bind using the 127.0.0.0 address, connecting to it should be secure (as far as I know), since the connection uses your local network stack and cannot be seen by anyone external.

I'm not against this, I just want to understand the benefits and motivation better.

@shurcooL I just use reverse proxy to handle https,like caddy/nginx

https://present.xxx.com {
	gzip
	tls tls/present.xxx.com.crt tls/present.xxx.com.key {
		   alpn http/1.1
	}	
	proxy / http://127.0.0.1:3999

	proxy /socket 127.0.0.1:3999 {
		websocket
	}
}

but present play.js ,use fixed ws:// protocol

so ,if src/golang.org/x/tools/cmd/present/local.go
provide a new flag, support assign protocol, like

	https= flag.Bool("https", fale, "http/https")

origin := &url.URL{Scheme: “http or https”}

src/golang.org/x/tools/godoc/static/static.go
check location.protocol to new WebSocket(‘ws://’ or wss://

I see.

Is your end goal to expose the present tool's output at an internet website (e.g., https://present.xxx.com in your sample Caddyfile)?

If so, I think it should absolutely support proxying from wss:// to ws:// protocol, does it not? /cc @mholt It should be very similar to reverse proxying external https:// traffic to your local backend via http:// (as far as I understand).

@shurcooL yes,expose the present to https website.
caddy or nginx support wss:// protocol, but present 's javascript, use fxed ws:// protocol

Just skimming this issue before I go to sleep, so forgive me if I've missed something; but I think you'll need to use wss:// to get a websocket connection on an HTTPS page.

@mholt you are right! so I think problem is present's javascript(src/golang.org/x/tools/godoc/static/playground.js) , should detetive location.protocol to new WebSocket using ws:// or wss:// ,

function SocketTransport() {
	var websocket = new WebSocket('ws://  or wss://' + window.location.host + '/socket');

and src/golang.org/x/tools/cmd/present/local.go, should supply a new flag to assign protocol(http or https)
origin := &url.URL{Scheme: "http or https"}

You're right, the JavaScript will need to be updated to be able to connect to wss://, since that's what the reverse proxy will expose.

@ddatsh Would it be more accurate to rename this issue from "support https" to "support being reverse proxied from https" or so?

We don't need to add full fledged support for https (which comes with a lot of overhead and doesn't have meaningful benefits) to present tool to resolve your issue. We just need to add support for its output being proxied and accessible via https/wss. These would be much less invasive changes, and therefore much easier to accept.

Yes, it seems like we should support having it behind a reverse proxy.

found can just modify caddyFile like

https://xx.xxx.com {
	gzip
	minify 
	tls tls/xxx.crt tls/xxx.key
	
	proxy / http://127.0.0.1:3999
	proxy /socket 127.0.0.1:3999 {
		header_upstream Origin http://127.0.0.1:3999
		header_upstream Host 127.0.0.1:3999
		websocket
	}
}

but still need modify godoc/static/playground.js

    var websocket;
    if(window.location.protocol == "http:"){
        websocket = new WebSocket('ws://' + window.location.host + '/socket');
    }else if(window.location.protocol == "https:"){
        websocket = new WebSocket('wss://' + window.location.host + '/socket');
    }

CL 96295 mentions this issue.

Change https://golang.org/cl/96295 mentions this issue: cmd/present: support being reverse proxied from https

Thank you @ddatsh for addressing review comments and resolving this issue!