disabling PROPFIND when using smart http

Hello,

Although smart http worked fine for me out of the box, following "man
git-http-backend", I've found folks on #git for whom it seems to fail
on doing a PROPFIND (found by setting GIT_CURL_VERBOSE=1).  Enabling
WebDAV also doesn't seem to help, although that is quite likely to be
some nuance in the Apache config I suppose.

The thing is, I *think* that PROPFIND is not, strictly speaking,
needed when you use the smart HTTP mode.  If that is indeed true, can
we stop git from even attempting it, and so avoid the need to setup
WebDAV on Apache?

Would be a great help for many installations.

Thanks,


--
Sitaram

On Tue, Nov 23, 2010 at 09:10:43PM +0530, Sitaram Chamarty wrote:

Hello,

Although smart http worked fine for me out of the box, following "man
git-http-backend", I've found folks on #git for whom it seems to fail
on doing a PROPFIND (found by setting GIT_CURL_VERBOSE=1).  Enabling
WebDAV also doesn't seem to help, although that is quite likely to be
some nuance in the Apache config I suppose.

The thing is, I *think* that PROPFIND is not, strictly speaking,
needed when you use the smart HTTP mode.  If that is indeed true, can
we stop git from even attempting it, and so avoid the need to setup
WebDAV on Apache?

I thought that this is quite strange, and as consequence, decided to
dig a bit. 

This is pretty telling:

$ git grep -i --files-with-matches "propfind"
http-push.c

http-push.c is AFAIK not used by smart HTTP, only by dumb HTTP
push.

Apparently pusher is falling back to dumb WebDAV push for some
reason. And then failing because server does not support it
or isn't configured apporiately for it.

-Ilari

Hey,

On Tue, Nov 23, 2010 at 8:10 AM, Ilari Liusvaara
[off-list ref] wrote:

Apparently pusher is falling back to dumb WebDAV push for some
reason. And then failing because server does not support it
or isn't configured apporiately for it.

Yes, the client will fall back to 'dumb' HTTP stuff if the server does
not respond properly to the initial /info/refs GET call.  I believe
it's something like if the client asks for

/info/refs?service=git-upload-pack

and the server does not respond with the first line being:

# service=git-upload-pack

or the Content-Type header being:

application/x-git-upload-pack-advertisement

I believe either of those being absent will cause the client to think
that it's not a smart server, so it falls back to the DAV based push.
If you let us know what the curl output before that point was, or what
your apache config looks like, we might be able to help figure out
what's wrong with the server.

I got these DAV fallbacks all the time when my proxy wasn't letting
the /info/refs calls through to Apache properly.

Scott

On Tue, Nov 23, 2010 at 11:01 PM, Scott Chacon [off-list ref] wrote:

Hey,

On Tue, Nov 23, 2010 at 8:10 AM, Ilari Liusvaara
[off-list ref] wrote:

quoted

Apparently pusher is falling back to dumb WebDAV push for some
reason. And then failing because server does not support it
or isn't configured apporiately for it.

Yes, the client will fall back to 'dumb' HTTP stuff if the server does
not respond properly to the initial /info/refs GET call.  I believe
it's something like if the client asks for

/info/refs?service=git-upload-pack

and the server does not respond with the first line being:

# service=git-upload-pack

or the Content-Type header being:

application/x-git-upload-pack-advertisement

I believe either of those being absent will cause the client to think
that it's not a smart server, so it falls back to the DAV based push.
If you let us know what the curl output before that point was, or what
your apache config looks like, we might be able to help figure out
what's wrong with the server.

Well it was someone else, but the pastie he has sent was
http://pastebin.com/eaB0G1gx -- which may or may not help, because it
doesn't seem to show the response *body*, only the headers.

If that doesn't help I'll try and reproduce the problem myself first.

Thanks,

Sitaram

Hey,

On Tue, Nov 23, 2010 at 11:40 AM, Sitaram Chamarty [off-list ref] wrote:

Well it was someone else, but the pastie he has sent was
http://pastebin.com/eaB0G1gx -- which may or may not help, because it
doesn't seem to show the response *body*, only the headers.

If that doesn't help I'll try and reproduce the problem myself first.

Still, it's enough.  The request is obviously not getting back to the
Git CGI for some reason.  There are a number of headers that should
have been returned after the first authed GET to /info/refs (lines
35-42 have the servers response).  It should have:

< Content-Type: application/x-git-receive-pack-advertisement
< Pragma: no-cache
< Cache-Control: no-cache, max-age=0, must-revalidate

The Git CGI will set all of those.  Since it's not, and it's setting
things like ETags, it's not the Git CGI you're communicating with.
Check the apache logs and see why it's not routing the request to the
cgi.

Scott