From: Jeff King <peff@peff.net>
To: Shawn Pearce <spearce@spearce.org>
Cc: Duy Nguyen <pclouds@gmail.com>, Git Mailing List <git@vger.kernel.org>
Subject: Re: Use mongoose to test smart-http unconditionally?
Date: Wed, 4 Dec 2013 13:48:42 -0500 [thread overview]
Message-ID: <20131204184842.GA11024@sigill.intra.peff.net> (raw)
In-Reply-To: <CAJo=hJuzP=zYsEZvC5ugKaAWPLAcTzmFJxT5PNFKbBEv0ctnDw@mail.gmail.com>
On Wed, Dec 04, 2013 at 10:13:11AM -0800, Shawn Pearce wrote:
> 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
next prev parent reply other threads:[~2013-12-04 18:48 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-04 10:53 Use mongoose to test smart-http unconditionally? Duy Nguyen
2013-12-04 18:13 ` Shawn Pearce
2013-12-04 18:48 ` Jeff King [this message]
2013-12-04 23:28 ` Jonathan Nieder
2013-12-05 0:18 ` Duy Nguyen
2013-12-05 3:00 ` Jeff King
2013-12-04 20:09 ` Junio C Hamano
2013-12-04 22:25 ` Jeff King
2013-12-04 22:53 ` Junio C Hamano
2013-12-05 2:49 ` Jeff King
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=20131204184842.GA11024@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=pclouds@gmail.com \
--cc=spearce@spearce.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).