top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

Use mongoose to test smart-http unconditionally?

+1 vote
514 views

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

posted Dec 4, 2013 by Sumit Pokharna

Share this question
Facebook Share Button Twitter Share Button LinkedIn Share Button

2 Answers

+1 vote

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.

answer Dec 4, 2013 by Sonu Jindal
+1 vote

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

answer Dec 4, 2013 by Jagan Mishra
Similar Questions
+2 votes

I recently used the Perl Framework, which is a Perl centric Http test kit. I followed the instructions mentioned in the readme available within the framework which I checked out from the link

http://svn.apache.org/repos/asf/httpd/test/framework/trunk/

The readme states the following steps:
1. You need an installation of Apache. (Either 1.3 or 2.0)
2. Any DSOs you wish to use should be configured in that Apaches
httpd.conf (the test harness will pick this configuration up)
3. Setup:
perl Makefile.PL -apxs /path/to/apache/bin/apxs
4. Run the tests:
t/TEST
5. Evaluate test output.

However, I get an error when I get to the 3rd step saying;

"Cant open perl script "/Perl": No such file or directory"

Hope someone could clarify whats happening here.

0 votes

I am new to GIT and trying to configure apache for git on windows, so that I can set it up to use over http protocol. I have tried quite hard, however, still missing here and there.
Can anyone please let me know, how to set it up step-by-step in apache including authentication and authorization? Also, how to integrate it with Ldap?

+2 votes

I want the images should be accessible as part of http page only not by any other mean, no clue any suggestion would have great help.

+1 vote

We have a set up like Apahce (80,443) redirects the request to Tomcat (8080) using mod_jk.

The new requirement is to route the request from the same apache to another tomcat (8090). Hence I made the different config file for apache with different ports (86,4444) and different worker for mod_jk which routes the request to tomcat.

Now the issue is when I hit the url http://:86 and after providing the credentials, it is redirecting to https://:86 and throwing the below error.

Error in browser:

Secure Connection Failed

An error occurred during a connection to x.x.x.x:86. SSL received a record that exceeded the maximum permissible length. (Error code: ssl_error_rx_record_too_long)

Error in logs:

"x16x03x01" 501

[Thu Jan 08 08:22:46 2015] [debug] ssl_engine_io.c(1523): OpenSSL: I/O error, 11 bytes expected to read on BIO#1bf568 [mem: 1f3930]
[Thu Jan 08 08:22:46 2015] [debug] ssl_engine_kernel.c(1806): OpenSSL: Exit: error in SSLv2/v3 read client hello A
[Thu Jan 08 08:22:46 2015] [info] (70014)End of file found: SSL handshake interrupted by system [Hint: Stop button pressed in browser?!]
[Thu Jan 08 08:22:46 2015] [info] Connection to child 3 closed with abortive shutdown(server pritoolvca1.sw.ericsson.se:443 [2], client 153.88.164.216)
[Thu Jan 08 08:23:53 2015] [error] [client 172.17.136.153] Invalid method in request x16x03x01

Could you please suggest where it might went wrong and the way forward..

+6 votes

I have a reverse proxy (apache 2.2) with mod_proxy_balancer with https visible to the outside world.

The question is: from the proxy performance/scalability point of view is it better to configure backends (origin servers) with http or with https?

Is it true that if proxy is setup https->http then it only has to decrypt/encrypt the headers and the body is encrypted/decrypted on the backend? I do not use mod_proxy_html (but maybe there are other modules which affect this behaviour on the proxy?.

How either setup affects latency of handling requests? With https->https do I have to do two handshakes (on the proxy and on the backend) for every connection? I have KeepAlive both on the proxy and the backends.

...