{"thread":{"id":"37152","subject":"git_inetd_server: run git-http-backend using inetd","startedAt":"2014-07-17T21:28:26Z","lastAt":"2014-07-20T15:25:46Z","messageCount":13,"participants":["Kyle J. McKay","Jonathan Nieder","Torsten Bögershausen"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"246273","messageId":"43923BC7-08AF-4900-AC5E-B2F0FE7CD5AC@gmail.com","threadId":"37152","inReplyTo":null,"subject":"git_inetd_server: run git-http-backend using inetd","fromName":"Kyle J. McKay","fromEmail":"mackyle@gmail.com","sentAt":"2014-07-17T21:28:26Z","receivedAt":"2014-07-17T21:28:26Z","isPatch":false,"sender":{"key":"mackyle@gmail.com","avatar":"https://avatars.githubusercontent.com/u/813346?v=4"},"body":"===========\nWhat is it?\n===========\nI have created a script (POSIX sh compatible) that allows running git- \nhttp-backend via inetd or similar service (it makes it like git-http- \nbackend had a --inet option just like git-daemon does).\n\nThis allows the Git smart HTTP protocol to be served without needing  \nto run a standard web server (assuming inetd, xinetd, launchd or  \nsimilar is already available).\n\nIt is available at [1] with a GPL license.\n\n====\nWhy?\n====\nI have several machines/virtual machines that need to be able to fetch  \nfrom a central Git repository without authentication (several of them  \nare test platforms and are therefore not trusted and typing a password  \non every fetch is a non-starter as some of the fetches are  \nautomated).  I also don't want to have to run a web server just to  \nserve Git fetches.\n\nOf course you say, \"why not use git daemon for that?\"  Well, I was (in  \n--inetd mode), but it has a serious problem and until recently I  \ndidn't know the cause.\n\nTalking to a git-daemon server works great for my FreeBSD, Darwin,  \ncygwin, msysgit platforms, but it's terrible for my Linux platforms.\n\nOn the Linux platforms every git fetch would hang for at least 15  \nseconds before starting the fetch.  I just wrote that off as some odd  \nconfiguration issue I was going to have to live with (although it only  \nhappened with Git and not web browsing or curl fetches).  It's killer  \nthough when fetching a project with lots of submodules as each one has  \nthe delay.\n\nRecently though, I discovered the cause.  While I don't actually run  \nDebian itself, all my Linux platforms are Debian offspring (Ubuntu,  \nRaspbian, Linux Mint, etc.).  The problem is in the Debian git package  \n[2] specifically the \"0010-transport-optionally-honor-DNS-SRV- \nrecords.diff\" patch located in the Debian diffs file [3].\n\nThe 0010 patch makes \"git://host/...\" fetches first try to fetch a git  \nSRV record from DNS.  This patch has a compile time option to enable  \nit, but once baked in it cannot be turned off at runtime and the  \nbinary packages for my distributions all have it turned on and baked  \nin.  And none of these distributions have a visible \"WARNING: Git has  \npatches that may cause it to behave oddly, violate RFC standards and/ \nor experience unexpected delays.\"\n\nIt so happens that my internal network is setup using mDNS [4] (on  \nLinux/FreeBSD by installing Avahi and nss-mdns packages).\n\nWhen I then try to fetch using a \"git://host/...\" URL where \"host\" is  \nan mDNS host name, the 0010 patch causes git to attempt to lookup a  \nDNS SRV record on the non-mDNS regular DNS service (a violation of RFC  \n6762 [4] section 22) and this is what has to time out before the real  \nfetch can start.\n\nSince the patch does not try to lookup an SRV record for \"http:// \nhost/...\" URLs, switching from git: to http: for fetches eliminates  \nthe problem.  However, git-http-backend does not have any of the -- \ndaemon or --inetd related options that git-daemon does.  Hence the  \ngit_inetd_server.sh script [1] that provides the equivalent of a -- \ninetd option for git-http-backend.\n\nI have since discovered that the 0010 patch behavior can be bypassed  \nby explicitly including a port number in the git: URLs.  So instead of  \n\"git://example.local/repo.git\" using \"git://example.local:9418/ \nrepo.git\" avoids the delaying SRV lookup.  This is highly unintuitive  \nsince omitting the default port for a scheme should not change its  \nbehavior (according to RFC 3986 [5] section 3.2.3 the port should be  \nomitted by producers and normalizers if it's the same as the scheme's  \ndefault port).  In any case, unless git_inetd_server.sh can be run on  \nthe default http port (80), the resulting http: URLs are no more  \nconvenient than the git: URLs with an explicit port.\n\nNonetheless, others may find this script helpful as it allows the Git  \nsmart (and non-smart) HTTP protocol to be served without needing to  \nrun a standard web server so I decided to share it.\n\n--Kyle\n\n=====\nLinks\n=====\n[1] https://github.com/mackyle/git_inetd_server\n[2] https://packages.debian.org/wheezy/git\n[3] http://ftp.de.debian.org/debian/pool/main/g/git/git_1.7.10.4-1+wheezy1.diff.gz\n[4] RFC 6762 http://tools.ietf.org/html/rfc6762\n[5] RFC 3986 http://tools.ietf.org/html/rfc3986\n"},{"id":"246275","messageId":"20140717221056.GO12427@google.com","threadId":"37152","inReplyTo":"43923BC7-08AF-4900-AC5E-B2F0FE7CD5AC@gmail.com","subject":"Re: git_inetd_server: run git-http-backend using inetd","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2014-07-17T22:10:56Z","receivedAt":"2014-07-17T22:10:56Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nKyle J. McKay wrote:\n\n> When I then try to fetch using a \"git://host/...\" URL where \"host\"\n> is an mDNS host name, the 0010 patch causes git to attempt to lookup\n> a DNS SRV record on the non-mDNS regular DNS service (a violation of\n> RFC 6762 [4] section 22) and this is what has to time out before the\n> real fetch can start.\n\nThat patch uses res_query from libresolv to do the lookup.  It doesn't\nknow what DNS server to use and relies on system libraries to get it\nright.\n\nIt was added to respond to a feature request within Debian but it is\nintended to eventually go upstream.  I'm glad you found this issue\nbefore that could happen. :)\n\nShould git automatically disable the SRV lookups when it sees one of\nthe six domains named in RFC6762, or is there some system library call\nthat can use mDNS when appropriate automatically (or get partway there\nwithout having to hard-code the domains)?\n\nThanks,\nJonathan\n"},{"id":"246280","messageId":"8E3CD89B-2E47-4CA8-8F3D-598A9BE2AD9F@gmail.com","threadId":"37152","inReplyTo":"20140717221056.GO12427@google.com","subject":"Re: git_inetd_server: run git-http-backend using inetd","fromName":"Kyle J. McKay","fromEmail":"mackyle@gmail.com","sentAt":"2014-07-17T23:38:30Z","receivedAt":"2014-07-17T23:38:30Z","isPatch":false,"sender":{"key":"mackyle@gmail.com","avatar":"https://avatars.githubusercontent.com/u/813346?v=4"},"body":"On Jul 17, 2014, at 15:10, Jonathan Nieder wrote:\n> Hi,\n>\n> Kyle J. McKay wrote:\n>\n>> When I then try to fetch using a \"git://host/...\" URL where \"host\"\n>> is an mDNS host name, the 0010 patch causes git to attempt to lookup\n>> a DNS SRV record on the non-mDNS regular DNS service (a violation of\n>> RFC 6762 [4] section 22) and this is what has to time out before the\n>> real fetch can start.\n>\n> That patch uses res_query from libresolv to do the lookup.  It doesn't\n> know what DNS server to use and relies on system libraries to get it\n> right.\n\nIf I understand the libresolv implementation correctly, it only  \nsupports DNS and not mDNS.  And as far as I know, the nss plugins only  \nsupport A and AAAA lookups, not SRV lookups.  However, it looks like  \nthere are some attempts to add mDNS support directly to res_query and  \nfriends [4].  Maybe that code could serve as a model.\n\n> It was added to respond to a feature request within Debian but it is\n> intended to eventually go upstream.  I'm glad you found this issue\n> before that could happen. :)\n\nIs there some reason the patch is not opt-in at runtime?  In other  \nwords the code is there, but not enabled unless you do something like  \n'git config --system --bool git.srvlookup true'?  If it's off by  \ndefault it doesn't matter so much that it's standards violating as it  \nwon't bite you unless you turn it on and then presumably if you do you  \nknow what you're doing and understand the possible downside.\n\n> Should git automatically disable the SRV lookups when it sees one of\n> the six domains named in RFC6762, or is there some system library call\n> that can use mDNS when appropriate automatically (or get partway there\n> without having to hard-code the domains)?\n\nSadly I think mDNS support is relegated to an add-on package on  \nLinux.  And Avahi [1] is the package that generally provides it  \nthere.  The recommended interface for C is the avahi-client API (see  \n[2]).  However, that is Avahi-only.\n\nIf the patch is to go upstream it probably needs to use the dns-sd.h  \nheader API for maximum compatibility (Avahi provides an avahi-compat- \nlibdns_sd interface via the libavahi-compat-libdnssd-dev package).  I  \nbelieve the correct function would be DNSServiceQueryRecord in this  \ncase.\n\nThat said, for the code to work properly it would need to:\n\n1) Get the canonical name of the host.  If \"local\" is one of the  \nsearch domains or the default domain you could have a mDNS name  \nwithout an explicit .local suffix.  I'm not sure best how to do this.  \nThe getaddrinfo function has an AI_CANONNAME flag but the call will  \nfail if the host does not have an A or AAAA record and in the case of  \nredirection-by-SRV it may have neither.  You probably just have to  \nloop through the search domains keeping in mind the Security  \nConsiderations of section 21 of RFC 6762 [3] (a host MUST NOT append  \nthe search suffix \".local.\", if present, to any relative (partially  \nqualified) host name containing two or more labels. Appending  \n\".local.\" to single-label relative host names is acceptable).  So if a  \nhost name does not end in .local (or .local.) it can only be an mDNS  \nname if it contains no dots ('.') AND \"local\" is one of the search  \ndomains or is the default domain.\n\n2) For mDNS either use the #include <dns_sd.h> DNSServiceQueryRecord  \nfunctionality if available or just skip it if not available.\n\n3) For non-mDNS use the same query as it does now.\n\nEven if the choice is to just disable SRV lookups for mDNS hosts at a  \nminimum the code will have to determine whether or not the given host  \nname is a mDNS name and it can't reliably do that for a host name  \nwithout any dots in it without at least looking at the default domain  \nname and possibly the search domain(s) as well.\n\nI think it would be much simpler just to make this opt-in via a config  \noption rather than baked in as it's probably going to be rather messy  \nwithout direct mDNS support in the res_query interface.\n\n--Kyle\n\n[1] http://avahi.org/\n[2] http://avahi.org/download/doxygen/index.html\n[3] http://tools.ietf.org/html/rfc6762#page-52\n[4] https://www.mail-archive.com/tech@openbsd.org/msg06100.html\n"},{"id":"246282","messageId":"20140718022208.GQ12427@google.com","threadId":"37152","inReplyTo":"8E3CD89B-2E47-4CA8-8F3D-598A9BE2AD9F@gmail.com","subject":"Re: git_inetd_server: run git-http-backend using inetd","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2014-07-18T02:22:08Z","receivedAt":"2014-07-18T02:22:08Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Kyle J. McKay wrote:\n> On Jul 17, 2014, at 15:10, Jonathan Nieder wrote:\n\n>> It was added to respond to a feature request within Debian but it is\n>> intended to eventually go upstream.  I'm glad you found this issue\n>> before that could happen. :)\n>\n> Is there some reason the patch is not opt-in at runtime?\n\nYes, it's a feature for server admins to control where clients\nconnect, to control where the load goes.  If the client has to enable\nit explicitly, that defeats the purpose.\n\nI'd much rather fix it than turn it off completely.\n\n[...]\n>> Should git automatically disable the SRV lookups when it sees one of\n>> the six domains named in RFC6762, or is there some system library call\n>> that can use mDNS when appropriate automatically (or get partway there\n>> without having to hard-code the domains)?\n>\n> Sadly I think mDNS support is relegated to an add-on package on\n> Linux.  And Avahi [1] is the package that generally provides it\n> there.  The recommended interface for C is the avahi-client API (see\n> [2]).  However, that is Avahi-only.\n[...]\n> Even if the choice is to just disable SRV lookups for mDNS hosts at\n> a minimum the code will have to determine whether or not the given\n> host name is a mDNS name and it can't reliably do that for a host\n> name without any dots in it without at least looking at the default\n> domain name and possibly the search domain(s) as well.\n>\n> I think it would be much simpler just to make this opt-in via a\n> config option\n\nThanks for these details.  I'll file a bug and mull it over some more.\n\nRFC 6762 makes it clear that what the package is currently doing is\nwrong.  Given that Debian's libc knows nothing about mdns on its own,\nI think I'll need to parse resolv.conf (that's what libc-ares does).\n\nJonathan\n"},{"id":"246287","messageId":"50047EE8-4EF8-49E3-9067-1C88B2FB9D58@gmail.com","threadId":"37152","inReplyTo":"20140718022208.GQ12427@google.com","subject":"Re: git_inetd_server: run git-http-backend using inetd","fromName":"Kyle J. McKay","fromEmail":"mackyle@gmail.com","sentAt":"2014-07-18T06:48:04Z","receivedAt":"2014-07-18T06:48:04Z","isPatch":false,"sender":{"key":"mackyle@gmail.com","avatar":"https://avatars.githubusercontent.com/u/813346?v=4"},"body":"On Jul 17, 2014, at 19:22, Jonathan Nieder wrote:\n\n> Thanks for these details.  I'll file a bug and mull it over some more.\n>\n> RFC 6762 makes it clear that what the package is currently doing is\n> wrong.  Given that Debian's libc knows nothing about mdns on its own,\n> I think I'll need to parse resolv.conf (that's what libc-ares does).\n\nYou might also want to take a look at [1] which suggests that when  \ndoing SRV lookups for URLs they should be done regardless of whether  \nor not a port number is present (which then eliminates the RFC 3986  \nissue the current SRV lookup code has).  It's only a draft (and  \nexpired now and looks like it received a rather chilly reception from  \nsome), but I haven't noticed anything else that addresses what the  \npatch code is trying to do.  The thread at [2] is related to what the  \npatch is trying to do.\n\n[1] http://tools.ietf.org/html/draft-ohta-urlsrv\n[2] http://www.ietf.org/mail-archive/web/pcp/current/msg01727.html\n"},{"id":"246321","messageId":"20140718171635.GR12427@google.com","threadId":"37152","inReplyTo":"50047EE8-4EF8-49E3-9067-1C88B2FB9D58@gmail.com","subject":"Re: git_inetd_server: run git-http-backend using inetd","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2014-07-18T17:16:35Z","receivedAt":"2014-07-18T17:16:35Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Kyle J. McKay wrote:\n\n> You might also want to take a look at [1] which suggests that when\n> doing SRV lookups for URLs they should be done regardless of whether\n> or not a port number is present (which then eliminates the RFC 3986\n> issue the current SRV lookup code has).\n\n\"Git URLs\" as described e.g. in git-clone(1) weren't intended to be\nactual URIs.  What would be the interoperability advantage of making\nthem URIs?\n\nThis has come up before, with e.g. people asking to introduce a\ngit+ssh:// and git+http:// syntax to refer to repositories accessed\nusing those transports without conflicting with the usual meanings of\nssh:// and http://.  If there's a good use case for that, maybe it\nwould be worth doing some day.\n\nCurious,\nJonathan\n"},{"id":"246350","messageId":"DC1EBA8C-1443-42DA-BA96-CB38D13502ED@gmail.com","threadId":"37152","inReplyTo":"20140718171635.GR12427@google.com","subject":"Re: git_inetd_server: run git-http-backend using inetd","fromName":"Kyle J. McKay","fromEmail":"mackyle@gmail.com","sentAt":"2014-07-19T00:08:18Z","receivedAt":"2014-07-19T00:08:18Z","isPatch":false,"sender":{"key":"mackyle@gmail.com","avatar":"https://avatars.githubusercontent.com/u/813346?v=4"},"body":"On Jul 18, 2014, at 10:16, Jonathan Nieder wrote:\n\n> Kyle J. McKay wrote:\n>\n>> You might also want to take a look at [1] which suggests that when\n>> doing SRV lookups for URLs they should be done regardless of whether\n>> or not a port number is present (which then eliminates the RFC 3986\n>> issue the current SRV lookup code has).\n>\n> \"Git URLs\" as described e.g. in git-clone(1) weren't intended to be\n> actual URIs.\n\nAccording to RFC 3968 section 1.1.3:\n\"A URI can be further classified as a locator, a name, or both. The  \nterm \"Uniform Resource Locator\" (URL) refers to the subset of  \nURIs\" [...]\n\nSo actually they are URIs.\n\n> What would be the interoperability advantage of making\n> them URIs?\n\nAccording to RFC 3968 they are already considered URIs.\n\n\n> This has come up before, with e.g. people asking to introduce a\n> git+ssh:// and git+http://\n\nHow is a discussion about changing the scheme name relevant to a  \ndiscussion about treating a URL with an explicit default port the same  \nas one without (which Git already does but stops doing with the 0010  \ngit SRV patch)?  That would seem to be an orthogonal discussion to  \nwhether or not to change the scheme name(s) used by Git more than 9  \nyears after it first came out.\n"},{"id":"246351","messageId":"20140719001908.GX12427@google.com","threadId":"37152","inReplyTo":"DC1EBA8C-1443-42DA-BA96-CB38D13502ED@gmail.com","subject":"Re: git_inetd_server: run git-http-backend using inetd","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2014-07-19T00:19:08Z","receivedAt":"2014-07-19T00:19:08Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Kyle J. McKay wrote:\n> On Jul 18, 2014, at 10:16, Jonathan Nieder wrote:\n>> Kyle J. McKay wrote:\n\n>>> You might also want to take a look at [1] which suggests that when\n>>> doing SRV lookups for URLs they should be done regardless of whether\n>>> or not a port number is present (which then eliminates the RFC 3986\n>>> issue the current SRV lookup code has).\n>>\n>> \"Git URLs\" as described e.g. in git-clone(1) weren't intended to be\n>> actual URIs.\n>\n> According to RFC 3968 section 1.1.3:\n> \"A URI can be further classified as a locator, a name, or both. The\n> term \"Uniform Resource Locator\" (URL) refers to the subset of URIs\"\n> [...]\n>\n> So actually they are URIs.\n\nYou mean abusing the word URL when we meant URL-shaped thing makes it\ninto a URL?\n\n>> What would be the interoperability advantage of making\n>> them URIs?\n>\n> According to RFC 3968 they are already considered URIs.\n\nI don't think you understood my question.\n\n>> This has come up before, with e.g. people asking to introduce a\n>> git+ssh:// and git+http://\n>\n> How is a discussion about changing the scheme name relevant to a\n> discussion about treating a URL with an explicit default port the\n> same as one without (which Git already does but stops doing with the\n> 0010 git SRV patch)?\n\nIt's where the question of whether the things you pass to 'git clone'\nare URIs came up before.\n\nI don't understand what you want in this side-conversation.  Do you\nmean that I should read that RFC and be convinced that what you are\nsaying about ports is the right thing to do?  I can easily be\nconvinced some other way, but \"It's in a standard that you never\nintended to follow\" is not particularly convincing or relevant.\n\nThe same philosophy as the git project applies to POSIX conformance\nissues applies here, too.  We live in the real world.\n\nHoping that clarifies,\nJonathan\n"},{"id":"246352","messageId":"1A68D760-F69C-4DBE-AEAC-6672626A9515@gmail.com","threadId":"37152","inReplyTo":"20140719001908.GX12427@google.com","subject":"Re: git_inetd_server: run git-http-backend using inetd","fromName":"Kyle J. McKay","fromEmail":"mackyle@gmail.com","sentAt":"2014-07-19T01:54:08Z","receivedAt":"2014-07-19T01:54:08Z","isPatch":false,"sender":{"key":"mackyle@gmail.com","avatar":"https://avatars.githubusercontent.com/u/813346?v=4"},"body":"On Jul 18, 2014, at 17:19, Jonathan Nieder wrote:\n\n> Kyle J. McKay wrote:\n>> On Jul 18, 2014, at 10:16, Jonathan Nieder wrote:\n>>>\n>>> \"Git URLs\" as described e.g. in git-clone(1) weren't intended to be\n>>> actual URIs.\n>>\n>> According to RFC 3968 section 1.1.3:\n>> \"A URI can be further classified as a locator, a name, or both. The\n>> term \"Uniform Resource Locator\" (URL) refers to the subset of URIs\"\n>> [...]\n>>\n>> So actually they are URIs.\n>\n> You mean abusing the word URL when we meant URL-shaped thing makes it\n> into a URL?\n\nThat is your contention.\n\n> Do you\n> mean that I should read that RFC and be convinced that what you are\n> saying about ports is the right thing to do?\n\nIt's the right thing to do because it's the standard for how URLs are  \nexpected to behave.\n\n> \"It's in a standard that you never\n> intended to follow\" is not particularly convincing or relevant.\n\nThat is your contention.  If it is truly the case that where the Git  \ndocumentation uses the \"URL\" acronym that Git does not actually intend  \nfor \"URL\" to be interpreted as a \"URL\" as defined by the various  \nstandards covering such URLs then explicit text needs to be added to  \nthe documentation saying so to avoid confusion.  In the absence of  \nsuch text, expecting a reader of Git documentation to interpret the  \nterm \"URL\" any other way is irrational.\n"},{"id":"246358","messageId":"53CA0E59.5030103@web.de","threadId":"37152","inReplyTo":"20140717221056.GO12427@google.com","subject":"Re: git_inetd_server: run git-http-backend using inetd","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2014-07-19T06:21:13Z","receivedAt":"2014-07-19T06:21:13Z","isPatch":false,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"On 07/18/2014 12:10 AM, Jonathan Nieder wrote:\n> Hi,\n>\n> Kyle J. McKay wrote:\n>\n>> When I then try to fetch using a \"git://host/...\" URL where \"host\"\n>> is an mDNS host name, the 0010 patch causes git to attempt to lookup\n>> a DNS SRV record on the non-mDNS regular DNS service (a violation of\n>> RFC 6762 [4] section 22) and this is what has to time out before the\n>> real fetch can start.\n> That patch uses res_query from libresolv to do the lookup.  It doesn't\n> know what DNS server to use and relies on system libraries to get it\n> right.\n>\n> It was added to respond to a feature request within Debian but it is\n> intended to eventually go upstream.  I'm glad you found this issue\n> before that could happen. :)\n>\n> Should git automatically disable the SRV lookups when it sees one of\n> the six domains named in RFC6762, or is there some system library call\n> that can use mDNS when appropriate automatically (or get partway there\n> without having to hard-code the domains)?\n>\n> Thanks,\n> Jonathan\n(My apologies, if this is spamish), but just to verify what is going on:\n\ngit fetch git://host.local/...\nresults in a DNS lookup ?\n\nKyle, did you verify the lookup with wireshark or a similar tool?\n\nJonathan, (I'm good in searching, but bad in finding)\ncould you point out where the source code for the git package for\ndebian is ?\n\nI recently learned about mDNS, and will probably do some tests\nand experiments later, and would like to test the lookup feature\nof \"0010\".\n\nThanks.\n/Torsten\n"},{"id":"246387","messageId":"20140719170623.GA29072@google.com","threadId":"37152","inReplyTo":"53CA0E59.5030103@web.de","subject":"Re: git_inetd_server: run git-http-backend using inetd","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2014-07-19T17:06:23Z","receivedAt":"2014-07-19T17:06:23Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Torsten Bögershausen wrote:\n\n> Jonathan, (I'm good in searching, but bad in finding)\n> could you point out where the source code for the git package for\n> debian is ?\n>\n> I recently learned about mDNS, and will probably do some tests\n> and experiments later, and would like to test the lookup feature\n> of \"0010\".\n\nThanks.  It's at git://git.debian.org/~jrnieder-guest/git branch\nrelease+patches and mirrored at http://repo.or.cz/r/git/debian\n"},{"id":"246400","messageId":"53CB5D64.9060801@web.de","threadId":"37152","inReplyTo":"20140719170623.GA29072@google.com","subject":"Re: git_inetd_server: run git-http-backend using inetd","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2014-07-20T06:10:44Z","receivedAt":"2014-07-20T06:10:44Z","isPatch":false,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"On 07/19/2014 07:06 PM, Jonathan Nieder wrote:\n> Torsten Bögershausen wrote:\n>\n>> Jonathan, (I'm good in searching, but bad in finding)\n>> could you point out where the source code for the git package for\n>> debian is ?\n>>\n>> I recently learned about mDNS, and will probably do some tests\n>> and experiments later, and would like to test the lookup feature\n>> of \"0010\".\n> Thanks.  It's at git://git.debian.org/~jrnieder-guest/git branch\n> release+patches and mirrored at http://repo.or.cz/r/git/debian\nWith my limited reading of the RFC and the code, and without having\ntest environment, my spontanous (and probably incomplete) change could \nlook like this:\n- Treat \"host:9418\" the same as \"host\"\n- When the hosts ends with .local, do not use DNS.\n\nstatic int git_tcp_connect_sock(char *host, int flags)\n{\n     struct strbuf error_message = STRBUF_INIT;\n     int sockfd = -1, gai = 0;\n     const char *port = NULL;\n     struct host *hosts = NULL;\n     int j, n = 0;\n\n     get_host_and_port(&host, &port);\n     if (!port)\n         port = STR(DEFAULT_GIT_PORT);\n\n     n = get_srv(host, &hosts);\n     if ((n <= 0) && ends_with(host, \".local\")) {\n         /*\n           host.local is really local, do not send it to a DNS resolver\n           The user may try host without .local\n          */\n         die(\"Unable to look up %s\", host);\n     }\n     if (!n) {\n         hosts = xmalloc(sizeof(*hosts));\n         hosts[0].hostname = xstrdup(host);\n         hosts[0].port = xstrdup(port);\n[snip]\n"},{"id":"246418","messageId":"53CBDF7A.5040509@web.de","threadId":"37152","inReplyTo":"53CB5D64.9060801@web.de","subject":"Re: git_inetd_server: run git-http-backend using inetd","fromName":"Torsten Bögershausen","fromEmail":"tboegi@web.de","sentAt":"2014-07-20T15:25:46Z","receivedAt":"2014-07-20T15:25:46Z","isPatch":false,"sender":{"key":"tboegi@web.de","avatar":"https://avatars.githubusercontent.com/u/7138363?v=4"},"body":"On 07/20/2014 08:10 AM, Torsten Bögershausen wrote:\n> On 07/19/2014 07:06 PM, Jonathan Nieder wrote:\n>> Torsten Bögershausen wrote:\n>>\n>>> Jonathan, (I'm good in searching, but bad in finding)\n>>> could you point out where the source code for the git package for\n>>> debian is ?\n>>>\n>>> I recently learned about mDNS, and will probably do some tests\n>>> and experiments later, and would like to test the lookup feature\n>>> of \"0010\".\n>> Thanks.  It's at git://git.debian.org/~jrnieder-guest/git branch\n>> release+patches and mirrored at http://repo.or.cz/r/git/debian\nI probably need to correct myself:\nDonwloaded your branch, compiled and tested.\nOn my test system the lookup timed out after 1.9 sec for DNS,\nand 5 seconds for MDNS (the lookup failed in both cases)\n\nI'm not sure any more how to improve things here, and\nthe question remains why Kyle has 15 seconds timeout ?\n\nWould it be possible to run wireshark, and give us an example\nof the URL's you have been using ?\n"}]}