Hi Florian On Tue, Mar 29, 2016 at 7:01 PM, Florian Manschwetus <manschwetus@xxxxxxxxxxxxxxxxxxx> wrote: > Hi, > I put together a first patch for the issue. > > Mit freundlichen Grüßen / With kind regards > Florian Manschwetus > > E-Mail: manschwetus@xxxxxxxxxxxxxxxxxxx > Tel.: +49-(0)611-8908534 > > CS Software Concepts and Solutions GmbH > Geschäftsführer / Managing director: Dr. Werner Alexi > Amtsgericht Wiesbaden HRB 10004 (Commercial registry) > Schiersteiner Straße 31 > D-65187 Wiesbaden > Germany > Tel.: 0611/8908555 > > > -----Ursprüngliche Nachricht----- > Von: Konstantin Khomoutov [mailto:kostix+git@xxxxxxxxx] > Gesendet: Donnerstag, 10. März 2016 13:55 > An: Florian Manschwetus > Cc: git@xxxxxxxxxxxxxxx > Betreff: Re: Problem with git-http-backend.exe as iis cgi > > On Thu, 10 Mar 2016 07:28:50 +0000 > Florian Manschwetus <manschwetus@xxxxxxxxxxxxxxxxxxx> wrote: > >> I tried to setup git-http-backend with iis, as iis provides proper >> impersonation for cgi under windows, which leads to have the >> filesystem access performed with the logon user, therefore the >> webserver doesn't need generic access to the files. I stumbled across >> a problem, ending up with post requests hanging forever. After some >> investigation I managed to get it work by wrapping the http-backend >> into a bash script, giving a lot of control about the environmental >> things, I was unable to solve within IIS configuration. The >> workaround, I use currently, is to use "/bin/head -c ${CONTENT_LENGTH} >> | ./git-http-backend.exe", which directly shows the issue. Git >> http-backend should check if CONTENT_LENGTH is set to something >> reasonable (e.g. >0) and should in this case read only CONTENT_LENGTH >> bytes from stdin, instead of reading till EOF what I suspect it is >> doing currently. > > The rfc [1] states in its section 4.2: > > | A request-body is supplied with the request if the CONTENT_LENGTH is > | not NULL. The server MUST make at least that many bytes available for > | the script to read. The server MAY signal an end-of-file condition > | after CONTENT_LENGTH bytes have been read or it MAY supply extension > | data. Therefore, the script MUST NOT attempt to read more than > | CONTENT_LENGTH bytes, even if more data is available. However, it is > | not obliged to read any of the data. > > So yes, if Git currently reads until EOF, it's an error. > The correct way would be: > > 1) Check to see if the CONTENT_LENGTH variable is available in the > environment. If no, read nothing. > > 2) Otherwise read as many bytes it specifies, and no more. > > 1. https://www.ietf.org/rfc/rfc3875 Your patch description seems well thought out but if you want someone to notice it you should have a read of https://git.kernel.org/cgit/git/git.git/tree/Documentation/SubmittingPatches -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html