>
> 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.
Any ideas?

Am Dienstag, 26. Mai 2015 12:42:30 UTC+2 schrieb Konstantin Khomoutov:
>
> On Mon, 25 May 2015 13:44:49 -0700 (PDT) 
> Matthias Lantsch <alasar.go...@gmail.com <javascript:>> wrote: 
>
> > Hello community I have a problem with the "new" http-backend of git. 
> > I have set up the git-http-backend to use the "smart" http version of 
> > git. Authentification works fine, I can clone my repository over http 
> > and https as expected. 
> > For testing purposes, GIT_SSL_NO_VERIFY and http.receivepack are both 
> > set to true. 
> > But when I am trying to push, I get a 404 header back and a return 
> > code 22: 
> > > PROPFIND /git/repo/test.git/ HTTP/1.1 
>
> How did you obtain there results?  Run Git client having set 
>
>   GIT_CURL_VERBOSE=1 
>
> in the environment, right? 
>
> I then wonder where are the attempts to do GET requests against 
>
>   git/repo/test.git/info/refs?service=git-receive-pack 
>
> in this log output before that PROPFIND attempt. 
>
> 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? 
>
> [...] 
> > That of course had me confused, because PROPFIND is a Webdav call and 
> > I thought the http backend would only use "smart" http (webdav is not 
> > enabled on the server) 
> > In an answer *here* 
> > <
> http://serverfault.com/questions/180413/authentication-for-git-push-over-http>
>  
>
> > it confirms that Webdav should actually not even be used. It also 
> > states that Webdav will be used as backup if the client receives a 
> > 403 header. But my Access log as well as the trace do not show any 
> > sign of that. 
>
> > Through my hook script I got a dump of the environement 
> > that is submitted to the script: 
> [...] 
> > export CONTENT_TYPE='text/xml' 
> > export QUERY_STRING='req=git/repo/test.git/' 
> > export REQUEST_METHOD='PROPFIND' 
> [...] 
> > The error log logging the error output of the git-http-backend 
> > contains that: 
> > Status: 404 Not Found 
> [...] 
> > Request not supported: '/theRealPathToTheGitRoot/gitroot/test.git/ 
>
> 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. 
>
> > Did I mess something up? I am sure that Webdav should not be required 
> > for the backend to work. 
>
> Absolutely. 
> Well, may be unless you have truly outdated Git setup on the server. 
> I'm not even sure what version is that. 
>
> I'm not sure it helps but I once helped someone on SO to set up 
> authenticated pushes over Apache, and my answer contains more 
> background info on how Git client performs HTTP requests [1]. 
> May be this will help you sort things out. 
>
> I'd try plain curl calls like 
>
>   $ curl -X GET http://server/git/repo/test.git/info/refs?service=... 
>
> and see what happens. 
>
> You might also try asking on the main Git list as well, as it's being 
> read by a person who actually implemented that smart HTTP transport. 
>
> 1. http://stackoverflow.com/a/26383935 
>

-- 
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.

Reply via email to