Closed cytown closed 5 years ago
Hi @cytown, are you talking about goproxy/goproxy or goproxy/goproxy.cn? I tried goproxy.cn
and didn't have multiple Content-Length cases.
@aofei Yes, it's not occur in my local laptop, but when we build it with K8S, it will fail with that error.
Now we change to goproxy.io, seems it works...
We use Ali Cloud, you can invested it what's wrong.
Glad you found a temporary solution. Anyway, I'm sorry for the inconvenience caused to you.
But weird, I can't reproduce this similar error in my k8s. Can you provide me with more information? Please, I'd love to know how and why this error occurred. 🙏
Not every fetch will fail, this is a part of log, you can find that many were success, but not all:
... above all success. go: finding github.com/armon/go-metrics v0.0.0-20180917152333-f0300d1749da go: finding github.com/gobuffalo/genny v0.0.0-20190403191548-3ca520ef0d9e go: finding golang.org/x/net v0.0.0-20181201002055-351d144fa1fc go: finding github.com/ryanuber/columnize v0.0.0-20160712163229-9b3edd62028f go: github.com/armon/go-metrics@v0.0.0-20180917152333-f0300d1749da: net/http: server replied with more than declared Content-Length; truncated go: finding github.com/gobuffalo/logger v0.0.0-20190315122211-86e12af44bc2 go: github.com/gobuffalo/plush@v3.8.0+incompatible: net/http: server replied with more than declared Content-Length; truncated go: finding gopkg.in/couchbaselabs/gojcbmock.v1 v1.0.3 go: github.com/gofrs/uuid@v3.2.0+incompatible: net/http: server replied with more than declared Content-Length; truncated go: finding github.com/fatih/structs v1.1.0 go: golang.org/x/net@v0.0.0-20181201002055-351d144fa1fc: net/http: server replied with more than declared Content-Length; truncated go: finding github.com/armon/circbuf v0.0.0-20150827004946-bbbad097214e go: github.com/gobuffalo/flect@v0.1.3: net/http: server replied with more than declared Content-Length; truncated go: finding github.com/modern-go/reflect2 v1.0.1 go: github.com/mitchellh/mapstructure@v1.1.2: net/http: server replied with more than declared Content-Length; truncated go: finding gopkg.in/go-playground/validator.v8 v8.18.2 go: github.com/ryanuber/columnize@v0.0.0-20160712163229-9b3edd62028f: net/http: server replied with more than declared Content-Length; truncated go: finding github.com/mitchellh/gox v0.4.0 go: github.com/gobuffalo/logger@v0.0.0-20190315122211-86e12af44bc2: net/http: server replied with more than declared Content-Length; truncated go: finding github.com/inconshreveable/mousetrap v1.0.0 go: finding github.com/onsi/gomega v1.5.0 go: finding github.com/onsi/ginkgo v1.8.0
Looks like the goproxy.cn limit the request rate cause this.
Rate Limit? Sorry, this limit is what we must have now because we've been attacked a while ago (and right now). See #5.
Is it not enough to have 1,200 requests per hour? It has increased to 3,600 per hour, and it should be better now. Please try it out and tell me the result. :-)
Note that this project (goproxy.cn) is still under development and will be handed over to Qiniu Cloud. So this problem will be solved in the future (very soon).
Hmm, maybe that's the problem. Just because we use this as a jenkins server in K8s, so every submit will cause the container build and fetch the so many packages, it's so easy to reach the limit in that way.
I think you need separate the real requests and the ddns attacks. In most cases, it's not so hard to implement.
Thank you, I'll think about it. So, I'm going to close this issue now. Sorry again for the inconvenience. :-)
the error codes like this:
go: gopkg.in/couchbaselabs/gocbconnstr.v1@v1.0.2: net/http: server replied with more than declared Content-Length; truncated ... ... go: github.com/opentracing/opentracing-go@v1.1.0: net/http: server replied with more than declared Content-Length; truncated go: error loading module requirements