Use mongoose to test smart-http unconditionally?

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..

[1] https://github.com/cesanta/mongoose
-- 
Duy

On Wed, Dec 4, 2013 at 2:53 AM, Duy Nguyen [off-list ref] 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.

[1] https://github.com/cesanta/mongoose

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

On Wed, Dec 4, 2013 at 2:53 AM, Duy Nguyen [off-list ref] wrote:

quoted

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

Jeff King wrote:

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

Yup, that's why I don't run them.

For what it's worth, when I build git and run tests I tend to be in an
environment with apache available, but I'm too lazy to configure git's
tests to pick the right port and make sure it is reserved and so on.
Perhaps there's some way to help lazy people in the same boat?  (E.g.,
picking a port randomly and skipping instead of failing a test when
it's taken or something)

On Thu, Dec 5, 2013 at 6:28 AM, Jonathan Nieder [off-list ref] wrote:

Jeff King wrote:

quoted

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

Yup, that's why I don't run them.

For what it's worth, when I build git and run tests I tend to be in an
environment with apache available, but I'm too lazy to configure git's
tests to pick the right port and make sure it is reserved and so on.
Perhaps there's some way to help lazy people in the same boat?  (E.g.,
picking a port randomly and skipping instead of failing a test when
it's taken or something)

Sounds like good first steps.
-- 
Duy

On Wed, Dec 04, 2013 at 03:28:00PM -0800, Jonathan Nieder wrote:

For what it's worth, when I build git and run tests I tend to be in an
environment with apache available, but I'm too lazy to configure git's
tests to pick the right port and make sure it is reserved and so on.
Perhaps there's some way to help lazy people in the same boat?  (E.g.,
picking a port randomly and skipping instead of failing a test when
it's taken or something)

What level of magic do you need?

For most people, "apt-get install apache && make GIT_TEST_HTTPD=yes
test" is enough to run the tests. It uses ports in the 5000-range; this
_can_ conflict with other services the user is running, but it should
not usually (we don't match anything in a typical /etc/services file).
And each script uses its own port, so running the tests in parallel is
fine.

If you are planning on running "make test" from multiple git checkouts
at the same time, though, they will conflict.

The failure mode is reasonable. You should get something like:

  $ GIT_TEST_HTTPD=1 LIB_HTTPD_PORT=80 ./t5540-http-push.sh
  1..0 # SKIP skipping test, web server setup failed

We could do better by retrying with a range of ports, but unless
somebody really needs that, I'd prefer to avoid complicating it more.

The one thing I have occasionally run into is a stale apache hanging
around. But I think that only happens when I am abusing the test script
(e.g., sticking a test_pause in, poking around, and then not letting the
script complete and do its cleanup).

So is the current behavior good enough to meet your needs and you
didn't know it, or do we need more?

-Peff