Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x/tools/gopls: use a localhost web server for richer interaction #59340

Open
adonovan opened this issue Mar 31, 2023 · 0 comments
Open

x/tools/gopls: use a localhost web server for richer interaction #59340

adonovan opened this issue Mar 31, 2023 · 0 comments
Labels
FeatureRequest gopls Issues related to the Go language server, gopls. Tools This label describes issues relating to any tools in the x/tools repository.
Milestone

Comments

@adonovan
Copy link
Member

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.

@gopherbot gopherbot added Tools This label describes issues relating to any tools in the x/tools repository. gopls Issues related to the Go language server, gopls. labels Mar 31, 2023
@gopherbot gopherbot added this to the Unreleased milestone Mar 31, 2023
@findleyr findleyr modified the milestones: Unreleased, gopls/later Apr 4, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
FeatureRequest gopls Issues related to the Go language server, gopls. Tools This label describes issues relating to any tools in the x/tools repository.
Projects
None yet
Development

No branches or pull requests

3 participants