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

Jump to bottom

proposal: cmd/go: use RFC 5785 .well-known URI instead of ?go-get=1 #27989

Closed
aeris opened this issue Oct 3, 2018 · 8 comments
Closed

proposal: cmd/go: use RFC 5785 .well-known URI instead of ?go-get=1 #27989

aeris opened this issue Oct 3, 2018 · 8 comments
Labels
FrozenDueToAge Proposal
Milestone
Proposal

Comments

@aeris
Copy link

aeris commented Oct 3, 2018

Currently, golang use https://example.org/pkg/module?go-get=1 to detect a custom import path.

It's impossible or complicated to support such requests if the targeted domain already serve real content.
You have to patch your root site to support go-imports, which can be tedious (Wordpress) if impossible (static landing page) or to modify your httpd config with ugly tricks (like this) and add overhead on each request.

Why not use RFC5785 /.well-known/ URIs to declare a custom go-imports path instead?
This way, it doesn't break existing content nor require httpd config and can be statically served.
@bradfitz
Copy link
Contributor

bradfitz commented Oct 3, 2018

While I like people using RFC 5785, it's not exactly appropriate here. We're asking about a per-URL property on paths, not a site-wide property.

If we wanted to do the appropriate thing would've used content negotiation (e.g. sending an Accept header and looking at the response Content-Type), but that was deemed too magic and hard to debug by hand, IIRC.

One could say that instead of /pkg/foo/bar?go-get=1 we request /.well-known/go-get-meta/pkg/foo/bar, that could work, but it's still weird and Accept still seems like the better option.

@ghost
Copy link

ghost commented Oct 3, 2018

With the <meta> tag, a publisher only needs to control a particular sub-directory in the HTTP root. With /.well-known/, control over that folder is required.

@aeris
Copy link
Author

aeris commented Oct 3, 2018

If we wanted to do the appropriate thing would've used content negotiation (e.g. sending an Accept header and looking at the response Content-Type), but that was deemed too magic and hard to debug by hand, IIRC.

Using accept/content-type require dynamic request handling, which require PHP/python/ruby/CGI/whatever server side or complex httpd config too.
In all cases, dynamic requests should be on a specific sub-folder (in this case, better to use RFC5785) or subdomain to avoid real content patches or httpd config changes.

Using a solution requiring only static content on a subfolder would be easier to set up and deployable everywhere without prerequisite or specific golang patch.

@aeris
Copy link
Author

aeris commented Oct 3, 2018

a publisher only needs to control a particular sub-directory in the HTTP root

Not only. Currently, you require no real content (or patchable one), or httpd config access to be able to configure response to ?go-get=1, which is in practice a lot of more complicated prerequisites to have than just a plain old folder at your domain root.
Software like Wordpress, Gitea or Gitlab or any landing content need to be explicitly patched to support go-get=1, with some side-effects or troubles

@bradfitz
Copy link
Contributor

bradfitz commented Oct 3, 2018

I also don't see how we could roll out this change even if we wanted to.

We'd have to make two HTTP requests for compatibility, which seems gross, even if they're done concurrently.

@aeris
Copy link
Author

aeris commented Oct 3, 2018

I also don't see how we could roll out this change even if we wanted to.

Trying /.well-known/ and then ?go-get=1 (or the opposite) if no valid response.
No need for concurrency here, no?
At the end of transition, most of the time only 1 request will be made.

@bradfitz bradfitz changed the title Use of RFC5785 .well-known URI instead of ?go-get=1 proposal: cmd/go: use of RFC 5785 .well-known URI instead of ?go-get=1 Oct 3, 2018
@gopherbot gopherbot added this to the Proposal milestone Oct 3, 2018
@bradfitz bradfitz changed the title proposal: cmd/go: use of RFC 5785 .well-known URI instead of ?go-get=1 proposal: cmd/go: use RFC 5785 .well-known URI instead of ?go-get=1 Oct 3, 2018
@rsc
Copy link
Contributor

rsc commented Oct 10, 2018

If you don't want to look for go-get=1, don't. Just serve the relevant HTML meta tag always. That's what most redirectors do.

Note also that the meta tag only needs to mention the root, not the page that was requested, so it's possible to serve as static content for a whole tree of packages.

Note also that the go command will even look for meta tags in 404 pages, so that you don't even have to have "200 OK" content there.

The current setup is working quite well and we can't possibly remove it. At most we'd have to add a second mechanism. It is not worth the disruption and confusion of introducing a second mechanism, especially one that doesn't work as well (requires control over the root of the web server space).

$ curl https://rsc.io/pdf/asdf/asdf/asdf
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
<meta name="go-import" content="rsc.io/pdf git https://github.com/rsc/pdf">
<meta http-equiv="refresh" content="0; url=https://godoc.org/rsc.io/pdf/asdf/asdf/asdf">
</head>
<body>
Redirecting to docs at <a href="https://godoc.org/rsc.io/pdf/asdf/asdf/asdf">godoc.org/rsc.io/pdf/asdf/asdf/asdf</a>...
</body>
</html>

@rsc rsc closed this as completed Oct 10, 2018
@aeris
Copy link
Author

aeris commented Oct 10, 2018

If you don't want to look for go-get=1, don't. Just serve the relevant HTML meta tag always. That's what most redirectors do.

Perhaps most of redirectors don't host a Wordpress, Drupal, Prestashop or a Hugo blog on their landing page ? Or had already patch their landing software to explicitly support Go, like Gitlab did.
😄

If you use a well known software, with a team to address such software customization, or are a big company like Github, yes, you can afford ?go-get=1.
But if like me you are just a lonely random guy with small if no free time to get worked up to add meta on a not Go related software, ?go-get=1 is just a pain in the ass.

@golang golang locked and limited conversation to collaborators Oct 10, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge Proposal
Projects
None yet
Milestone
Proposal
Development

No branches or pull requests
4 participants
@bradfitz @aeris @rsc @gopherbot