x/pkgsite/cmd/frontend: no longer loads stdlib in proxy mode #63249
Comments
bcmills
changed the title
Hmm. I suspect that's a bug in the Probably if a module with an invalid path is requested from @aslatter, want to send a fix? |
|
Just to make sure I understand, you mean something like this? diff --git a/internal/proxy/client.go b/internal/proxy/client.go
index 92adc32c..dec80330 100644
--- a/internal/proxy/client.go
+++ b/internal/proxy/client.go
@@ -175,7 +175,14 @@ func (c *Client) ZipSize(ctx context.Context, modulePath, resolvedVersion string
}
func (c *Client) EscapedURL(modulePath, requestedVersion, suffix string) (_ string, err error) {
- defer derrors.WrapStack(&err, "Client.escapedURL(%q, %q, %q)", modulePath, requestedVersion, suffix)
+ defer func() {
+ // if we cannot correctly craft a URL for the request module, it's possible we are dealing with
+ // something we cannot proxy (i.e. stdlib).
+ //
+ // Pass-back "NotFound" so we keep searching.
+ err = fmt.Errorf("%w: %s", derrors.NotFound, err)
+ derrors.WrapStack(&err, "Client.escapedURL(%q, %q, %q)", modulePath, requestedVersion, suffix)
+ }()
if suffix != "info" && suffix != "mod" && suffix != "zip" {
return "", errors.New(`suffix must be "info", "mod" or "zip"`) |
|
That seems like probably too low a level for the transformation. It looks like there are already special cases in Perhaps the |
|
I can think of two options:
Both of these feel kinda icky - (2) has a higher density of weird coupling of components, but (1) requires the proxy-client having to know about the "std" module. My comment about flipping the order of the getters in the issue-description was not a serious suggestion - it was more describing what I'd done to diagnose things. But it doesn't seem worse than these options? Every module which is handled by the stdlib-getter can never be handled by the proxy-getter. |
|
cc @jba |
aslatter
changed the title
|
As far as I can tell this issue is a blocker for running in "direct proxy" mode. Any work-arounds would be appreciated (or guidance/advice for running in non-proxy mode). I'd be happy to send a fix, but it seemed like the direction we wanted to take wasn't clear. |
What version of Go are you using (
go version)?Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env)?go envOutputWhat did you do?
We run pkgsite and host it internally to provide documentation for our own packages. We run it in "direct" mode, and send it through our internal go-proxy (Athena), which has credentials to fetch our internal go-modules.
We run pkgsite with arguments like the following:
After commit f159e616582641bdbeb2d6a0018ca4c8c472fbb5 we are no longer able to load godocs
for stdlib packages - for example, loading
http://localhost:8080/iowill return HTTP-500 with the following logs from pkgsite:The error. It is objected to a module named std, which seems like a reasonable thing to object-to.malformed module path "std": missing dot in first path element: invalid argumentappears to be coming fromour go-proxy (Athena)
(edit: on further testing the error is internal to pkgsite - the module for loading stdlib does not seem to be compatible with the direct-proxy mode)
If I swap the order of the getters used in fetchdatasource.Options in the direct-mode branch of frontend startup everything seems to work for me:
Bisect result:
What did you expect to see?
What did you see instead?
The text was updated successfully, but these errors were encountered: