From: Konstantin Khomoutov <kostix+git@007spb.ru>
To: Florian Manschwetus <manschwetus@cs-software-gmbh.de>
Cc: "git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: Problem with git-http-backend.exe as iis cgi
Date: Thu, 10 Mar 2016 15:55:22 +0300 [thread overview]
Message-ID: <20160310155522.1dee53cf95fead8cfd4e178a@domain007.com> (raw)
In-Reply-To: <F0F5A56A22F20D4CB4A03BB8D6658797E260E0E3@SERVER2011.CS-SOFTWARE.local>
On Thu, 10 Mar 2016 07:28:50 +0000
Florian Manschwetus <manschwetus@cs-software-gmbh.de> 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
next prev parent reply other threads:[~2016-06-20 10:07 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-10 7:28 Problem with git-http-backend.exe as iis cgi Florian Manschwetus
2016-03-10 12:55 ` Konstantin Khomoutov [this message]
2016-03-29 6:01 ` AW: " Florian Manschwetus
2016-03-29 9:28 ` Chris Packham
2016-06-21 16:46 ` Junio C Hamano
2016-06-22 6:49 ` Johannes Schindelin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160310155522.1dee53cf95fead8cfd4e178a@domain007.com \
--to=kostix+git@007spb.ru \
--cc=git@vger.kernel.org \
--cc=manschwetus@cs-software-gmbh.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.