Git over HTTPS on the Same Port: Tips and Tricks

Serving Git repositories over HTTPS on the same port as your web application is an efficient way to simplify your infrastructure. This approach reduces the number of open ports needed and can make firewall configurations easier to manage. By using smart HTTP protocol and proper reverse proxy configuration, you can seamlessly serve both web content and Git repositories through port 443 (HTTPS) or port 80 (HTTP).

Introduction

Running Git over HTTPS on the same port as your web server can simplify your infrastructure and reduce the number of open ports. Traditionally, Git services like Gitolite or Gitweb would run on separate ports, requiring additional firewall rules and complicating network configurations. By consolidating services on standard HTTP/HTTPS ports, you can leverage existing SSL certificates, simplify monitoring, and reduce attack surface.

Smart HTTP protocol allows Git clients to intelligently negotiate with HTTP servers, enabling efficient Git operations over standard web protocols. This eliminates the need for specialized Git daemons running on non-standard ports.

Key Topics to Cover

Smart HTTP Protocol Explained

The Smart HTTP protocol is Git's native way of communicating over HTTP/S. Unlike dumb HTTP which serves static files, Smart HTTP uses CGI scripts (like git-http-backend) to negotiate capabilities and transfer data efficiently. Git clients send specific HTTP requests that the server interprets to determine whether to perform uploads, downloads, or ref advertisements.

Key advantages include:

• Efficient data transfer using packfiles
• Authentication at the repository level
• Ability to host multiple repositories under different paths
• Compatibility with existing HTTP infrastructure

Configuring git-http-backend with Nginx/Apache

Git's http-backend CGI script handles Smart HTTP requests. Proper configuration involves:

1. Setting appropriate PATH_INFO and SCRIPT_FILENAME variables
2. Configuring GIT_PROJECT_ROOT and GIT_HTTP_EXPORT_ALL environment variables
3. Ensuring proper permissions on repository directories
4. Limiting access through authentication mechanisms

For Nginx, this typically involves using fastcgi_params or uwsgi_params depending on your setup. For Apache, you'd use ScriptAlias or SetHandler directives.

Reverse Proxy Setup

When placing Git services behind a reverse proxy (common for SSL termination), you must:

• Preserve original Host headers
• Forward the correct protocol scheme (http/https)
• Pass through all Git-specific HTTP headers
• Handle large request bodies for Git push operations
• Configure appropriate timeouts for long-running Git operations

Authentication Integration

Authentication can be handled at multiple levels:

• Web server level (basic auth, LDAP, OAuth)
• Application level (custom auth systems)
• Gitolite/GitLab style authorization layers

The key is ensuring that authentication information flows correctly to the git-http-backend process so it can make proper access control decisions.

Port Multiplexing Strategies

True port multiplexing involves distinguishing Git requests from web requests at the same URL path. Strategies include:

• Path-based routing (/git/ for Git, / for web)
• Subdomain-based routing (git.example.com vs www.example.com)
• Header-based routing (examining User-Agent or custom headers)
• Using different HTTP methods (though less common)

Security Considerations

Critical security aspects include:

• Validating and sanitizing all inputs to prevent injection attacks
• Implementing proper repository permissions
• Using HTTPS exclusively for Git operations (never plain HTTP)
• Rate limiting to prevent abuse
• Regularly updating Git server components
• Auditing logs for unusual access patterns

Troubleshooting Common Issues

Common problems and their solutions:

• 403 errors: Usually permission issues on repository directories
• 500 errors: Check Git server logs for CGI script problems
• Slow performance: Often related to missing packfile optimization
• Authentication failures: Verify header forwarding in reverse proxy
• Push failures: Check content-length limits and timeout settings

Conclusion

Implementing Git over HTTPS on the same port as your web application offers significant operational benefits. By following the practices outlined in this guide—proper Smart HTTP protocol implementation, correct reverse proxy configuration, thoughtful authentication integration, and attention to security considerations—you can create a robust, efficient Git hosting solution that shares infrastructure with your web applications.

The key to success lies in understanding how Git's Smart HTTP protocol works and ensuring that all components of your infrastructure—from reverse proxy to Git backend—are properly configured to work together. While the initial setup may require careful attention to detail, the resulting simplification of your network architecture and reduced maintenance overhead make it well worth the effort.

Remember to regularly monitor your Git server performance and security, keep your software updated, and always test configuration changes in a staging environment before deploying to production.

Frequently Asked Questions

Do I need to install special software to serve Git over HTTPS?

No, you don't need special software. Git's built-in git-http-backend CGI script (included with Git) handles Smart HTTP requests. You'll need a web server like Nginx or Apache to serve as the frontend, and optionally an authentication system.

Can I host multiple Git repositories on the same domain?

Yes, absolutely. With path-based routing (e.g., example.com/git/repo1, example.com/git/repo2), you can host numerous repositories under the same domain and port. Each repository just needs to be properly configured in your GIT_PROJECT_ROOT.

Is serving Git over HTTPS secure?

Yes, when properly configured. Always use HTTPS (never plain HTTP) for Git operations to encrypt credentials and data. Implement proper authentication, validate inputs, set correct repository permissions, and keep your Git server components updated.

What performance impact should I expect?

Performance is comparable to traditional Git serving methods. The Smart HTTP protocol uses efficient packfile transfers, and with proper caching and reverse proxy configuration, you should see minimal overhead compared to running Git on a dedicated port.

How does authentication work with Git over HTTPS?

Authentication can be handled at the web server level (basic auth, LDAP, OAuth), application level, or through Git-specific authorization layers like Gitolite or GitLab. The key is ensuring authentication headers are properly forwarded to the git-http-backend process so it can make access control decisions.