Re: Use mongoose to test smart-http unconditionally?

From: Jeff King <peff@peff.net>
Date: Dec 4, 2013, 18:48 UTC
Message-ID: <20131204184842.GA11024@sigill.intra.peff.net>
In-Reply-To: <CAJo=hJuzP=zYsEZvC5ugKaAWPLAcTzmFJxT5PNFKbBEv0ctnDw@mail.gmail.com>

On Wed, Dec 04, 2013 at 10:13:11AM -0800, Shawn Pearce wrote:

Show 14 quoted lines

> On Wed, Dec 4, 2013 at 2:53 AM, Duy Nguyen <pclouds@gmail.com> wrote:
> > I was thinking of an alternative to apache for testing smart-http so
> > that most of http tests could always run. Mongoose [1] looks like a
> > good candidate to bundle with git. Just one pair of source files,
> > mongoose.[ch], a mainloop wrapper and we have an http server. Just
> > wondering, do we rely on any apache-specific features? I'm not so
> > familiar with lib-httpd.sh..
> 
> I don't think we do anything Apache specific in the test suite. It
> basically relies on CGI execution, being able to configure a URL to
> serve a directory, and making some URLs 404 or 500 so we can emulate a
> broken or failing server to test the client behavior in those
> conditions. At worst that 404/500 forced failure mode could be handled
> by a CGI.

I don't think there's anything apache specific, but there's a fair bit of config for handling various auth scenarios. It's stuff I'd expect any decent server implementation to handle, but somebody actually needs to go through and translate all of the config to mongoose.

I've been tempted to add lighttpd support, as I generally find its config much more readable (and less prone to breaking during upgrades). But I think it would be a mistake to support multiple servers, as it would mean updates to the tests need to hit all of the servers. If mongoose gives a sane lowest common denominator, that's fine with me.

I don't know if it is worth all that much effort, though. I suppose it could get us more exposure to the httpd tests, but I do not know if it would be a good idea to turn them on by default anyway. They touch global machine resources (like ports) that can cause conflicts or test failures. I assume that is the reason we do not turn on git-daemon tests by default (though perhaps it would be better in both cases to have it on by default and let people with special needs, like running multiple test instances at once, turn it off).

-Peff