Page MenuHomePhabricator

git clone fails with HTTP-error 415
Closed, ResolvedPublic

Description

I know that the hosted repo feature is fairly new and needs some testing, but thats what I want to do :).

I created a new repo in the webinterface and then tried to clone this repo.

This is the output I get:

E:\temp>git clone https://bk-dev.hacked.jp/diffusion/T/ testrepo
Cloning into 'testrepo'...
efrror: RPC failed; result=22, HTTP code = 415
atal: The remote end hung up unexpectedly

Looking at the code of git-http-backend, 415 means that the content-type is wrong. Looking even further at DiffusionServeController::serveGitRequest. It seems to me that the content-type is just pushed through.

Is this a bug of diffusion or just my server having some issues?

I'm using git version 1.8.3.msysgit.0 as the clone client and git version 1.7.10.4 is on the server.

Can I enable some kind of logging, that shows me what env is passed to the git-http-backend executeable?

Event Timeline

enko raised the priority of this task from to Needs Triage.
enko updated the task description. (Show Details)
enko added a project: Diffusion.
enko added a subscriber: enko.

We should just be shoving this through unmodified. There's no real logging, but you can add something like this:

phlog(print_r(array(
  'value1' => $value1,
  'value2' => $value2,
), true));

...to serveGitRequest and then check your webserver error log (usually /var/apache/error.log or similar, if under apache).

One other user has reported something similar, although we also have several who can clone things fine, so it might be a config/version issue. Let me know if you figure anything out.

Ok, found out why this fails. $_SERVER does not contains HTTP_CONTENT_TYPE. $_SERVER looks like that for the request:

 Array
(
    [REDIRECT_HTTPS] => on
    [REDIRECT_SSL_TLS_SNI] => bk-dev.hacked.jp
    [REDIRECT_STATUS] => 200
    [HTTPS] => on
    [SSL_TLS_SNI] => bk-dev.hacked.jp
    [HTTP_USER_AGENT] => git/1.8.3.msysgit.0
    [HTTP_HOST] => bk-dev.hacked.jp
    [HTTP_ACCEPT_ENCODING] => gzip
    [CONTENT_TYPE] => application/x-git-upload-pack-request
    [HTTP_ACCEPT] => application/x-git-upload-pack-result
    [CONTENT_LENGTH] => 174
    [PATH] => /usr/local/bin:/usr/bin:/bin
    [SERVER_SIGNATURE] => <address>Apache/2.2.22 (Debian) Server at bk-dev.hacked.jp Port 443</address>

    [SERVER_SOFTWARE] => Apache/2.2.22 (Debian)
    [SERVER_NAME] => bk-dev.hacked.jp
    [SERVER_ADDR] => 2a01:4f8:120:1085::2
    [SERVER_PORT] => 443
    [REMOTE_ADDR] => 2001:4bd8:2f:24:dc29:dcd2:8299:416a
    [DOCUMENT_ROOT] => /usr/local/phabricator/webroot
    [SERVER_ADMIN] => tim@boese-ban.de
    [SCRIPT_FILENAME] => /usr/local/phabricator/webroot/index.php
    [REMOTE_PORT] => 49886
    [REDIRECT_QUERY_STRING] => __path__=/diffusion%2fT%2fgit%2dupload%2dpack
    [REDIRECT_URL] => /diffusion/T/git-upload-pack
    [GATEWAY_INTERFACE] => CGI/1.1
    [SERVER_PROTOCOL] => HTTP/1.1
    [REQUEST_METHOD] => POST
    [QUERY_STRING] => __path__=/index%2ephp&__path__=/diffusion%2fT%2fgit%2dupload%2dpack
    [REQUEST_URI] => /diffusion/T/git-upload-pack
    [SCRIPT_NAME] => /index.php
    [PHP_SELF] => /index.php
    [PHP_AUTH_USER] => enko
    [PHP_AUTH_PW] => 
    [REQUEST_TIME_FLOAT] => 1384188326.213
    [REQUEST_TIME] => 1384188326
)

It seems Content-Type is a bit special in this case: http://www.php.net/manual/en/reserved.variables.server.php#110763

What about using getallheaders instead of your approach? I have attached a patch for this, which makes it work here™.

I don't want to use getallheaders() because we can't unit test that (we have no way to control what it returns). I'll accept a patch to special-case Content-Type / Content-Length, though, if you want to do that. Thanks for figuring this out!