gopls usually interacts with the client (a text editor) over an LSP JSONRPC session. But there are a great many ways in which we could improve the user experience of the IDE by having gopls run a local web server. Currently, it starts a web server only in response to an obscure extension to the LSP protocol used by us maintainers, but we would like to generalize this so that the server is always running.

Some of the additional features we would like to integrate this way include:

• CPU and heap profiles (e.g. pprof's list, svg, and flame views) obtained from running go test;
• coverage reports obtained from running go test;
• pkgsite's preview of Go documentation for the user's edited Go source.

The LSP showDocument RPC, which is sent from the server (gopls) to the client (text editor), allows the server to trigger the opening of a document in the text editor (for file: URIs) or the browser (for https URIs). This enables very rich integrations whereby, for example, pkgsite could display Go documentation including links to the source code that, when clicked, cause the user's editor to open the relevant source file.

One concern is security: although a localhost web server cannot be reached from the Internet, any process on the user's machine can GET documents that potentially contain source code or other private file contents. HTTP cookies are an imperfect solution as they are not port-scoped, so if a malicious process can trick a user into visiting a malicious local HTTP server on one port, it can obtain their cookies and use them to access gopls's server on another port. A crude but effective solution would be for each gopls process to choose a random number and use this as the root of its URL endpoint tree, e.g. http://localhost:12345/fb6cecc85a10/index. Every valid URL would start with, or be relative to, this unguessable root.