-
Notifications
You must be signed in to change notification settings - Fork 25
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
RPC failed; HTTP 400 curl 22 The requested URL returned error: 400 #30
Comments
in routes/git.go UploadPack function: if err = upr.Decode(r.Body); chk.E(err) {
var rdr io.Reader
if rdr, err = gzip.NewReader(r.Body); !chk.E(err) {
if err = upr.Decode(rdr); chk.E(err) {
http.Error(w, err.Error(), 400)
return
}
}
http.Error(w, err.Error(), 400)
return
} fixes the problem |
@mleku Thanks for your feedback. I'll try to find time to deal with this issue as that issue or a similar one has been nagging at me again. |
@mleku I don't know, but I seem to get similarly phrased errors that I'm unable to investigate. Because of lack of logging. My impression is that this kind of issue about packet length are tied to timestamps. But I do not know enough about the git protocol to make an informed judgement. It doesn't work. And then, after a few hours, it works. It seems to match the UTC offset related to my time zone. I'm 1. unsure if this is related to that, but it seems so, and 2. have yet no clue as to whether or not legit manages timestamps w/r to timezones properly. |
Your code is incomplete. For instance, |
well, if you ever read any rob pike code you'd know about the concept of err!=nil check functions i log at the site and that function prints if there is an error, i think you can see the semantics of it just fine was just trying to be helpful the relevant logger is here i depend on logging in my work because you can't debug realtime concurrent processes without having a complex harness that also slows down the client's clock |
I've been unfrozen only recently. Up to a few months ago, I did not know who Taylor Swift was. So Rob Pike... Bottom line: I'm new to go code. I'm interested in legit not because it's go but because it's minimalistic and because the inner Neanderthal in me still works from the command line with no X handy. I've noticed your legit fork. Will have a look. |
i broke that thing... hmm better put it on my github i guess had a fit of pique and tried to go self hosted but legit failed me with gzip and other pack encoding errors... https://github.com/mleku/legit just put it back on my github account including the logger also with a bit more polish this thing would be a great basis for a distributed git hosting network like what the nostr people are working on i don't know exactly what the glitch is and only some repos seem to do it, so it may be some quirk in git that isn't handled by the go-git, but i made a small change that partly fixed it, but then after it tries gzip decompression it then says it fails too so idk? is there another compression that can be in use like bzip or zstd or something? |
It might be that glitch. In fact, going back to an old version of legit (using git and and not go-git) did fix it. For a time. And it broke again. The glitch I experienced may be summed up as follows: 1. git clone a legit repo is ok. 2. git remote add followed by git fetch fails. |
I did some (unwanted) changes on my server, and as a result, legit doesn't work. My bad. However, I tried to fix things, got all access rights correct, I do not see what is wrong anymore, and I get the below error when performing git clone.
RPC failed; HTTP 400 curl 22 The requested URL returned error: 400
On the server side, I get a rather unhelpful message:
2023/12/01 12:59:30 git: invalid pkt-len found
Bottom line: legit is bare bones, which I like. It is perhaps a bit too bare bone: logging is really limited to debug issues.
And any hint as to what these errors may mean, precisely, would be more than welcome.
But please enhance logging.
The text was updated successfully, but these errors were encountered: