4 ms·

This is the error I see in the response body in HTTP Toolkit. ``` Error: Passthrough loop detected. This probably means you're sending a request directly to a

This is the error I see in the response body in HTTP Toolkit. ``` Error: Passthrough loop detected. This probably means you're sending a request directly to a passthrough endpoint, which is forwarding it to the target URL, which is a passthrough endpoint, which is forwarding it to the target URL, which is a passthrough endpoint... You should either explicitly mock a response for this URL (http://127.0.0.1:8000/golang.org/x/oauth2/@v/list http://127.0.0.1:8000/golang.org/x/oauth2/@v/list), or use the server as a proxy, instead of making requests to it directly. ```

pimterry 5y ago
That's really interesting! That's what appears if you HTTP Toolkit receives a request, proxies to the provided destination, and then finds itself on the other end of its own outgoing socket. This avoids the simplest infinite proxy loops. That'll make if you try to proxy a request to `127.0.0.1:8000` via HTTP Toolkit for example. That shouldn't be happening here though - there's no way Go should be using the proxy address as its target URL. I.e. to see this result, it must be sending a request like: GET /golang.org/x/oauth2/@v/list Host: 127.0.0.1:8000 You can probably see the full details in HTTP Toolkit's request data. Any chance you've added a rule in HTTP Toolkit that's redirecting traffic back to itself? That could do this, and would show up as two identical requests in HTTP Toolkit. If not (you can reset the rules by hitting the trash icon on the mock page) then this means something in your Go setup is either configured very strangely or its interpreting HTTP Toolkit's configuration incorrectly. Sorry I can't be more helpful, I have no idea why `go get` would send a request like that! If you can pin it down to something I can reproduce (e.g. a specific Go version or config setting or something) than I'm happy to investigate further, but it seems to work correctly everywhere I've tested so far.
- IceWreck 5y ago
  > Any chance you've added a rule in HTTP Toolkit that's redirecting traffic back to itself. No, I literally downloaded it after seeing the post on HN and started a terminal with it for testing. Default settings. I'm using Fedora 35 if it helps. Then I started using that terminal for something else and thats when I realized go get was failing.

pimterry 5y ago

That's really interesting! That's what appears if you HTTP Toolkit receives a request, proxies to the provided destination, and then finds itself on the other end of its own outgoing socket. This avoids the simplest infinite proxy loops. That'll make if you try to proxy a request to `127.0.0.1:8000` via HTTP Toolkit for example. That shouldn't be happening here though - there's no way Go should be using the proxy address as its target URL. I.e. to see this result, it must be sending a request like: GET /golang.org/x/oauth2/@v/list Host: 127.0.0.1:8000 You can probably see the full details in HTTP Toolkit's request data. Any chance you've added a rule in HTTP Toolkit that's redirecting traffic back to itself? That could do this, and would show up as two identical requests in HTTP Toolkit. If not (you can reset the rules by hitting the trash icon on the mock page) then this means something in your Go setup is either configured very strangely or its interpreting HTTP Toolkit's configuration incorrectly. Sorry I can't be more helpful, I have no idea why `go get` would send a request like that! If you can pin it down to something I can reproduce (e.g. a specific Go version or config setting or something) than I'm happy to investigate further, but it seems to work correctly everywhere I've tested so far.

IceWreck 5y ago
> Any chance you've added a rule in HTTP Toolkit that's redirecting traffic back to itself. No, I literally downloaded it after seeing the post on HN and started a terminal with it for testing. Default settings. I'm using Fedora 35 if it helps. Then I started using that terminal for something else and thats when I realized go get was failing.