The Host header is handled specially by the Go http library and
needs special processing in order to have it forwarded with the
other headers to the auth backend.

Support Kerberos authentication "final leg" as per RFC4559

This for the passwordless Kerberos token authentication to comply with the RFC.

See merge request !4

Add custom "User-Agent" header to auth requests

This makes it a lot easier to proxy requests to gitlab-git-http-server when Gitlab is running inside Passenger (or similiar) and therefore does not have a dedicated port.

Example Apache config:
~~~~
RewriteEngine on
RewriteCond "%{REQUEST_URI}" "^[-/\w\.]+\.git/"
RewriteCond "%{HTTP_USER_AGENT}" "!=gitlab-git-http-server"
RewriteRule . http://127.0.0.1:8181%{REQUEST_URI} [P,QSA]
~~~~

See merge request !1

The profiler is disabled by default. It will allow us to better
understand the behavior of gitlab-git-http-server in production.

After reading the curious Git repository corruption report in
https://gitlab.com/gitlab-org/gitlab-ce/issues/2336 (where
gitlab-git-http-server was NOT being used, for the record), I feel
inclined to be a little more cautious and use SIGTERM instead of
SIGKILL to terminate the git-xxx-pack process group in case of
aborted requests.

Also discussed in
https://gitlab.com/gitlab-org/gitlab-git-http-server/issues/1 .

Splitting the program in multiple files broke the Makefile, oops.

Change in behavior: we stop panicking in the middle of writing a
response body; instead we do a 'clean' return from the handler.

This lets us drop a few global variables.

The Golang net/http HTTP server will not pass URLs with '/../' in
them to our code (see http://golang.org/pkg/net/http/#ServeMux ).

Change in behavior: we now accept requests with path '/'. This
should not be a problem; upstream GitLab (the 'auth backend') still
decides if Git access to the path is OK. We are still guarding
against traversal.

We want literal periods, not arbitraty characters. :(

TODO: add a test for this

We should not leave open a TCP connection to the auth backend
(Unicorn) in the CLOSE_WAIT state, it may take several minutes for
the HTTP response to our own client to finish.

We were seeing a resource leak:

2015/08/07 12:09:17 Get http://localhost:8080/gitlab/omnibus-gitlab.git/info/refs?service=git-upload-pack: dial tcp: lookup localhost: too many open files
2015/08/07 12:09:18 http: Accept error: accept tcp 127.0.0.1:8181: too many open files; retrying in 5ms

My guess is it was about not closing the auth response body.