Jeff King [off-list ref] writes:
The rollout would be:
1. add contrib/mongoose/*
2. add test-httpd which links against mongoose, built by default in the
Makefile
3. convert lib-httpd/apache.conf into mongoose config as necessary
4. convert lib-httpd.sh to run test-httpd instead of LIB_HTTPD_PATH
5. delete apache.conf, LIB_HTTPD_PATH and any other apache remnants
6. default GIT_TEST_HTTPD to yes
Step 3 is the part where I would anticipate trouble (i.e., finding out
that the new server does not do everything the tests expect).
If it involves making things not tested with apache, I'd actually be
less supportive for the whole plan. I thought the primary objective
was to encourage people who currently are _not_ running httpd tests
by making a lightweight server available out of the box, robbing an
excuse "my box does not have apache installed" from them.
As long as a server supports bog standard CGI interface, smart-http
should work the same way with any such server. For that reason, it
should be theoretically sufficient to test with one non-apache
server (i.e. mongoose) for the purpose of making sure _our_ end of
the set-up works, but still...
On Wed, Dec 04, 2013 at 02:53:13PM -0800, Junio C Hamano wrote:
If it involves making things not tested with apache, I'd actually be
less supportive for the whole plan.
I hadn't really considered that angle. Apache is a much more realistic
real-world deployment. We give advice for it in git-http-backend(1), and
the tests do check that that advice works (OTOH, we also give advice for
lighttpd, but that is not checked in the test scripts).
I thought the primary objective was to encourage people who currently
are _not_ running httpd tests by making a lightweight server available
out of the box, robbing an excuse "my box does not have apache
installed" from them.
Whether we get rid of apache or not, I think a new lightweight server
would fulfill that goal. I just did not want the maintenance burden of
managing multiple configs (and our test harness apache config has grown
non-trivial).
As long as a server supports bog standard CGI interface, smart-http
should work the same way with any such server. For that reason, it
should be theoretically sufficient to test with one non-apache
server (i.e. mongoose) for the purpose of making sure _our_ end of
the set-up works, but still...
There are definitely subtleties between servers. For example, when I
worked on fetching bundles over http a while back, there was a big
difference between lighttpd and apache. A request for
"http://example.com/foo.bundle/info/refs" would return the bundle under
lighttpd, but not under apache (for an apache server, we would have to
make a fallback request). The client needs to be able to handle both
scenarios gracefully.
That's a case where it would be nice to be able to test _both_ cases,
and that may be an argument for having multiple (or trying to configure
apache to do both behaviors). But it shows that there may be subtle
differences between a fake test server and a real deployment.
So thinking on it more, I'm somewhat less enthusiastic about mongoose.
-Peff