> > I'm afraid this part is not interesting as it's already about WebDAV > being used, and we want to prevent this situation, right? > Hence, the place to debug is why WebDAV is being used in the first > place. > Yes of course you are correct, the goal is it not using Webdav at all.
> I mean, if the smart HTTP client falls back to dumb transport after > getting 403, then it should have performed at least a single GET/POST > request to hit that error condition. Did you see it? Yes of course I wasn't pasting that part because I already mentioned that the server does NOT return a 403 to a normal GET prior (taken from the access.log) But if it can be of any help, here is the full trace: > GET /git/repo/test.git/info/refs?service=git-receive-pack HTTP/1.1 User-Agent: git/1.9.1 Host: localhost:8080 Accept: */* Accept-Encoding: gzip Pragma: no-cache < HTTP/1.1 200 OK < Date: Tue, 26 May 2015 10:55:07 GMT * Server Apache/2.4.7 (Ubuntu) is not blacklisted < Server: Apache/2.4.7 (Ubuntu) < X-Powered-By: PHP/5.5.9-1ubuntu4.9 < Expires: Fri, 01 Jan 1980 00:00:00 GMT < Pragma: no-cache < Cache-Control: no-cache, max-age=0, must-revalidate < Vary: Accept-Encoding < Content-Encoding: gzip < Content-Length: 186 < Content-Type: text/plain < * Connection #0 to host localhost left intact * Couldn't find host localhost in the .netrc file; using defaults * Found bundle for host localhost: 0x7d8210 * Re-using existing connection! (#0) with host localhost * Connected to localhost (127.0.0.1) port 8080 (#0) > GET /git/repo/test.git/HEAD HTTP/1.1 User-Agent: git/1.9.1 Host: localhost:8080 Accept: */* Accept-Encoding: gzip Pragma: no-cache < HTTP/1.1 200 OK < Date: Tue, 26 May 2015 10:55:07 GMT * Server Apache/2.4.7 (Ubuntu) is not blacklisted < Server: Apache/2.4.7 (Ubuntu) < X-Powered-By: PHP/5.5.9-1ubuntu4.9 < Content-Length: 23 < Content-Type: text/plain < * Connection #0 to host localhost left intact * Couldn't find host localhost in the .netrc file; using defaults * Hostname was NOT found in DNS cache * Trying 127.0.0.1... * Connected to localhost (127.0.0.1) port 8080 (#0) > PROPFIND /git/repo/test.git/ HTTP/1.1 User-Agent: git/1.9.1 Host: localhost:8080 Accept: */* Depth: 0 Content-Type: text/xml Content-Length: 165 Expect: 100-continue < HTTP/1.1 100 Continue * We are completely uploaded and fine * The requested URL returned error: 404 Not Found * Closing connection 0 error: Cannot access URL http://localhost:8080/git/repo/test.git/, return code 22 fatal: git-http-push failed As you can see, no 403 header is sent back, as the access.log already stated. Absolutely. > Well, may be unless you have truly outdated Git setup on the server. > I'm not even sure what version is that. I just checked, the git version on the server is up to date. I thought it could be that not all Environment variables required by the backend to work are set, but I double checked and all those mentioned in the official documentation are set. Does it check if "REMOTE_USER" really is a authentificated user on the apache server?? (even though shouldn't matter, http.receivepack is true) I'd try plain curl calls like > > $ curl -X GET http://server/git/repo/test.git/info/refs?service=... > > and see what happens. I was trying that and following the requests the client issued before receiving the error. The first call, the one to GET /git/repo/test.git/info/refs?service=git-receive-pack returned the expected (?) list of branches and corresponding hashes, The second call to GET /git/repo/test.git/HEAD returns the expected output as well: ref: refs/heads/master Immediately afterwards in the client trace the PROPFIND is issued, which is the strange part to me :/ Maybe I should really write to the developers mailist, so that the creators of the backend could maybe help me. I just reposted because I didn't see that it pasted your whole answer into my answer :) Any ideas? -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.