{
    "mode": "man",
    "parameter": "gitprotocol-http",
    "section": "5",
    "url": "https://www.chedong.com/phpMan.php/man/gitprotocol-http/5/json",
    "generated": "2026-11-08T13:32:15Z",
    "synopsis": "<over-the-wire-protocol>",
    "sections": {
        "NAME": {
            "content": "gitprotocol-http - Git HTTP-based protocols\n",
            "subsections": []
        },
        "SYNOPSIS": {
            "content": "<over-the-wire-protocol>\n\n",
            "subsections": []
        },
        "DESCRIPTION": {
            "content": "Git supports two HTTP based transfer protocols. A \"dumb\" protocol which requires only a\nstandard HTTP server on the server end of the connection, and a \"smart\" protocol which\nrequires a Git aware CGI (or server module). This document describes both protocols.\n\nAs a design feature smart clients can automatically upgrade \"dumb\" protocol URLs to smart\nURLs. This permits all users to have the same published URL, and the peers automatically\nselect the most efficient transport available to them.\n",
            "subsections": []
        },
        "URL FORMAT": {
            "content": "URLs for Git repositories accessed by HTTP use the standard HTTP URL syntax documented by RFC\n1738, so they are of the form:\n\nhttp://<host>:<port>/<path>?<searchpart>\n\nWithin this documentation the placeholder $GITURL will stand for the http:// repository URL\nentered by the end-user.\n\nServers SHOULD handle all requests to locations matching $GITURL, as both the \"smart\" and\n\"dumb\" HTTP protocols used by Git operate by appending additional path components onto the\nend of the user supplied $GITURL string.\n\nAn example of a dumb client requesting a loose object:\n\n$GITURL:     http://example.com:8080/git/repo.git\nURL request:  http://example.com:8080/git/repo.git/objects/d0/49f6c27a2244e12041955e262a404c7faba355\n\nAn example of a smart request to a catch-all gateway:\n\n$GITURL:     http://example.com/daemon.cgi?svc=git&q=\nURL request:  http://example.com/daemon.cgi?svc=git&q=/info/refs&service=git-receive-pack\n\nAn example of a request to a submodule:\n\n$GITURL:     http://example.com/git/repo.git/path/submodule.git\nURL request:  http://example.com/git/repo.git/path/submodule.git/info/refs\n\nClients MUST strip a trailing /, if present, from the user supplied $GITURL string to\nprevent empty path tokens (//) from appearing in any URL sent to a server. Compatible clients\nMUST expand $GITURL/info/refs as foo/info/refs and not foo//info/refs.\n",
            "subsections": []
        },
        "AUTHENTICATION": {
            "content": "Standard HTTP authentication is used if authentication is required to access a repository,\nand MAY be configured and enforced by the HTTP server software.\n\nBecause Git repositories are accessed by standard path components server administrators MAY\nuse directory based permissions within their HTTP server to control repository access.\n\nClients SHOULD support Basic authentication as described by RFC 2617. Servers SHOULD support\nBasic authentication by relying upon the HTTP server placed in front of the Git server\nsoftware.\n\nServers SHOULD NOT require HTTP cookies for the purposes of authentication or access control.\n\nClients and servers MAY support other common forms of HTTP based authentication, such as\nDigest authentication.\n",
            "subsections": []
        },
        "SSL": {
            "content": "Clients and servers SHOULD support SSL, particularly to protect passwords when relying on\nBasic HTTP authentication.\n",
            "subsections": []
        },
        "SESSION STATE": {
            "content": "The Git over HTTP protocol (much like HTTP itself) is stateless from the perspective of the\nHTTP server side. All state MUST be retained and managed by the client process. This permits\nsimple round-robin load-balancing on the server side, without needing to worry about state\nmanagement.\n\nClients MUST NOT require state management on the server side in order to function correctly.\n\nServers MUST NOT require HTTP cookies in order to function correctly. Clients MAY store and\nforward HTTP cookies during request processing as described by RFC 2616 (HTTP/1.1). Servers\nSHOULD ignore any cookies sent by a client.\n",
            "subsections": []
        },
        "GENERAL REQUEST PROCESSING": {
            "content": "Except where noted, all standard HTTP behavior SHOULD be assumed by both client and server.\nThis includes (but is not necessarily limited to):\n\nIf there is no repository at $GITURL, or the resource pointed to by a location matching\n$GITURL does not exist, the server MUST NOT respond with 200 OK response. A server SHOULD\nrespond with 404 Not Found, 410 Gone, or any other suitable HTTP status code which does not\nimply the resource exists as requested.\n\nIf there is a repository at $GITURL, but access is not currently permitted, the server MUST\nrespond with the 403 Forbidden HTTP status code.\n\nServers SHOULD support both HTTP 1.0 and HTTP 1.1. Servers SHOULD support chunked encoding\nfor both request and response bodies.\n\nClients SHOULD support both HTTP 1.0 and HTTP 1.1. Clients SHOULD support chunked encoding\nfor both request and response bodies.\n\nServers MAY return ETag and/or Last-Modified headers.\n\nClients MAY revalidate cached entities by including If-Modified-Since and/or If-None-Match\nrequest headers.\n\nServers MAY return 304 Not Modified if the relevant headers appear in the request and the\nentity has not changed. Clients MUST treat 304 Not Modified identical to 200 OK by reusing\nthe cached entity.\n\nClients MAY reuse a cached entity without revalidation if the Cache-Control and/or Expires\nheader permits caching. Clients and servers MUST follow RFC 2616 for cache controls.\n",
            "subsections": []
        },
        "DISCOVERING REFERENCES": {
            "content": "All HTTP clients MUST begin either a fetch or a push exchange by discovering the references\navailable on the remote repository.\n",
            "subsections": [
                {
                    "name": "Dumb Clients",
                    "content": "HTTP clients that only support the \"dumb\" protocol MUST discover references by making a\nrequest for the special info/refs file of the repository.\n\nDumb HTTP clients MUST make a GET request to $GITURL/info/refs, without any search/query\nparameters.\n\nC: GET $GITURL/info/refs HTTP/1.0\n\nS: 200 OK\nS:\nS: 95dcfa3633004da0049d3d0fa03f80589cbcaf31  refs/heads/maint\nS: d049f6c27a2244e12041955e262a404c7faba355  refs/heads/master\nS: 2cb58b79488a98d2721cea644875a8dd0026b115  refs/tags/v1.0\nS: a3c2e2402b99163d1d59756e5f207ae21cccba4c  refs/tags/v1.0^{}\n\nThe Content-Type of the returned info/refs entity SHOULD be text/plain; charset=utf-8, but\nMAY be any content type. Clients MUST NOT attempt to validate the returned Content-Type. Dumb\nservers MUST NOT return a return type starting with application/x-git-.\n\nCache-Control headers MAY be returned to disable caching of the returned entity.\n\nWhen examining the response clients SHOULD only examine the HTTP status code. Valid responses\nare 200 OK, or 304 Not Modified.\n\nThe returned content is a UNIX formatted text file describing each ref and its known value.\nThe file SHOULD be sorted by name according to the C locale ordering. The file SHOULD NOT\ninclude the default ref named HEAD.\n\ninforefs   =  *( refrecord )\nrefrecord  =  anyref / peeledref\n\nanyref     =  obj-id HTAB refname LF\npeeledref  =  obj-id HTAB refname LF\nobj-id HTAB refname \"^{}\" LF\n"
                },
                {
                    "name": "Smart Clients",
                    "content": "HTTP clients that support the \"smart\" protocol (or both the \"smart\" and \"dumb\" protocols)\nMUST discover references by making a parameterized request for the info/refs file of the\nrepository.\n\nThe request MUST contain exactly one query parameter, service=$servicename, where\n$servicename MUST be the service name the client wishes to contact to complete the operation.\nThe request MUST NOT contain additional query parameters.\n\nC: GET $GITURL/info/refs?service=git-upload-pack HTTP/1.0\n\ndumb server reply:\n\nS: 200 OK\nS:\nS: 95dcfa3633004da0049d3d0fa03f80589cbcaf31  refs/heads/maint\nS: d049f6c27a2244e12041955e262a404c7faba355  refs/heads/master\nS: 2cb58b79488a98d2721cea644875a8dd0026b115  refs/tags/v1.0\nS: a3c2e2402b99163d1d59756e5f207ae21cccba4c  refs/tags/v1.0^{}\n\nsmart server reply:\n\nS: 200 OK\nS: Content-Type: application/x-git-upload-pack-advertisement\nS: Cache-Control: no-cache\nS:\nS: 001e# service=git-upload-pack\\n\nS: 0000\nS: 004895dcfa3633004da0049d3d0fa03f80589cbcaf31 refs/heads/maint\\0multiack\\n\nS: 003fd049f6c27a2244e12041955e262a404c7faba355 refs/heads/master\\n\nS: 003c2cb58b79488a98d2721cea644875a8dd0026b115 refs/tags/v1.0\\n\nS: 003fa3c2e2402b99163d1d59756e5f207ae21cccba4c refs/tags/v1.0^{}\\n\nS: 0000\n\nThe client may send Extra Parameters (see gitprotocol-pack(5)) as a colon-separated string in\nthe Git-Protocol HTTP header.\n\nUses the --http-backend-info-refs option to git-upload-pack(1).\n"
                },
                {
                    "name": "Dumb Server Response",
                    "content": "Dumb servers MUST respond with the dumb server reply format.\n\nSee the prior section under dumb clients for a more detailed description of the dumb\nserver response.\n"
                },
                {
                    "name": "Smart Server Response",
                    "content": "If the server does not recognize the requested service name, or the requested service\nname has been disabled by the server administrator, the server MUST respond with the 403\nForbidden HTTP status code.\n\nOtherwise, smart servers MUST respond with the smart server reply format for the\nrequested service name.\n\nCache-Control headers SHOULD be used to disable caching of the returned entity.\n\nThe Content-Type MUST be application/x-$servicename-advertisement. Clients SHOULD fall\nback to the dumb protocol if another content type is returned. When falling back to the\ndumb protocol clients SHOULD NOT make an additional request to $GITURL/info/refs, but\ninstead SHOULD use the response already in hand. Clients MUST NOT continue if they do not\nsupport the dumb protocol.\n\nClients MUST validate the status code is either 200 OK or 304 Not Modified.\n\nClients MUST validate the first five bytes of the response entity matches the regex\n^[0-9a-f]{4}#. If this test fails, clients MUST NOT continue.\n\nClients MUST parse the entire response as a sequence of pkt-line records.\n\nClients MUST verify the first pkt-line is # service=$servicename. Servers MUST set\n$servicename to be the request parameter value. Servers SHOULD include an LF at the end\nof this line. Clients MUST ignore an LF at the end of the line.\n\nServers MUST terminate the response with the magic 0000 end pkt-line marker.\n\nThe returned response is a pkt-line stream describing each ref and its known value. The\nstream SHOULD be sorted by name according to the C locale ordering. The stream SHOULD\ninclude the default ref named HEAD as the first ref. The stream MUST include capability\ndeclarations behind a NUL on the first ref.\n\nThe returned response contains \"version 1\" if \"version=1\" was sent as an Extra Parameter.\n\nsmartreply     =  PKT-LINE(\"# service=$servicename\" LF)\n\"0000\"\n*1(\"version 1\")\nreflist\n\"0000\"\nreflist        =  emptylist / nonemptylist\n\nemptylist      =  PKT-LINE(zero-id SP \"capabilities^{}\" NUL cap-list LF)\n\nnonemptylist  =  PKT-LINE(obj-id SP name NUL caplist LF)\n*refrecord\n\ncap-list        =  capability *(SP capability)\ncapability      =  1*(LCALPHA / DIGIT / \"-\" / \"\")\nLCALPHA        =  %x61-7A\n\nrefrecord      =  anyref / peeledref\nanyref         =  PKT-LINE(obj-id SP name LF)\npeeledref      =  PKT-LINE(obj-id SP name LF)\nPKT-LINE(obj-id SP name \"^{}\" LF\n"
                }
            ]
        },
        "SMART SERVICE GIT-UPLOAD-PACK": {
            "content": "This service reads from the repository pointed to by $GITURL.\n\nClients MUST first perform ref discovery with $GITURL/info/refs?service=git-upload-pack.\n\nC: POST $GITURL/git-upload-pack HTTP/1.0\nC: Content-Type: application/x-git-upload-pack-request\nC:\nC: 0032want 0a53e9ddeaddad63ad106860237bbf53411d11a7\\n\nC: 0032have 441b40d833fdfa93eb2908e52742248faf0ee993\\n\nC: 0000\n\nS: 200 OK\nS: Content-Type: application/x-git-upload-pack-result\nS: Cache-Control: no-cache\nS:\nS: ....ACK %s, continue\nS: ....NAK\n\nClients MUST NOT reuse or revalidate a cached response. Servers MUST include sufficient\nCache-Control headers to prevent caching of the response.\n\nServers SHOULD support all capabilities defined here.\n\nClients MUST send at least one \"want\" command in the request body. Clients MUST NOT reference\nan id in a \"want\" command which did not appear in the response obtained through ref discovery\nunless the server advertises capability allow-tip-sha1-in-want or\nallow-reachable-sha1-in-want.\n\ncomputerequest   =  wantlist\nhavelist\nrequestend\nrequestend       =  \"0000\" / \"done\"\n\nwantlist         =  PKT-LINE(want SP caplist LF)\n*(wantpkt)\nwantpkt          =  PKT-LINE(want LF)\nwant              =  \"want\" SP id\ncaplist          =  capability *(SP capability)\n\nhavelist         =  *PKT-LINE(\"have\" SP id LF)\n\nTODO: Document this further.\n",
            "subsections": [
                {
                    "name": "The Negotiation Algorithm",
                    "content": "The computation to select the minimal pack proceeds as follows (C = client, S = server):\n\ninit step:\n\nC: Use ref discovery to obtain the advertised refs.\n\nC: Place any object seen into set advertised.\n\nC: Build an empty set, common, to hold the objects that are later determined to be on both\nends.\n\nC: Build a set, want, of the objects from advertised that the client wants to fetch, based on\nwhat it saw during ref discovery.\n\nC: Start a queue, cpending, ordered by commit time (popping newest first). Add all client\nrefs. When a commit is popped from the queue its parents SHOULD be automatically inserted\nback. Commits MUST only enter the queue once.\n\none compute step:\n\nC: Send one $GITURL/git-upload-pack request:\n\nC: 0032want <want #1>...............................\nC: 0032want <want #2>...............................\n....\nC: 0032have <common #1>.............................\nC: 0032have <common #2>.............................\n....\nC: 0032have <have #1>...............................\nC: 0032have <have #2>...............................\n....\nC: 0000\n\nThe stream is organized into \"commands\", with each command appearing by itself in a pkt-line.\nWithin a command line, the text leading up to the first space is the command name, and the\nremainder of the line to the first LF is the value. Command lines are terminated with an LF\nas the last byte of the pkt-line value.\n\nCommands MUST appear in the following order, if they appear at all in the request stream:\n\n•   \"want\"\n\n•   \"have\"\n\nThe stream is terminated by a pkt-line flush (0000).\n\nA single \"want\" or \"have\" command MUST have one hex formatted object name as its value.\nMultiple object names MUST be sent by sending multiple commands. Object names MUST be given\nusing the object format negotiated through the object-format capability (default SHA-1).\n\nThe have list is created by popping the first 32 commits from cpending. Fewer can be\nsupplied if cpending empties.\n\nIf the client has sent 256 \"have\" commits and has not yet received one of those back from\nscommon, or the client has emptied cpending it SHOULD include a \"done\" command to let the\nserver know it won’t proceed:\n\nC: 0009done\n\nS: Parse the git-upload-pack request:\n\nVerify all objects in want are directly reachable from refs.\n\nThe server MAY walk backwards through history or through the reflog to permit slightly stale\nrequests.\n\nIf no \"want\" objects are received, send an error: TODO: Define error if no \"want\" lines are\nrequested.\n\nIf any \"want\" object is not reachable, send an error: TODO: Define error if an invalid \"want\"\nis requested.\n\nCreate an empty list, scommon.\n\nIf \"have\" was sent:\n\nLoop through the objects in the order supplied by the client.\n\nFor each object, if the server has the object reachable from a ref, add it to scommon. If a\ncommit is added to scommon, do not add any ancestors, even if they also appear in have.\n\nS: Send the git-upload-pack response:\n\nIf the server has found a closed set of objects to pack or the request ends with \"done\", it\nreplies with the pack. TODO: Document the pack based response\n\nS: PACK...\n\nThe returned stream is the side-band-64k protocol supported by the git-upload-pack service,\nand the pack is embedded into stream 1. Progress messages from the server side MAY appear in\nstream 2.\n\nHere a \"closed set of objects\" is defined to have at least one path from every \"want\" to at\nleast one \"common\" object.\n\nIf the server needs more information, it replies with a status continue response: TODO:\nDocument the non-pack response\n\nC: Parse the upload-pack response: TODO: Document parsing response\n\nDo another compute step.\n"
                }
            ]
        },
        "SMART SERVICE GIT-RECEIVE-PACK": {
            "content": "This service reads from the repository pointed to by $GITURL.\n\nClients MUST first perform ref discovery with $GITURL/info/refs?service=git-receive-pack.\n\nC: POST $GITURL/git-receive-pack HTTP/1.0\nC: Content-Type: application/x-git-receive-pack-request\nC:\nC: ....0a53e9ddeaddad63ad106860237bbf53411d11a7 441b40d833fdfa93eb2908e52742248faf0ee993 refs/heads/maint\\0 report-status\nC: 0000\nC: PACK....\n\nS: 200 OK\nS: Content-Type: application/x-git-receive-pack-result\nS: Cache-Control: no-cache\nS:\nS: ....\n\nClients MUST NOT reuse or revalidate a cached response. Servers MUST include sufficient\nCache-Control headers to prevent caching of the response.\n\nServers SHOULD support all capabilities defined here.\n\nClients MUST send at least one command in the request body. Within the command portion of the\nrequest body clients SHOULD send the id obtained through ref discovery as oldid.\n\nupdaterequest  =  commandlist\n\"PACK\" <binary data>\n\ncommandlist    =  PKT-LINE(command NUL caplist LF)\n*(commandpkt)\ncommandpkt     =  PKT-LINE(command LF)\ncaplist        =  *(SP capability) SP\n\ncommand         =  create / delete / update\ncreate          =  zero-id SP newid SP name\ndelete          =  oldid SP zero-id SP name\nupdate          =  oldid SP newid SP name\n\nTODO: Document this further.\n",
            "subsections": []
        },
        "REFERENCES": {
            "content": "RFC 1738: Uniform Resource Locators (URL)[1] RFC 2616: Hypertext Transfer Protocol —\nHTTP/1.1[2]\n",
            "subsections": []
        },
        "SEE ALSO": {
            "content": "gitprotocol-pack(5) gitprotocol-capabilities(5)\n",
            "subsections": []
        },
        "GIT": {
            "content": "Part of the git(1) suite\n",
            "subsections": []
        },
        "NOTES": {
            "content": "1. RFC 1738: Uniform Resource Locators (URL)\nhttp://www.ietf.org/rfc/rfc1738.txt\n\n2. RFC 2616: Hypertext Transfer Protocol — HTTP/1.1\nhttp://www.ietf.org/rfc/rfc2616.txt\n\nGit 2.43.0                                   07/02/2025                          GITPROTOCOL-HTTP(5)",
            "subsections": []
        }
    },
    "summary": "gitprotocol-http - Git HTTP-based protocols",
    "flags": [],
    "examples": [],
    "see_also": [
        {
            "name": "gitprotocol-pack",
            "section": "5",
            "url": "https://www.chedong.com/phpMan.php/man/gitprotocol-pack/5/json"
        },
        {
            "name": "gitprotocol-capabilities",
            "section": "5",
            "url": "https://www.chedong.com/phpMan.php/man/gitprotocol-capabilities/5/json"
        }
    ]
}