{"thread":{"id":"35474","subject":"Use mongoose to test smart-http unconditionally?","startedAt":"2013-12-04T10:53:09Z","lastAt":"2013-12-05T03:00:15Z","messageCount":10,"participants":["Duy Nguyen","Shawn Pearce","Jeff King","Junio C Hamano","Jonathan Nieder"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"231500","messageId":"CACsJy8BHnTHRugJoTDGs7h=dF1qQUWyPXYxCU8YsDU57s+5gyg@mail.gmail.com","threadId":"35474","inReplyTo":null,"subject":"Use mongoose to test smart-http unconditionally?","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2013-12-04T10:53:09Z","receivedAt":"2013-12-04T10:53:09Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"I was thinking of an alternative to apache for testing smart-http so\nthat most of http tests could always run. Mongoose [1] looks like a\ngood candidate to bundle with git. Just one pair of source files,\nmongoose.[ch], a mainloop wrapper and we have an http server. Just\nwondering, do we rely on any apache-specific features? I'm not so\nfamiliar with lib-httpd.sh..\n\n[1] https://github.com/cesanta/mongoose\n-- \nDuy\n"},{"id":"231529","messageId":"CAJo=hJuzP=zYsEZvC5ugKaAWPLAcTzmFJxT5PNFKbBEv0ctnDw@mail.gmail.com","threadId":"35474","inReplyTo":"CACsJy8BHnTHRugJoTDGs7h=dF1qQUWyPXYxCU8YsDU57s+5gyg@mail.gmail.com","subject":"Re: Use mongoose to test smart-http unconditionally?","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2013-12-04T18:13:11Z","receivedAt":"2013-12-04T18:13:11Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"On Wed, Dec 4, 2013 at 2:53 AM, Duy Nguyen wrote:\n> I was thinking of an alternative to apache for testing smart-http so\n> that most of http tests could always run. Mongoose [1] looks like a\n> good candidate to bundle with git. Just one pair of source files,\n> mongoose.[ch], a mainloop wrapper and we have an http server. Just\n> wondering, do we rely on any apache-specific features? I'm not so\n> familiar with lib-httpd.sh..\n\nI don't think we do anything Apache specific in the test suite. It\nbasically relies on CGI execution, being able to configure a URL to\nserve a directory, and making some URLs 404 or 500 so we can emulate a\nbroken or failing server to test the client behavior in those\nconditions. At worst that 404/500 forced failure mode could be handled\nby a CGI.\n\n> [1] https://github.com/cesanta/mongoose\n"},{"id":"231530","messageId":"20131204184842.GA11024@sigill.intra.peff.net","threadId":"35474","inReplyTo":"CAJo=hJuzP=zYsEZvC5ugKaAWPLAcTzmFJxT5PNFKbBEv0ctnDw@mail.gmail.com","subject":"Re: Use mongoose to test smart-http unconditionally?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-12-04T18:48:42Z","receivedAt":"2013-12-04T18:48:42Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Dec 04, 2013 at 10:13:11AM -0800, Shawn Pearce wrote:\n\n> On Wed, Dec 4, 2013 at 2:53 AM, Duy Nguyen wrote:\n> > I was thinking of an alternative to apache for testing smart-http so\n> > that most of http tests could always run. Mongoose [1] looks like a\n> > good candidate to bundle with git. Just one pair of source files,\n> > mongoose.[ch], a mainloop wrapper and we have an http server. Just\n> > wondering, do we rely on any apache-specific features? I'm not so\n> > familiar with lib-httpd.sh..\n> \n> I don't think we do anything Apache specific in the test suite. It\n> basically relies on CGI execution, being able to configure a URL to\n> serve a directory, and making some URLs 404 or 500 so we can emulate a\n> broken or failing server to test the client behavior in those\n> conditions. At worst that 404/500 forced failure mode could be handled\n> by a CGI.\n\nI don't think there's anything apache specific, but there's a fair bit\nof config for handling various auth scenarios. It's stuff I'd expect any\ndecent server implementation to handle, but somebody actually needs to\ngo through and translate all of the config to mongoose.\n\nI've been tempted to add lighttpd support, as I generally find its\nconfig much more readable (and less prone to breaking during upgrades).\nBut I think it would be a mistake to support multiple servers, as it\nwould mean updates to the tests need to hit all of the servers. If\nmongoose gives a sane lowest common denominator, that's fine with me.\n\nI don't know if it is worth all that much effort, though. I suppose it\ncould get us more exposure to the httpd tests, but I do not know if it\nwould be a good idea to turn them on by default anyway. They touch\nglobal machine resources (like ports) that can cause conflicts or test\nfailures. I assume that is the reason we do not turn on git-daemon tests\nby default (though perhaps it would be better in both cases to have it\non by default and let people with special needs, like running multiple\ntest instances at once, turn it off).\n\n-Peff\n"},{"id":"231536","messageId":"xmqqa9ggl6oq.fsf@gitster.dls.corp.google.com","threadId":"35474","inReplyTo":"CACsJy8BHnTHRugJoTDGs7h=dF1qQUWyPXYxCU8YsDU57s+5gyg@mail.gmail.com","subject":"Re: Use mongoose to test smart-http unconditionally?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-12-04T20:09:09Z","receivedAt":"2013-12-04T20:09:09Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Duy Nguyen writes:\n\n> I was thinking of an alternative to apache for testing smart-http\n> so that most of http tests could always run. Mongoose [1] looks\n> like a good candidate to bundle with git. Just one pair of source\n> files, mongoose.[ch], a mainloop wrapper and we have an http\n> server.\n\nHmmmm. How would the high-level integration look like?\n\n - we add contrib/mongoose/*;\n\n - in t/Makefile, we:\n\n . set GIT_TEST_HTTPD to yes, unless it is already set to another value;\n\n . set LIB_HTTPD_PATH to $GIT_BUILD_DIR/contrib/mongoose/mongoose,\n unless it is already set to another value;\n\n . if LIB_HTTPD_PATH is set to our mongoose and if it hasn't been\n built, go ../contrib/mongoose and build it.\n\n - we teach lib-httpd.sh to trigger the DEFAULT_HTTPD_PATH\n computation when LIB_HTTPD_PATH is set to 'system-apache', so\n that people can test with their installed apache if they choose\n to; and\n\n - we teach lib-httpd.sh to write out an appropriate configuration\n for the mongoose server.\n\nThat would force people to run http tests by turning it from an\nopt-in option to an opt-out option.\n\nOr were you thinking about embedding mongoose in the git executable?\n"},{"id":"231550","messageId":"20131204222522.GA16706@sigill.intra.peff.net","threadId":"35474","inReplyTo":"xmqqa9ggl6oq.fsf@gitster.dls.corp.google.com","subject":"Re: Use mongoose to test smart-http unconditionally?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-12-04T22:25:22Z","receivedAt":"2013-12-04T22:25:22Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Dec 04, 2013 at 12:09:09PM -0800, Junio C Hamano wrote:\n\n> Duy Nguyen writes:\n> \n> > I was thinking of an alternative to apache for testing smart-http\n> > so that most of http tests could always run. Mongoose [1] looks\n> > like a good candidate to bundle with git. Just one pair of source\n> > files, mongoose.[ch], a mainloop wrapper and we have an http\n> > server.\n> \n> Hmmmm. How would the high-level integration look like?\n> \n> - we add contrib/mongoose/*;\n> \n> - in t/Makefile, we:\n> \n> . set GIT_TEST_HTTPD to yes, unless it is already set to another value;\n> \n> . set LIB_HTTPD_PATH to $GIT_BUILD_DIR/contrib/mongoose/mongoose,\n> unless it is already set to another value;\n> \n> . if LIB_HTTPD_PATH is set to our mongoose and if it hasn't been\n> built, go ../contrib/mongoose and build it.\n\nI think building it on-demand is probably too much effort. If it is\nportable, then it should not be a problem to just build it along with\nthe rest of git. If it is not, then we should rethink whether it is\nworth including.\n\n> - we teach lib-httpd.sh to trigger the DEFAULT_HTTPD_PATH\n> computation when LIB_HTTPD_PATH is set to 'system-apache', so\n> that people can test with their installed apache if they choose\n> to; and\n\nI do not think we want to allow run-time switching between an embedded\nsolution and apache. That would mean that we have to keep two sets of\nhttp-server config in sync.\n\n> Or were you thinking about embedding mongoose in the git executable?\n\nI don't think it makes sense to embed it in git, but it could easily be\ntest-httpd.\n\nThe rollout would be:\n\n 1. add contrib/mongoose/*\n\n 2. add test-httpd which links against mongoose, built by default in the\n Makefile\n\n 3. convert lib-httpd/apache.conf into mongoose config as necessary\n\n 4. convert lib-httpd.sh to run test-httpd instead of LIB_HTTPD_PATH\n\n 5. delete apache.conf, LIB_HTTPD_PATH and any other apache remnants\n\n 6. default GIT_TEST_HTTPD to yes\n\nStep 3 is the part where I would anticipate trouble (i.e., finding out\nthat the new server does not do everything the tests expect).\n\n-Peff\n"},{"id":"231554","messageId":"xmqq38m8jkiu.fsf@gitster.dls.corp.google.com","threadId":"35474","inReplyTo":"20131204222522.GA16706@sigill.intra.peff.net","subject":"Re: Use mongoose to test smart-http unconditionally?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-12-04T22:53:13Z","receivedAt":"2013-12-04T22:53:13Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> The rollout would be:\n>\n> 1. add contrib/mongoose/*\n>\n> 2. add test-httpd which links against mongoose, built by default in the\n> Makefile\n>\n> 3. convert lib-httpd/apache.conf into mongoose config as necessary\n>\n> 4. convert lib-httpd.sh to run test-httpd instead of LIB_HTTPD_PATH\n>\n> 5. delete apache.conf, LIB_HTTPD_PATH and any other apache remnants\n>\n> 6. default GIT_TEST_HTTPD to yes\n>\n> Step 3 is the part where I would anticipate trouble (i.e., finding out\n> that the new server does not do everything the tests expect).\n\nIf it involves making things not tested with apache, I'd actually be\nless supportive for the whole plan. I thought the primary objective\nwas to encourage people who currently are _not_ running httpd tests\nby making a lightweight server available out of the box, robbing an\nexcuse \"my box does not have apache installed\" from them.\n\nAs long as a server supports bog standard CGI interface, smart-http\nshould work the same way with any such server. For that reason, it\nshould be theoretically sufficient to test with one non-apache\nserver (i.e. mongoose) for the purpose of making sure _our_ end of\nthe set-up works, but still...\n"},{"id":"231557","messageId":"20131204232800.GG29959@google.com","threadId":"35474","inReplyTo":"20131204184842.GA11024@sigill.intra.peff.net","subject":"Re: Use mongoose to test smart-http unconditionally?","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-12-04T23:28:00Z","receivedAt":"2013-12-04T23:28:00Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Jeff King wrote:\n\n> I don't know if it is worth all that much effort, though. I suppose it\n> could get us more exposure to the httpd tests, but I do not know if it\n> would be a good idea to turn them on by default anyway. They touch\n> global machine resources (like ports) that can cause conflicts or test\n> failures. I assume that is the reason we do not turn on git-daemon tests\n> by default\n\nYup, that's why I don't run them.\n\nFor what it's worth, when I build git and run tests I tend to be in an\nenvironment with apache available, but I'm too lazy to configure git's\ntests to pick the right port and make sure it is reserved and so on.\nPerhaps there's some way to help lazy people in the same boat? (E.g.,\npicking a port randomly and skipping instead of failing a test when\nit's taken or something)\n"},{"id":"231559","messageId":"CACsJy8Aj_RLUteevuHDzFRTHZgkWjSTb669ZiZV5fLPP6dYf1Q@mail.gmail.com","threadId":"35474","inReplyTo":"20131204232800.GG29959@google.com","subject":"Re: Use mongoose to test smart-http unconditionally?","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2013-12-05T00:18:41Z","receivedAt":"2013-12-05T00:18:41Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Thu, Dec 5, 2013 at 6:28 AM, Jonathan Nieder wrote:\n> Jeff King wrote:\n>\n>> I don't know if it is worth all that much effort, though. I suppose it\n>> could get us more exposure to the httpd tests, but I do not know if it\n>> would be a good idea to turn them on by default anyway. They touch\n>> global machine resources (like ports) that can cause conflicts or test\n>> failures. I assume that is the reason we do not turn on git-daemon tests\n>> by default\n>\n> Yup, that's why I don't run them.\n>\n> For what it's worth, when I build git and run tests I tend to be in an\n> environment with apache available, but I'm too lazy to configure git's\n> tests to pick the right port and make sure it is reserved and so on.\n> Perhaps there's some way to help lazy people in the same boat? (E.g.,\n> picking a port randomly and skipping instead of failing a test when\n> it's taken or something)\n\nSounds like good first steps.\n-- \nDuy\n"},{"id":"231567","messageId":"20131205024938.GA19376@sigill.intra.peff.net","threadId":"35474","inReplyTo":"xmqq38m8jkiu.fsf@gitster.dls.corp.google.com","subject":"Re: Use mongoose to test smart-http unconditionally?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-12-05T02:49:38Z","receivedAt":"2013-12-05T02:49:38Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Dec 04, 2013 at 02:53:13PM -0800, Junio C Hamano wrote:\n\n> If it involves making things not tested with apache, I'd actually be\n> less supportive for the whole plan.\n\nI hadn't really considered that angle. Apache is a much more realistic\nreal-world deployment. We give advice for it in git-http-backend(1), and\nthe tests do check that that advice works (OTOH, we also give advice for\nlighttpd, but that is not checked in the test scripts).\n\n> I thought the primary objective was to encourage people who currently\n> are _not_ running httpd tests by making a lightweight server available\n> out of the box, robbing an excuse \"my box does not have apache\n> installed\" from them.\n\nWhether we get rid of apache or not, I think a new lightweight server\nwould fulfill that goal. I just did not want the maintenance burden of\nmanaging multiple configs (and our test harness apache config has grown\nnon-trivial).\n\n> As long as a server supports bog standard CGI interface, smart-http\n> should work the same way with any such server. For that reason, it\n> should be theoretically sufficient to test with one non-apache\n> server (i.e. mongoose) for the purpose of making sure _our_ end of\n> the set-up works, but still...\n\nThere are definitely subtleties between servers. For example, when I\nworked on fetching bundles over http a while back, there was a big\ndifference between lighttpd and apache. A request for\n\"http://example.com/foo.bundle/info/refs\" would return the bundle under\nlighttpd, but not under apache (for an apache server, we would have to\nmake a fallback request). The client needs to be able to handle both\nscenarios gracefully.\n\nThat's a case where it would be nice to be able to test _both_ cases,\nand that may be an argument for having multiple (or trying to configure\napache to do both behaviors). But it shows that there may be subtle\ndifferences between a fake test server and a real deployment.\n\nSo thinking on it more, I'm somewhat less enthusiastic about mongoose.\n\n-Peff\n"},{"id":"231569","messageId":"20131205030015.GB19376@sigill.intra.peff.net","threadId":"35474","inReplyTo":"20131204232800.GG29959@google.com","subject":"Re: Use mongoose to test smart-http unconditionally?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-12-05T03:00:15Z","receivedAt":"2013-12-05T03:00:15Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Dec 04, 2013 at 03:28:00PM -0800, Jonathan Nieder wrote:\n\n> For what it's worth, when I build git and run tests I tend to be in an\n> environment with apache available, but I'm too lazy to configure git's\n> tests to pick the right port and make sure it is reserved and so on.\n> Perhaps there's some way to help lazy people in the same boat? (E.g.,\n> picking a port randomly and skipping instead of failing a test when\n> it's taken or something)\n\nWhat level of magic do you need?\n\nFor most people, \"apt-get install apache && make GIT_TEST_HTTPD=yes\ntest\" is enough to run the tests. It uses ports in the 5000-range; this\n_can_ conflict with other services the user is running, but it should\nnot usually (we don't match anything in a typical /etc/services file).\nAnd each script uses its own port, so running the tests in parallel is\nfine.\n\nIf you are planning on running \"make test\" from multiple git checkouts\nat the same time, though, they will conflict.\n\nThe failure mode is reasonable. You should get something like:\n\n $ GIT_TEST_HTTPD=1 LIB_HTTPD_PORT=80 ./t5540-http-push.sh\n 1..0 # SKIP skipping test, web server setup failed\n\nWe could do better by retrying with a range of ports, but unless\nsomebody really needs that, I'd prefer to avoid complicating it more.\n\nThe one thing I have occasionally run into is a stale apache hanging\naround. But I think that only happens when I am abusing the test script\n(e.g., sticking a test_pause in, poking around, and then not letting the\nscript complete and do its cleanup).\n\nSo is the current behavior good enough to meet your needs and you\ndidn't know it, or do we need more?\n\n-Peff\n"}]}